OAuth 2.0 Building Blocks
OAuth 2.0 is the industry standard for access delegation. If someone asked about OAuth 2.0, naturally it will bring in to your mind that there is an access token which is similar to your valet key, allow to access your protected resource on behalf of you.
Further, I believe you have already read, The OAuth 2.0 Authorization Framework [RFC 6749] specification which defines the OAuth 2.0 specific roles (Resource owner, Authorization server, Client, etc.), basic grant types to provide the authorization grant and basic recommendations. With this specification, it has built the base of this overall authorization framework, yet there are many aspects undefined. Over time these missing pieces were added as additional specs and new improvements still being added as draft specifications.
Hence to properly understand the full framework and to build a complete solution, it’s essential to learn each of these bits and pieces, but scattered nature of these specifications is challenging. In this article, I’ll list down different OAuth 2.0 specifications and their relations.
In high level, these framework components can be broken down into five main sections.
- Application registration and management
- Access delegation
- Verification and terminating delegated access
- Recommendations and security considerations
- Extended use case of OAuth 2.0 framework
Application Registration and Management
To start with the OAuth 2.0 framework, need to implement an authorization server discovery mechanism so client applications can discover the authorization server and then execute the registration process followed by application management. With the following specifications, these processes have been standardized.
OAuth 2.0 Authorization Server Metadata [RFC 8414]
This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations, authorization server capabilities such as supported grant types, response types, scopes.
This is based on the OpenID Connect Discovery 1.0 specification, which was produced by the OpenID Connect working group of the OpenID Foundation and generalizes in a way that this is compatible with OpenID Connect Discovery while being applicable to a wider set of OAuth 2.0 use cases.
OAuth 2.0 Dynamic Client Registration Protocol [RFC 7591]
Programmatically or dynamically OAuth 2.0 client application registration with an authorization server is being standardized with this specification. Upon successful registration, the authorization server returns the client credentials and relevant metadata to the client application.
Same as authorization server metadata profile, this specification also generalized the OpenID Connect Dynamic Client Registration 1.0 specification and compatible with that.
OAuth 2.0 Dynamic Client Registration Management Protocol [RFC 7592]
Dynamic client registration specification only defines how dynamically register a client application, but it does not discuss how to get, modify or delete the registered application. In this specification, it extends the capabilities in RFC 7591 and introduce Read, Update and Delete operations for registered application.
This specification is introduced as an experimental specification but requirements are valid and already implemented by most of the Identity Providers.
Access Delegation
Access delegation is in the central of OAuth 2.0 framework. After registering client application in the authorization server, it builds the trust relationship between the authorization server and client application. Next step is to get the access token from the authorization server. This process can be discussed under three main sections.
- Access grant flows
- Token types
- Client authentication mechanisms
Access Grant Flows
Mainly based on the nature of client application, there are different flows that client application can get access token from the authorization server. These flows are known as grant types, in this section, it will list down different available grant types.
The OAuth 2.0 Authorization Framework [RFC 6749]
This is the OAuth 2.0 core framework where it defines five main grant types, Authorization Code, Implicit, Password, Client Credential and Refresh grant. With the introduction of OAuth 2.0 framework there were different defined use cases and client applications types for each of these grant types, but later with the latest security recommendations and extensions there use cases have been changed. With my previous article “OAuth 2.0 Basics” I have discussed more of these grant types.
Assertion Framework for Client Authentication and Authorization Grants [RFC 7521]
The intent of this specification is to provide a common framework to use assertions with OAuth 2.0 in the form of a new client authentication mechanism or new authorization grant type. This only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations.
SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants [RFC 7522]
This specification is an extended version of “Assertion Framework for Client Authentication and Authorization Grants (RFC 7521)” for SAML 2.0 assertions. This defines how SAML 2.0 assertions can be used as a client authentication mechanism or authorization grant and processing rules and consideration. Widely used as an authorization grant compared to client authentication.
JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants [RFC 7523]
This specification is an extended version of “Assertion Framework for Client Authentication and Authorization Grants (RFC 7521)” for JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication. This includes JWT processing rules and considerations.
OAuth 2.0 Device Authorization Grant [draft-ietf-oauth-device-flow-15]
The OAuth 2.0 Device Authorization Grant is designed for internet-connected devices that either lack a browser to perform a user-agent based authorization or are input-constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources without using an on-device user-agent.
Token Types
Access token is the key concept in OAuth 2.0 framework. Access token is a string which represents the authorization issues to the client and used as a credential to access protected resources. Usually access token is an opaque string but it can have different formats, structures and methods of utilization which is not covered in the core specification and following specifications discuss regarding those aspects.
The OAuth 2.0 Authorization Framework: Bearer Token Usage [RFC 6750]
Having a bearer token any party can assess the associated protected resources without having further verifications, hence bearer token should be protected from disclosure in storage and in transport. This specification is used to define the use of bearer tokens over HTTP/1.1 [RFC2616] using Transport Layer Security (TLS) [RFC5246] to access protected resources.
JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens [draft-ietf-oauth-access-token-jwt-02]
In the past access token used to be an opaque random string and resource server always talk to the authorization server to check the validity of the access token. With the emerging industry requirements JWT (RFC 7519) token format came up as a new bee where the resource server can validate the access token without further involvement of the authorization server. Over time different identity providers used to define their own format of access tokens with this draft it's trying to generalize the format of JWT access token.
OAuth 2.0 Incremental Authorization [draft-ietf-oauth-incremental-authz-02]
With the current practice, client should request all the possible scopes upfront even all the scopes are not used or request different authorization grant for different scopes and mange it client slide. These methods provide either bad user experience or complicated developer experience.
With this specification, enhances the OAuth 2.0 authorization protocol by adding incremental authorization, the ability to request specific authorization scopes as needed, when they’re needed, removing the requirement to request every possible scope that might be needed upfront or storing multiple authorization grants in client-side.
Client Authentication
The OAuth 2.0 Authorization Framework [RFC6749] defines a client key and secret based client authentication method and it allows to define additional client authentication mechanisms.
OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens [draft-ietf-oauth-mtls-15]
This draft specification defines the client authentication using mutual TLS [RFC5246] certificate-based authentication and this can be used to do the client authentication with token, introspection and revocation endpoints similar to usual client authentication. WIth Mutual TLS authentication it can ensure only the client in possession of the private key can use the access token.
Verification and Terminating Delegated Access
Validating access tokens before accessing the protected resources and revoking the authorization grant of the access token, are another important aspect of OAuth 2.0 authorization framework. In this section, you can find the specifications used for that aspect.
OAuth 2.0 Token Introspection [RFC 7662]
This specification defines how resource server to query the authorization server to validate the access token and get the associated meta-information from the authorization server before accessing protected resources. Response will be delivered in the format of JSON object with the information including, current validity, approved scopes.
JWT Response for OAuth Token Introspection [draft-ietf-oauth-jwt-introspection-response]
Token introspection response defined in the OAuth 2.0 Token Introspection [RFC 7662] is a JSON object, but there are requirements that resource server expects strong assurance that the authorization server issued that introspection response. Hence in this draft specification defines how signed JWT it used as an introspection response.
OAuth 2.0 Token Revocation [RFC 7009]
It’s essential to invalidate the authorization grant if the intended usage is over or if there is a security concern using existing tokens. This specification defines how client application notifies the authorization server that obtained access token or refresh token is no longer required. Then authorization server can invalidate the given token and if there are any other tokens associated with the same authorization grant.
Recommendations and Security considerations
All the above specifications and draft specifications discuss how OAuth 2.0 authorization framework developed and extends. This section of this article will discuss how OAuth 2.0 framework utilizes in specific use cases, applications and security considerations required.
OAuth 2.0 Threat Model and Security Considerations [RFC 6819]
OAuth 2.0 Threat Model and Security Considerations specification provide additional security guidelines beyond described in the core OAuth 2.0 specification. Many known attacks and appropriate countermeasures to prevent those attacks are described here. Back in 2013, this came out once real implementations begin.
OAuth 2.0 Security Best Current Practice [draft-ietf-oauth-security-topics-13]
Over time the technology landscape improved so as security threats. This draft is an extension of OAuth 2.0 Security Threat Model [RFC 6819] to incorporate current security threats, precautions and security best practices.
Proof Key for Code Exchange by OAuth Public Clients (PKCE) [RFC 7636]
OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack and a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced “pixy”).
OAuth 2.0 for Native Apps [RFC 8252]
In general, different specifications describe grant types, best practices and security considerations in OAuth 2.0 framework. This is the specific best practice guideline for the Native application. In this specification, it recommends making OAuth 2.0 authorization requests from native apps through external user-agents, primarily the user’s browser. This specification details the security and usability reasons why this is the case and how native apps and authorization servers can implement this best practice.
Further, this pattern is also known as the “AppAuth pattern”, in reference to open-source libraries [AppAuth] that implement it.
OAuth 2.0 for Browser-Based Apps [draft-ietf-oauth-browser-based-apps]
OAuth 2.0 for Native Apps [RFC8252] makes specific recommendations for implementing OAuth in native applications, incorporating additional OAuth extensions where needed. OAuth 2.0 for Browser-Based Apps addresses the similarities between implementing OAuth for native apps as well as browser-based apps, and includes additional considerations when running in a browser. This is primarily focused on OAuth, except where OpenID Connect provides additional considerations.
Extended Use-case of OAuth 2.0 Framework
OAuth 2.0 is the dominant framework for access delegation. Utilizing its extensible nature, other use cases such as federated authentication (OIDC) has implemented on top of the OAuth 2.0 infrastructure. In this section, it will overlook those extended scenarios.
OAuth 2.0 Token Exchange [draft-ietf-oauth-token-exchange-19]
A Security Token Service (STS) is a service capable of validating security tokens provided to it and issuing new security tokens in response, which enables clients to obtain appropriate access credentials for resources in heterogeneous environments or across security domains. Web Service clients have used WS-Trust [WS-Trust] which used uses XML and SOAP, as the protocol to interact with an STS for token exchange.
This specification defines a protocol for an HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation.
OpenID Connect [https://openid.net/connect/]
OAuth 2.0 is a framework for access delegation and does not discuss the end-user and his identities. OpenID Connect (OIDC) is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, obtain basic profile information about the End-User in an interoperable and REST-like manner and discuss how authentication session is managed.
User Managed Access (UMA 2.0) [rec-oauth-uma-grant-2.0]
User-Managed Access (UMA) is an OAuth 2.0 based access delegation protocol. OAuth 2.0 is used to delegate access to a protected resource, to a client application used by the resource owner. Unlike OAuth, UMA allows resource owner (user) to delegate access to a client application used by someone else(third party). UMA 2.0 is the latest version of this protocol.
