Before OAuth 2.0, third-party applications required users to share their credentials (username and password) directly. This created several critical security issues: credentials had to be stored in clear text, servers needed to support password authentication despite security weaknesses, applications gained overly broad access, and compromise of any application meant compromise of the user's password and all protected data.
OAuth addresses these issues by introducing an authorization layer that separates the role of the client from the resource owner, issuing access tokens instead of using the resource owner's credentials.
OAuth 2.0 defines four distinct roles in the authorization process:
Resource Owner: An entity capable of granting access to a protected resource. When the resource owner is a person, they are referred to as an end-user.
Resource Server: The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
Client: An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics.
Authorization Server: The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
The abstract OAuth 2.0 flow involves six steps where the client requests authorization from the resource owner, receives an authorization grant, exchanges it for an access token from the authorization server, and then uses that token to access protected resources on the resource server.
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
Access Token: A string representing an authorization issued to the client, denoting a specific scope, lifetime, and other access attributes. Access tokens are used to access protected resources.
Refresh Token: Credentials used to obtain access tokens, intended for use only with authorization servers and never sent to resource servers. Refresh tokens enable clients to obtain new access tokens without requiring the resource owner to re-authenticate.
OAuth 2.0 defines four primary authorization grant types, each suited for different use cases.
The authorization code grant type is used to obtain both access tokens and refresh tokens The authorization code grant can actually be used by both client types:
Confidential Clients
Public Clients
Flow Steps:
Use Cases: Web applications with a server-side component, mobile applications with backend servers.
Security Benefits: The authorization code provides important security benefits, including the ability to authenticate the client and transmit the access token directly to the client without passing it through the resource owner's user-agent.
The implicit grant type is optimized for public clients known to operate a particular redirection URI, typically browser-based applications using JavaScript. Unlike the authorization code grant, the client receives the access token directly as the result of the authorization request.
Flow Steps:
Limitations: Does not support refresh tokens, does not include client authentication, and may expose the access token to the resource owner and other applications on the same device.
This grant type is suitable where the resource owner has a trust relationship with the client, such as the device operating system or a highly privileged application.
Flow Steps:
Use Cases: First-party applications, migration from legacy authentication systems.
The client can request an access token using only its client credentials when requesting access to protected resources under its control or previously arranged with the authorization server. This grant type must only be used by confidential clients.
Flow Steps:
Use Cases: Service-to-service authentication, background jobs, machine-to-machine communication.
The authorization endpoint is used by the authorization code and implicit grant type flows. The authorization server must support the HTTP GET method for the authorization endpoint and may support the POST method as well.
Response Types:
code - for requesting an authorization code (authorization code grant)token - for requesting an access token (implicit grant)Required Parameters vary by grant type but typically include:
response_typeclient_idredirect_uri (optional but recommended)scope (optional)state (recommended for CSRF protection)The token endpoint is used by the client to obtain an access token by presenting its authorization grant or refresh token.
Grant Types supported:
authorization_codepasswordclient_credentialsrefresh_tokenClient Authentication: A client may use the client_id request parameter to identify itself when sending requests to the token endpoint.
After completing its interaction with the resource owner, the authorization server directs the resource owner's user-agent back to the client via the redirection endpoint.
Requirements:
The authorization and token endpoints allow the client to specify the scope of the access request using the scope request parameter. The scope parameter is expressed as a list of space-delimited, case-sensitive strings.
The authorization server uses the scope to:
The redirection endpoint should require the use of TLS when the requested response type is "code" or "token", or when the redirection request will result in the transmission of sensitive credentials over an open network.
Lack of transport-layer security can have a severe impact on the security of the client and the protected resources it is authorized to access.
Clients must prevent Cross-Site Request Forgery attacks on the redirection endpoint. Clients that have ensured authorization server support for PKCE may rely on the CSRF protection provided by PKCE. Otherwise, one-time use CSRF tokens carried in the state parameter must be used.
When comparing client redirection URIs against pre-registered URIs, authorization servers must utilize exact string matching except for port numbers in localhost redirection URIs of native apps.
Clients and authorization servers must not expose URLs that forward the user's browser to arbitrary URIs obtained from a query parameter, as open redirectors can enable exfiltration of authorization codes and access tokens.
When an access token expires, clients can obtain a new access token using a refresh token without requiring the resource owner to re-authenticate.
Refresh Flow:
+--------+ +---------------+
| |--(A)------- Authorization ---->| |
| | Grant | |
| | | |
| |<-(B)------- Access Token -------| |
| | & Refresh Token | Authorization |
| | | Server |
| | | |
| |--(C)------- Access Token ------>| |
| | | |
| |<-(D)--- Invalid Token Error ----| |
| | | |
| |--(E)------- Refresh Token ----->| |
| | | |
| |<-(F)------- Access Token -------| |
+--------+ & Optional +---------------+
Refresh Token
OAuth 2.0 defines two client types based on their ability to maintain the confidentiality of their credentials:
Confidential Clients: Clients capable of maintaining the confidentiality of their credentials (e.g., server-side web applications).
Public Clients: Clients incapable of maintaining credential confidentiality (e.g., browser-based applications, native mobile apps).
Before using OAuth 2.0, clients must register with the authorization server. Registration typically involves:
The authorization server issues the client:
OAuth 2.0 provides a rich authorization framework with well-defined security properties, though as a highly extensible framework with many optional components, it can produce a wide range of non-interoperable implementations.
The framework allows for:
Based on the specification and security considerations:
OAuth 2.0, often combined with OpenID Connect, enables users to authenticate once and access multiple applications.
Third-party applications can access user data from APIs without requiring user credentials, with granular control through scopes.
Native mobile applications can securely authenticate users and obtain access tokens using authorization code flow with PKCE.
Backend services can authenticate with each other using the client credentials grant.
OAuth 2.0 leaves some required components partially or fully undefined, such as client registration, authorization server capabilities, and endpoint discovery. Without these components, clients must be manually and specifically configured against a particular authorization server and resource server.
To improve interoperability, consider implementing:
RFC 6749 defines a comprehensive authorization framework that has become the industry standard for delegated authorization. While the specification provides flexibility and extensibility, implementers must carefully consider security implications and follow best practices to ensure secure deployments. Modern implementations should also incorporate updates from related specifications such as the OAuth 2.0 Security Best Current Practice (RFC 9700) and PKCE (RFC 7636).
Before OAuth 2.0, third-party applications required users to share their credentials (username and password) directly. This created several critical security issues: credentials had to be stored in clear text, servers needed to support password authentication despite security weaknesses, applications gained overly broad access, and compromise of any application meant compromise of the user's password and all protected data.
OAuth addresses these issues by introducing an authorization layer that separates the role of the client from the resource owner, issuing access tokens instead of using the resource owner's credentials.
OAuth 2.0 defines four distinct roles in the authorization process:
Resource Owner: An entity capable of granting access to a protected resource. When the resource owner is a person, they are referred to as an end-user.
Resource Server: The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
Client: An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics.
Authorization Server: The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
The abstract OAuth 2.0 flow involves six steps where the client requests authorization from the resource owner, receives an authorization grant, exchanges it for an access token from the authorization server, and then uses that token to access protected resources on the resource server.
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
Access Token: A string representing an authorization issued to the client, denoting a specific scope, lifetime, and other access attributes. Access tokens are used to access protected resources.
Refresh Token: Credentials used to obtain access tokens, intended for use only with authorization servers and never sent to resource servers. Refresh tokens enable clients to obtain new access tokens without requiring the resource owner to re-authenticate.
OAuth 2.0 defines four primary authorization grant types, each suited for different use cases.
The authorization code grant type is used to obtain both access tokens and refresh tokens The authorization code grant can actually be used by both client types:
Confidential Clients
Public Clients
Flow Steps:
Use Cases: Web applications with a server-side component, mobile applications with backend servers.
Security Benefits: The authorization code provides important security benefits, including the ability to authenticate the client and transmit the access token directly to the client without passing it through the resource owner's user-agent.
The implicit grant type is optimized for public clients known to operate a particular redirection URI, typically browser-based applications using JavaScript. Unlike the authorization code grant, the client receives the access token directly as the result of the authorization request.
Flow Steps:
Limitations: Does not support refresh tokens, does not include client authentication, and may expose the access token to the resource owner and other applications on the same device.
This grant type is suitable where the resource owner has a trust relationship with the client, such as the device operating system or a highly privileged application.
Flow Steps:
Use Cases: First-party applications, migration from legacy authentication systems.
The client can request an access token using only its client credentials when requesting access to protected resources under its control or previously arranged with the authorization server. This grant type must only be used by confidential clients.
Flow Steps:
Use Cases: Service-to-service authentication, background jobs, machine-to-machine communication.
The authorization endpoint is used by the authorization code and implicit grant type flows. The authorization server must support the HTTP GET method for the authorization endpoint and may support the POST method as well.
Response Types:
code - for requesting an authorization code (authorization code grant)token - for requesting an access token (implicit grant)Required Parameters vary by grant type but typically include:
response_typeclient_idredirect_uri (optional but recommended)scope (optional)state (recommended for CSRF protection)The token endpoint is used by the client to obtain an access token by presenting its authorization grant or refresh token.
Grant Types supported:
authorization_codepasswordclient_credentialsrefresh_tokenClient Authentication: A client may use the client_id request parameter to identify itself when sending requests to the token endpoint.
After completing its interaction with the resource owner, the authorization server directs the resource owner's user-agent back to the client via the redirection endpoint.
Requirements:
The authorization and token endpoints allow the client to specify the scope of the access request using the scope request parameter. The scope parameter is expressed as a list of space-delimited, case-sensitive strings.
The authorization server uses the scope to:
The redirection endpoint should require the use of TLS when the requested response type is "code" or "token", or when the redirection request will result in the transmission of sensitive credentials over an open network.
Lack of transport-layer security can have a severe impact on the security of the client and the protected resources it is authorized to access.
Clients must prevent Cross-Site Request Forgery attacks on the redirection endpoint. Clients that have ensured authorization server support for PKCE may rely on the CSRF protection provided by PKCE. Otherwise, one-time use CSRF tokens carried in the state parameter must be used.
When comparing client redirection URIs against pre-registered URIs, authorization servers must utilize exact string matching except for port numbers in localhost redirection URIs of native apps.
Clients and authorization servers must not expose URLs that forward the user's browser to arbitrary URIs obtained from a query parameter, as open redirectors can enable exfiltration of authorization codes and access tokens.
When an access token expires, clients can obtain a new access token using a refresh token without requiring the resource owner to re-authenticate.
Refresh Flow:
+--------+ +---------------+
| |--(A)------- Authorization ---->| |
| | Grant | |
| | | |
| |<-(B)------- Access Token -------| |
| | & Refresh Token | Authorization |
| | | Server |
| | | |
| |--(C)------- Access Token ------>| |
| | | |
| |<-(D)--- Invalid Token Error ----| |
| | | |
| |--(E)------- Refresh Token ----->| |
| | | |
| |<-(F)------- Access Token -------| |
+--------+ & Optional +---------------+
Refresh Token
OAuth 2.0 defines two client types based on their ability to maintain the confidentiality of their credentials:
Confidential Clients: Clients capable of maintaining the confidentiality of their credentials (e.g., server-side web applications).
Public Clients: Clients incapable of maintaining credential confidentiality (e.g., browser-based applications, native mobile apps).
Before using OAuth 2.0, clients must register with the authorization server. Registration typically involves:
The authorization server issues the client:
OAuth 2.0 provides a rich authorization framework with well-defined security properties, though as a highly extensible framework with many optional components, it can produce a wide range of non-interoperable implementations.
The framework allows for:
Based on the specification and security considerations:
OAuth 2.0, often combined with OpenID Connect, enables users to authenticate once and access multiple applications.
Third-party applications can access user data from APIs without requiring user credentials, with granular control through scopes.
Native mobile applications can securely authenticate users and obtain access tokens using authorization code flow with PKCE.
Backend services can authenticate with each other using the client credentials grant.
OAuth 2.0 leaves some required components partially or fully undefined, such as client registration, authorization server capabilities, and endpoint discovery. Without these components, clients must be manually and specifically configured against a particular authorization server and resource server.
To improve interoperability, consider implementing:
RFC 6749 defines a comprehensive authorization framework that has become the industry standard for delegated authorization. While the specification provides flexibility and extensibility, implementers must carefully consider security implications and follow best practices to ensure secure deployments. Modern implementations should also incorporate updates from related specifications such as the OAuth 2.0 Security Best Current Practice (RFC 9700) and PKCE (RFC 7636).