OIDC Token (OIDC Token)

OpenID Connect (OIDC) is a specification that adds an authentication layer on top of OAuth 2.0 to convey "who this person is." OAuth 2.0 alone only handles authorization—"this token holder may be granted access to the resource"—and there was no standard way for applications to identify which user had logged in. OIDC fills that gap with three types of tokens. ### The Role of the Three Tokens The **ID token** is the core of OIDC. It is issued in JWT (JSON Web Token) format, and its payload contains claims such as the user identifier (`sub`), issuer (`iss`), and expiration time (`exp`). Verifying the signature instantly determines whether the token has been tampered with, eliminating the need to query the IdP (Identity Provider). This property of being a "self-contained credential" is key to reducing authentication overhead between microservices. The **access token** originates from OAuth 2.0 and represents the right to access APIs and resource servers. The scope of permissions is restricted by scopes (such as `openid profile email`), and the expiration time is typically set short, ranging from a few minutes to about one hour. The **refresh token** is used to obtain a new set of tokens without requiring the user to log in again when the access token expires. Because it remains valid for a long period, the risk of leakage is higher; the standard practice is to store it only on the server side and to enable rotation (replacing it with a new refresh token upon each use). ### Flow Overview In a typical Authorization Code Flow, when a user logs in at the IdP, an authorization code is returned to the client. The client sends this code to the IdP's token endpoint and receives all three tokens—ID token, access token, and refresh token—in a single response. Since the authorization code can only be used once and has an extremely short validity period, the number of times tokens themselves travel over the network is minimized. ### Implementation Considerations One area the author finds easy to overlook is where tokens are stored. In SPAs (Single Page Applications), patterns that store access tokens in the browser's `localStorage` are sometimes introduced, but these are easily stolen via XSS attacks. It is safer to store them in HttpOnly Cookies using the BFF (Backend for Frontend) pattern, or to keep them in a server-side session store. Careful attention is also required when designing token expiration times. If the ID token's `exp` is too long, changes to a user's permissions or account suspension will not be reflected immediately. Setting it too short increases the refresh frequency and raises the load on the IdP. Many IdPs default to 5–15 minutes for ID tokens, 1 hour for access tokens, and 30–90 days for refresh tokens; starting adjustments within these ranges is the most practical approach.