Supported OAuth 2.0 RFCs
On this page
This article provides an overview of the OAuth 2.0 landscape by categorizing the related standards from IETF and the OpenID Foundation that the Curity Identity Server supports. It then maps the standards to a basic set of use cases to help you to identify when to use which specifications. Complement your findings with the right OAuth flow.
OAuth 2.0 Landscape
The web authorization protocol working group (oauth WG) within IETF lists more than 30 proposed standards (RFCs) and several active draft documents. Specifications from other working groups like the JSON Object Signing and Encryption (JOSE) working group and from the OpenID Foundation also contribute to the landscape. The great amount of related documents and their specifications complicates identifying relevant standards for an implementation.
The following illustration visualizes the categories of the various standards to provide a quick overview of the landscape. Note that it does not include all related standards. For example, it does not account for cryptographic algorithms (such as RSA, ECDSA, or EdDSA) or transport security, or their data formats (e.g., TLS and X509). Instead, it focuses on the protocols at the application layer.
The core standards are the ones needed to retrieve, transport and manage access tokens. They are accompanied by best current practice documents. Some standards are mainly applicable when using the code flow, which, on the other hand, is recommended for most cases. Other standards relate to the access token, and specify how to format, transport and validate it. There is also a set of standards that simplifies integrations by providing the means to discover server capabilities and implement self-service management for clients.
There are standards that enable implementing the principle of least privilege by extending the authorization request, facilitating token revocation and down-scoping. Certain standards provide message integrity for requests and responses to harden the security on the application layer. There are also standards that relate to the identification of authentication method to use. In that context, it is also worth mentioning standard authentication protocols like WebAuthn and Digital Credentials Protocols that may be used with an OAuth flow. Other standards for the OAuth 2.0 protocol define means to bridge trust boundaries. Many categories overlap.
Categorizing the standards helps to get a better understanding of the landscape. To assist you with identifying relevant specifications for an implementation, we provide a map of standards that reflect some common use-cases.
Map of OAuth 2.0 Standards
There are primarily three components in OAuth:
- Client
- Resource server
- Authorization server
The authorization server is the central component that needs to support the vast majority of the standards. The Curity Identity Server supports and enables the support of a wide range of identity-related standards. The list is not limited to OAuth and OpenID Connect but also includes SCIM and related protocols from standard bodies such as IETF, OpenID Foundation and OASIS. In addition to these integration standards, the Curity Identity Server also supports a large number of user authentication standards such as WebAuthn, Kerberos, TOTP and SAML.
For the remaining two components there are less requirements because some of the standards are only relevant for the client and others for the resource server. You may need to support additional standards if you have strong security requirements. When it comes to the client, the set of standards also depends on whether and how it needs to authenticate users. We therefore provide you a filtered view for the client as well as the resource server (aka API).
To secure OAuth clients, first implement an appropriate flow, such as a code flow. Follow best practices for your client type. Many OAuth libraries assist you in the configuration of an integration by automatically discovering the necessary settings from the authorization server metadata (RFC 8414).
In some environments, you need to further refine implementations and deployments to improve security. In some cases, hardening security requires only minor changes and in others it may introduce some overhead like additional key management.
The security in OAuth clients increases significantly with strong client authentication, e.g. by using public key cryptography. Dynamic Client Registration is a protocol that enables a setup commonly used with mobile applications where otherwise public clients can upgrade to confidential clients. Often, hardening security also implies replacing bearer tokens with sender-constrained tokens or protecting the integrity of the messages.
With the resources in this article, you should be able to determine the relevant specifications for you and your implementation whether you're working on the client or API-side of the architecture. Whatever your conclusion, the Curity Identity Server supports all (and more) specifications listed in the maps.
Standards & Conformance
Refer to the conformance page for a complete list of supported standards.
Future standards
Curity is actively working on adding support for more parts of the OAuth 2.0 framework, if you're missing a spec or have questions contact us for more details.
Judith Kahrer
Product Marketing Engineer at Curity
Join our Newsletter
Get the latest on identity management, API Security and authentication straight to your inbox.
Start Free Trial
Try the Curity Identity Server for Free. Get up and running in 10 minutes.
Start Free Trial
