Application Security – OAuth 2.0
Now a days web application is one of main component of digital network space. Due to its vast range and types of data it is important to secure web application in production environment. Auth2.0 is a one of these application security protocol, which allows accessing the resources of the resource owner by enabling the client applications on HTTP services.
There are few main oAuth2.0 providers such as Google, Facebook, GitHub, etc. It allows sharing of resources stored on one site to another site without using their credentials. It uses username and password tokens instead direct credentials sharing over network.
- Resource Owner: The user who owns the data.
- Client: The third-party app requesting access.
- Resource Server: The server hosting the protected user data
- Authorization Server: The server that authenticates the user and issues tokens.
OAuth 2.0 primarily defines two core token types, with a third commonly used via the OpenID Connect (OIDC) extension.
1. Access Token
Purpose: Grants the client temporary permission to access protected resources (APIs, files, data) on a resource server.
Characteristics:
- Short-lived (typically minutes to a few hours) for security.
- Carries scopes (permissions) that define what the client can do.
- Presented by the client (usually in the Authorization: Bearer <token> header).
Formats:
Opaque (reference) tokens: Random string; the resource server must call the authorization server (via Token Introspection – RFC 7662) or look it up to validate.
Self-contained (JWT) tokens: Signed JSON Web Token that contains claims; the resource server can validate it locally without calling the authorization server (JWT Profile for OAuth 2.0 Access Tokens – RFC 9068).
Common subtypes / binding methods:
Bearer tokens (RFC 6750) – most widely used; anyone who has the token can use it.
Proof-of-Possession (PoP) / sender-constrained tokens – cryptographically bound to the client (e.g., DPoP – RFC 9449, or mTLS-bound tokens – RFC 8705) for higher security.
2. Refresh Token
Purpose: Allows the client to obtain a new access token (and optionally a new refresh token) when the current access token expires, without requiring the user to re-authenticate or re-consent.
Characteristics:
- Longer-lived than access tokens (hours, days, or longer, depending on policy).
- Highly sensitive — must be stored securely.
- Usually opaque.
Best practices include refresh token rotation (issue a new one each time it is used) and sender-constraining for public clients.
Issued optionally along with an access token (depending on the grant type and server configuration).
3. ID Token (from OpenID Connect)
Purpose: Provides authentication information (who the user is) to the client application.
Characteristics:
- Always a JWT.
- Contains claims about the user and the authentication event (e.g., sub, iss, aud, iat, exp, auth_time).
- Intended for the client application only — not sent to resource servers for API access.
- Used to verify identity, not for authorization.
Notes – The token_type returned by the authorization server is almost always “Bearer” in modern implementations.
Authorization codes are temporary intermediate values (not long-lived tokens) used in the Authorization Code flow.