Authentication (session, JWT, OAuth/OIDC)

01 · CONTEXT

Two questions: who they are and what they can do

An authentication system answers two different questions. The first is who the person is: OpenID Connect lets the client verify the user's identity based on the authentication performed by an authorization server. The second is what an application can do on their behalf: OAuth lets a third-party application obtain limited access to an HTTP service.

Once the first question is answered, the system needs to remember the result, and HTTP does not help: each request and response pair is independent of the other interactions. This is where the session identifier or the token comes in, which, according to OWASP, bind the authenticated credentials to the user's traffic and to access controls. Once the authenticated session is established, this identifier is temporarily equivalent to the strongest authentication method used.

02 · SERVER-SIDE SESSION

Session: the state lives on the server

In the session model, the browser stores only an identifier and its meaning lives on the server. OWASP asks that the identifier's value be meaningless and never include sensitive information or personal data (PII). The meaning and business logic associated with it live in session objects or in a session store on the server.

Unpredictability of the identifier is a requirement: OWASP asks for enough entropy to prevent brute-force guessing and sets the required minimum at 64 bits.

1. The browser sends the credentials and the load balancer forwards them to the authentication service.

2. The authentication service checks the credentials against the user database.

3. Once the user is authenticated, the service stores the session state in the session store and returns to the browser only a meaningless identifier.

4. On subsequent calls the browser resends the identifier, and the business API uses it to query the session store.

5. On logout, the server invalidates the session in the session store.

The session cookie carries two protection attributes. The Secure attribute makes the browser send the cookie only over HTTPS. The HttpOnly attribute prevents scripts from accessing the cookie, a protection that OWASP considers mandatory against identifier theft via XSS.

The lifecycle is also controlled by the server. The identifier should be renewed after any change in privilege level, and the most common scenario is the authentication process itself. Every session must have an idle timeout and an absolute timeout, enforced on the server, and logout must invalidate the session at least on the server.

03 · TOKENS

Self-contained tokens and JWT

A JWT is a compact, URL-safe way of representing claims exchanged between two parties. The claims can be signed or MAC-protected and/or encrypted.

Three registered claims weigh on the design. The iss claim identifies who issued the JWT. The aud claim identifies the recipients, and whoever processes the token without identifying itself with a value in aud must reject it. The exp claim marks the moment from which the token can no longer be accepted.

In OAuth, the access token is usually opaque to the client. It can be an identifier used to retrieve the authorization or can itself contain the authorization information in a verifiable form, and it represents scopes and durations of access granted by the resource owner and enforced by the resource server and the authorization server.

1. The browser sends the credentials to the issuer, which checks them against the user database.

2. The issuer returns a JWT, whose claims can be signed, including iss, aud, and exp.

3. The client presents the JWT to the gateway, which does not accept a token with an expired exp and rejects it if aud does not include it.

4. The business service applies the scopes and the access duration represented by the token.

5. When the access token expires, the client uses the refresh token to obtain another access token from the issuer.

The access token can have a shorter life and fewer permissions than the resource owner authorized, and the refresh token is the credential used to obtain new access tokens.

To end a token's access, OAuth defines a revocation endpoint: it lets the client tell the authorization server that a refresh or access token is no longer needed, and the request invalidates the token and, where applicable, other tokens from the same authorization grant.

04 · OAUTH AND OIDC

Federated login with the authorization code flow

In the OpenID Connect authorization code flow, the client sends the request to the authorization server, which authenticates the user and sends them back to the client with a code. The client exchanges the code at the token endpoint, receives an ID Token and an access token, and validates the ID Token to obtain the user's identifier.

Because the resource owner authenticates only at the authorization server, their credentials are never shared with the client. The flow also avoids exposing tokens to the user agent and to other malicious applications with access to it.

1. The client application sends the user and the authentication request to the authorization server.

2. The authorization server authenticates the user, with the user database as the basis for the credentials.

3. The server returns the user to the application with an authorization code, and the user's credentials do not pass through the application.

4. The application exchanges the code at the token endpoint; public clients must use PKCE to protect the code.

5. The application receives an ID Token and an access token, validates the ID Token, and obtains the user's identifier.

6. With the access token, the application calls the protected API, which must verify that the token was issued for it.

What OpenID Connect adds to OAuth is the identity layer: the ID Token is a security token with claims about the user's authentication by an authorization server.

OAuth public clients are susceptible to the authorization code interception attack, and must use PKCE against code injection and misuse.

05 · PITFALLS AND WRAP-UP

What to avoid and how to close the interview

OAuth's security recommendations say that the resource owner password credentials grant must not be used and that clients must not use the implicit grant. Refresh tokens for public clients must be sender-constrained or use rotation. Audience restriction limits the access token to a specific resource server, which checks the intended audience.