This is a quick overview of what is going on around OAuth 2.0 and OIDC (OpenID Connect 1.0).

OAuth 2.0 was approved as RFC by IETF in 2012. OIDC was approved by OpenID Foundation in 2014. These two fundamental base protocols have been around for some years and have proven to become very popular. We have covered these protocols in a couple of posts and white papers covering both some basic use cases and differences with SAML.

I thought it was time for an update of work around these protocols, including specifications released many years ago after the initial work and early, not yet finalized drafts that people are currently working on. After the initial work a few dozen new specifications and recommendations have been published.

Implementation of an OpenID Connect Basic Client is a fairly straightforward task and the simplicity is surely a major contributing factor to the success of OAuth and OIDC. However, it is also quite easy to make implementation mistakes, which can make applications vulnerable. Some of the new specifications are written as best-practice documents, giving guidance on how to avoid the most common mistakes.

Another set of specifications is focused on adding features that improve security. The risk model of a basic client implementation is often sufficient but the security specifications are there to allow interoperability across implementations with higher security requirements.

Discovery and Registration

Discovery allows relying parties to obtain information about capabilities of an OIDC provider, such as security keys and endpoint locations. The discovery specification defines the exact URL location where this information is available and a JSON format for publishing the information.

Registration lets a relying party establish its identity with an OIDC provider. This allows a provider to communicate securely with the relying party. Registration sets the configuration of a relying party, including security keys and how the relying party intends to communicate with the provider.

Software statements are a solution to automate initial registration of relying parties. A software statement is a token or signed message that is verified by the provider and lets the provider create a registration for a relying party, usually with a pre-defined configuration. Automation is useful when a large number of relying parties need registration, for example for mobile application installation or as part of DevOps efforts to manage web application clusters.

Configuration management allows a relying party to update or remove its registration at an OIDC provider. For example, when a mobile application installation is removed from a phone, the application could also remove its registration.

Grant types

Grant types are protocols for getting access and ID tokens from the AS. Initially, OAuth defined two browser-based flows: authorisation code flow and implicit grant, and in addition two back channel flows: password grant and client credentials grant.

The assertion framework specifies how to use SAML 2 assertions and JWT tokens to obtain OAuth tokens.

Device flow enables clients running on input constrained systems to obtain user authorisation and tokens. Devices such as smart TVs, media consoles etc. are typical systems. Device flow also works well with command line tools running on remote servers. With device flow, the only requirement for the client is to display a http link, which could be presented as a QR code for ease of access. The end user is expected to use a browser and navigate to this link in order to complete authorisation. 

CIBA allows clients that know the user’s identifier to obtain authorisation and tokens. CIBA works without redirects through the user’s browser. Authorisation is completed on the user’s Authentication Device. In a typical scenario, CIBA is a standards-based protocol to authenticate users using an authenticator app running on a smart phone.

Token exchange is in some sense similar to the assertion framework. However, token exchange also implements a couple of new use cases. Generally a token exchange service validates security tokens provided to it and issues new tokens in response. For example, the service could issue an ID token in response to a SAML 2 assertion. Token exchange also specifies use cases for impersonation and delegation, where the issued new token is for a different target service or represents another subject.

Security features

Using asymmetric keys

One of the first steps in improving security is to get rid of the client secret and symmetric cryptography. This means using JWT client assertions signed with asymmetric keys for authenticating requests from the client.

End-to-end message integrity and confidentiality

OAuth and OpenID Connect require using TLS. However, TLS alone does not always guarantee complete end-to-end integrity and confidentiality. Some messages are transported via the user agent and some messages may pass http proxies and other intermediaries that have access to the decrypted TLS stream.

Authorisation request and authorisation response are the two messages transported via the user agent. The JWT secured authorisation request (JAR) lets clients sign and encrypt the authorisation request. The pushed authorisation request (PAR) is an extension of signed request. The JWT secured authorisation response mode (JARM) provides means to sign and encrypt the authorisation response.

OpenID Connect has built in features for securing ID token and user info response. For OAuth, a recent spec added the missing feature of securing the introspection response. Securing these messages may be legally mandated because the messages often contain personally identifying information.

Proof of possession

By default, the authorisation code, access token and refresh token are bearer tokens. That means anyone who is in possession of such a token can get access to the associated resources. Because tokens are simple strings of characters, and tokens are transmitted over the network, there is always some risk of tokens leaking.

Proof of possession (PoP) is a concept that addresses this risk by adding the requirement of demonstrating a cryptographic proof when presenting a token. The assumption is that cryptographic keys are better protected than tokens, as the keys can be securely stored and are never transmitted over the network.

PKCE, also known as “pixy” or SPoP, provides proof of possession protection for the authorisation code. This protection is especially important for public clients and other clients that cannot keep client credentials confidential.

Mutual TLS binding (MTLS), Token Binding, and DPoP are protections for access tokens and refresh tokens.

MTLS binding relies on two way TLS. The access and refresh tokens are bound to a client certificate. A MTLS-bound token can only be presented on a two way TLS connection that was initiated with the particular client certificate. MTLS is typically intended for scenarios without a user agent, such as native apps or server-to-server deployments.

Token binding relies on a TLS extension implemented by both the user agent and the web server. Token binding asks the browser to generate a private key scoped to a particular website. Token binding binds tokens for a website to the generated private key. The reason token binding works is because the browser manages and stores the private key securely, and does not expose the private key via any APIs.

The early draft of DPoP protects access and refresh tokens with JWT-formatted DPoP tokens. The DPoP tokens are signed with better protected keys such as WebCrypto generated keys in a user agent context, or HSM protected keys in a server-to-server scenario.

Interoperability

The OAuth spec intentionally does not define a ‘format’ for the refresh and access tokens. The tokens should be treated opaque by the application and token introspection is required to validate tokens.

However, many OAuth providers have opted for using JWT format for these tokens. The early draft of JWT profile for access tokens attempts to standardise the JWT format. This allows interoperability across relying parties that wish to treat access tokens as value tokens that can be validated without token introspection.

Best practices

OAuth and OIDC are very popular and widely deployed. However, security research and experiences from deployments have shown that there are common pitfalls and also new threats have emerged. The best practices documents are written to share experiences and provide guidance how to avoid the most common mistakes.

The OAuth Security BCP is the most broad one and extends the original OAuth security considerations document. These documents are a must-read for anyone planning to deploy OAuth or OIDC.

The Native Apps BCP provides guidance how to use OAuth from native applications, such as mobile or desktop applications.

Browser Based Apps BCP is for those implementing modern browser-based single page applications (SPA) with HTML and JavaScript technologies.

JSON web tokens, or JWTs, are widely used and deployed as a simple security token format in numerous protocols and applications. The JWT BCP provides guidance to secure implementation of JWTs – a must-read for anyone producing or consuming JWTs, including ID tokens, client assertions or JWT-encoded access tokens.

Other

Many OpenID Connect providers implement Single Sign-On (SSO). The session management specifications define features for checking the status of and terminating SSO sessions.

Complex federations with countless identity providers forming a network of trust is often seen as the stronghold of SAML. The OpenID Connect Federation specification, which is based on experiences from operating large SAML federations, proposes a novel approach to managing trust in a federation network.

Conclusions

The set of extensions and supplements to the original OAuth and OIDC specifications is quite extensive. I hope this article helps navigate the specifications.

As mentioned earlier, we have covered other aspects of OAuth and OpenID Connect in two white papers – Secure an API by using OAuth 2.0 and SAML vs OAuth 2.0 vs OIDC.  I also provide instructions and a live example of Single Page Applications (SPA’s) on my GitHub account, links here – Single Page Applications & API Protection Examples.