HomeBytesheetsRoadmapsUI TemplatesUI ToolsStack Discussion
4 Topics
Chapter•220 Minutes

Authentication and Authorization

Understand API identity, credentials, permissions, tokens, JWTs, sessions, and access control.

Authentication vs Authorization

Authentication answers: "Who are you?"

Authorization answers: "What are you allowed to do?"

A request can be successfully authenticated but still forbidden. For example, a normal employee can authenticate successfully but may not have permission to delete organization billing data.

Do not implement authorization merely by checking that a user is logged in. Authorization must evaluate the requested action against the resource and the caller's permissions.

Authentication and Authorization

API Keys and Basic Authentication

API keys are simple credentials often used for server-to-server integrations or identifying applications. They should be treated as secrets, rotated, scoped, and revocable.

HTTP Basic Authentication sends a username and password encoded with Base64. Base64 is not encryption, so Basic Authentication must be used over TLS.

API keys are usually weaker than modern delegated authorization systems when users and third-party access are involved, but they remain useful for controlled machine-to-machine scenarios.

Never Treat Base64 as Encryption

Base64 encoding provides no confidentiality. Credentials transmitted with Basic Authentication require HTTPS.

Bearer Tokens and JWT

A bearer token grants access to whoever possesses it. This is why bearer tokens must be protected in transit and at rest.

JWT is a token format consisting of encoded header, payload, and signature. A JWT may contain claims such as issuer, subject, audience, expiration, and issued-at time.

A signature provides integrity and authenticity of the signed token; it does not automatically provide confidentiality. Sensitive data should not be placed into a JWT merely because it is encoded.

Servers must validate the algorithm, signature, issuer, audience, expiration, and other required claims according to the application's security model.

Bearer Token Validation
Key Takeaways
  • Bearer tokens must be protected because possession grants access.
  • JWT encoding is not encryption.
  • JWT validation must include more than decoding the payload.

OAuth 2.0 and OpenID Connect

OAuth 2.0 is primarily an authorization framework, not an authentication protocol.

It allows a resource owner to authorize a client application to access protected resources without giving the client the user's password.

Modern applications commonly use the Authorization Code flow with PKCE for user-facing clients.

OpenID Connect builds an identity layer on top of OAuth 2.0 and introduces concepts such as the ID token and UserInfo endpoint.

Important OAuth concepts include authorization server, resource server, client, resource owner, scopes, access tokens, refresh tokens, redirect URIs, PKCE, and consent.

OAuth 2.0 Authorization Code with PKCE