Why OAuth is so Important: An Interview with Justin Richer

This is the third article in this series by Kathleen Moriarty, CIS Chief Technology Officer.

In this article, Moriarty interviews Justin Richer, an internet security expert with over two decades of experience, and author of “OAuth2 In Action,” as well as many OAuth (Open Authorization) extensions. Together they take a deep dive into authentication, authorization, federation, and related technologies.

Related articles in this series:

• Why Are Authentication and Authorization So Difficult?
• Authentication and Authorization Using Single Sign-On

Moriarty: Strong authentication and dynamic authentication are intrinsic to a zero trust architecture as these measures reduce the chance of an attacker gaining a foothold on your network, moving laterally, or surviving a reauthentication request. It’s not as simple to just deploy these technologies as there are many to choose from and there are lots of deployment considerations to ensure the expected security gains are met. Let’s say an organization has selected a multi-factor authentication (MFA) solution that meets their needs (). They are considering an authorization framework.

What are the high-level considerations for an organization considering OAuth?

Richer: OAuth is a powerful security framework that allows software to act on the behalf of users without exposing their credentials to the software. OAuth is a fairly loose collection of related protocols that are applicable in different environments, and the first choice to be made is which pieces to deploy. The OAuth working group is currently drafting OAuth 2.1 that pulls together many of the best practices from the last decade of experience with this protocol family. In OAuth 2.1, if there is a user involved in the delegation process, the recommendation is to use the Authorization Code Grant with the Proof Key for Code Exchange extension (PKCE). If there is no user involved with the delegation process, the recommendation is to use the Client Credentials Grant. Other grant types and extensions are available for specific applications and use cases, but these two cover the majority of cases.

What security considerations should organizations keep in mind for deployments?

Richer: The OAuth Authorization Server (AS) is the key point for an OAuth system. Since the AS issues access tokens and authorizes the client software, if the AS is compromised, then an attacker could act with impunity on the network by impersonating anyone. This is the core issue behind the Golden SAML attack at the center of the Solar Winds breach. The SAML equivalent of the AS was attacked and its signing keys were stolen, allowing attackers to bypass all the security and authentication requirements in the system by acting as their own AS. Therefore, protection of the AS, its keys, and its storage are of the utmost importance.

Ultimately, the trust model of an OAuth system is a combination of trusting the AS, the client software, and the end users. In a functioning delegation, the end user delegates their access rights to the client software using the AS as a means for accomplishing this. An OAuth deployment needs to be able to answer key questions such as who is allowed to delegate authority, to whom, and for what. These questions will guide deployers in determining how to build and configure their OAuth systems.

The OAuth working group learned quite a bit from a security protocol proofing performed by researchers a few years back. Have the gaps been addressed in available libraries and products?

The OAuth ecosystem is continuously evolving. These days, most libraries support PKCE and related projects, however some naive but well-meaning implementations skip important checks like randomizing and validating the “state” parameter or sharing client identifiers between different pieces of software. It is possible to build out a very secure OAuth ecosystem, but it’s still up to the deployer and developer to implement all the appropriate checks.

What is OpenID Connect and how does OAuth fit into it?

OpenID Connect is an identity protocol built on top of OAuth 2.0. Where OAuth provides software a way to access something on a user’s behalf, OpenID Connect extends this by saying that the software is asking for access to the identity of the end user. In this way, OpenID Connect can leverage all the power and flexibility of OAuth and deliver an authentication technology on top of an authorization technology. OpenID Connect accomplishes all of this by adding several important constructs to OAuth, including an identity assertion (called an ID Token) separate from the access token, as well as a standardized identity API (the UserInfo Endpoint) that is protected by OAuth. The OAuth portions of OpenID Connect can simultaneously be used to grant access to other resources, in addition to the user’s identity, at the same time. In this way, a user can log into a piece of software and let that software access protected functionality on their behalf.

Moriarty: OWASP Top 10 Web Application Security Risks highlights key recommendations to protect against common application vulnerabilities and includes recommendations for OpenID Connect and OAuth, such as the use of a JSON Web Token for cryptographic protection on authorization tokens.

Are these recommendations baked into products and libraries or are there certain actions implementers need to be keenly aware of?

Access tokens need to be constructed in such a way that an attacker can’t generate or modify the token and what it’s good for. The use of JWT as an access token format is one approach that is commonly supported, and another is to use cryptographically random reference tokens that contain no information in them. These tokens can be used with OAuth Token Introspection to look up token information in real time from the AS. Furthermore, key-bound access tokens like OAuth mutual transport layer security (MTLS), OAuth Demonstration of Proof of Possession (DPoP), and the newly-proposed OAuth HTTP Signature binding all make it more difficult for an attacker to steal and use access tokens by tying the token to a key.

The key itself is not sent over the wire with the access token, so theft of both would require a much more advanced attack than simply stealing a valid token in flight from a poorly-configured client or resource. We are seeing an increase in software that supports these more advanced token formats, though bearer tokens (OAuth’s default, which requires no such key) are far and away still the most common.

Moriarty: As mentioned earlier in the blog series, the Security Assertion Markup Language (SAML) vulnerability led to attackers being able to bypass multi-factor authentication in the SolarWinds attack. The only recommendation I’ve seen to avoid this exploit, dubbed a golden SAML attack, is to correlate logs for authorizations back to authentication.

Are there other well-known vulnerabilities in SAML?

Richer: In the SolarWinds attack, the attackers were not only able to create valid assertions that looked just like they had come from the identity provider (IdP) but  they were also able to inject those assertions into waiting applications. SAML’s WebSSO profile is built around the application waiting for such an assertion to be injected from the web browser, which allowed attackers to create active sessions for arbitrary users. The applications being attacked made no difference between waiting for a response to a login request and receiving a request unbidden. SAML does have an Artifact Binding extension that would prevent this, but that extension is largely unused in the wild.

Why might an organization use SAML versus other available federation technologies?

Richer: Federation technologies are often chosen as the least common denominator among the parties who want to federate. Therefore, if both sides speak SAML and not something else, then SAML is the sensible choice because it’s what’s available.

While OAuth is an authorization technology and SAML is a federation technology, might OpenID Connect that includes OAuth be a better option than SAML today?

Richer: OpenID Connect is greatly superior to SAML from a technology standpoint in most measurable ways, especially when used with OAuth 2.0’s best security practices (such as not using the Implicit Grant Type). OpenID Connect also separates the assertion carrying the authentication event (the ID Token) from the conveyance of user account attributes (from the UserInfo Endpoint). SAML combines these both into a single assertion, and also encourages the use of this assertion to access additional resources beyond logging in. The separation of concerns allows for better privacy practices and better efficiency, as attributes don’t need to be passed around all the time. It also enables better security, as selective discloser can be used to limit what attributes are sent for a given transaction. Furthermore, OpenID Connect can be deployed more readily for non-web applications, such as mobile applications.

OpenID Connect also encourages short-lived assertions and the use of proper session management at client applications, as opposed to a single assertion that lives long and should be used at multiple different applications for login. Finally, OpenID Connect’s use of OAuth allows the client application to access additional services and APIs with the same access token, making for a better user and developer experience.

When might you use both OpenID Connect and SAML?

Richer: One would use multiple types of federation technology when the endpoints and environments that they need to connect to already speak those types. It is not uncommon for an organization to expose their identity infrastructure with multiple protocols in parallel to fit these cases. From a user’s perspective, SSO is still achieved as one account allows them to log into multiple applications. There are some cases where an identity proxy is used to translate between one federation protocol and another, allowing two groups to connect to each other that otherwise would be technologically limited. Such situations come with their own risks, such as the proxy being attacked directly or actions being tracked.

Moriarty: You [Richer] havebeen active in the Grant Negotiation and Authorization Protocol (GNAP) working group of the IETF as an author of this new proposed standard. Having been involved in the effort for the design team, the working group has been considering these types of attacks.

What measures are being baked into the Security Considerations for GNAP to prevent attacks like golden SAML?

Richer: The golden SAML attack counts on the attacker being able to create a signed artifact just like the AS and having that artifact accepted by the target to effect a log in or resource access. If the AS’s keys are stolen and those keys are used for things like generating signed access tokens to be trusted by resource servers, then an attacker would be able to create their own trusted access tokens. Technologies like token introspection, which is a built-in option for GNAP, can help this with liveness detection. Additionally, all access tokens in GNAP are, by default, bound to keys associated with client instances. If the resource server is able to validate the identifier for the key in addition to the access token itself, it will be able to further protect itself against accepting bad tokens. Finally, a resource server is going to want to analyze how and where access tokens are being presented. If the same token is rapidly being presented from different parts of the world, for example, that raises suspicion. These are approaches that can be used with OAuth but are more naturally fit for GNAP.

Fundamentally however, the access token is not used to log in a user to an application. That job is given to the assertion next to the access token. The assertion is directed at the client application, not the resource server. While an attacker who steals the AS’s keys would be able to generate a signed assertion, it would be more difficult to insert that assertion into the client application because of how GNAP is designed. Assertions that would constitute a login are only ever passed as a response to a direct HTTP call to the AS, never injected from an untrusted context like a web browser. In order to inject a fraudulent assertion, an attacker would need to impersonate the target AS enough that the client instance would be talking directly to the attacker. This would require things like DNS and certificate poisoning attacks on top of the signing key theft.

Additionally, GNAP is being designed in a dynamic-first mindset, where the relationships between all parties are not necessarily known ahead of time. OAuth and SAML assume that all parties have made agreements to behave nicely ahead of time, and the trust of the network relies on those agreements. While GNAP allows such agreements, they are an optimization on top of a protocol that assumes a dynamic introduction of all actors and components. This dynamic trust model puts less trust into any individual component and more into the overall holistic process. An attacker then has to attack the process itself in order to execute successfully.

We have a number of authorization protocols, why is GNAP important?

GNAP is building on what came before it, in the same way that OAuth 2.0 built on OAuth 1.0, AuthSub, and BBAuth, and the way that OpenID Connect built on OpenID 2.0 and SAML. GNAP is being designed in a forward-facing way that embraces security and privacy in ways we now know are important, and its design takes into account the kinds of applications and deployments you see around the internet today. For example, single-page applications and mobile applications are currently much more common than server-side web applications on a dedicated server, and GNAP’s core design assumptions take that into account. We’re also seeing a push against OAuth’s assumption of the user always being in a web browser, and GNAP accounts for this by having an abstracted and extensible interaction phase. None of this is being built in a vacuum, and all the best aspects of things that have come before are being incorporated. Instead of patching together spot-fixes that often conflict, GNAP is letting us design a better foundation.

Moriarty: From my perspective, it seems that adding another authorization protocol could be confusing to industry.

Would GNAP replace OAuth 2.0 for some implementations and why?

For many systems, GNAP would replace OAuth 2.0 as it can solve the same core problems in a very similar fashion. Where GNAP really shines is the spaces where OAuth is awkward or lacking. In much the same way that OpenID Connect took over the use cases where SAML began to fail – mobile applications and API access, for instance – GNAP can take over in cases where OAuth starts to fall apart, such as cross-application delegation, multi-user and multi-stage access rights, and complex API access. And GNAP is able to do this all with a simplified and clean protocol that fits modern environments.

I’d like to thank Justin Richer for his time and valuable insights!

About the Author