The OAuth Standards Stack: An Architectural Perspective

The OAuth standards stack is racing to keep up with the growing inter-connectedness of cloud, IOT, social networks, e-commerce, individuals, and enterprises on today’s Internet. The menu of new standards options can seem bewildering – especially since some are still cooking in the standards committees’ kitchens.

Fortunately, Pam Dingle created the diagram shown above from Ping Identity’s “Emerging Standards on the Identity Landscape” webinar.

These days, any discussion of identity and access management (IAM) standards starts with OAuth and OpenID Connect. The webinar begins with a quick recap, likening OAuth to “a game of hot potato” for passing secrets between users, applications, and APIs. (If you’re feeling a bit foggy on OAuth, I recommend getting a quick intro or refresh in pictures at the following OAuth 2.0 Simplified slildeshare first).

In General

Since OAuth 2.0 came out, why are there still more standards now? It helps to understand that OAuth was built to be simple for developers. For example, it gives us an opaque access token with no way to revoke or validate it. Implementations needing more functionality must layer it on in a proprietary manner, e.g. token value = “read privilege023AF85-&34”.

Unintentional consequence: Multiple proprietary OAuth extensions make the OAuth implementation ecosystem complex even though the spec itself is simple. Too many such implementations pose training and interoperability challenges for developers trying to make them work together. The need to interoperate and/or reuse functionality motivates the ongoing standards work which has continued since OAuth 2.0 first came out in 2012.

Pam’s webinar builds up the identity standards stack figure, layer by layer. I summarize it below.

Access Token Create-Read-Update-Delete (CRUD) Layer

RFC 7009 was one of the first standard extensions to come out. It enables an OAuth client to request a token to be revoked, e.g. enable a user to withdraw consent for sharing personal identity attributes and other use cases. RFC 7662 enables token introspection for those applications that need to use or understand semantics within the token for fine-grained authorization or other purposes.

Also in the CRUD layer, new standards create mechanisms to tweak OAuth’s four token establishment flows, and to create new flows. For example, RFC 7521 provides a framework enabling signed data or identity assertions (such as SAML assertions or signed Java Web Tokens (JWTs)) to be used as Authorization Grants, or for client authentication. The Internet Draft “OAuth 2.0 Device Flow for Browserless and Input Constrained Devices” is in the works to enable an additional flow for new use cases, such as authorizing a Roku or BluRay player for a Netflix or Hulu streaming subscription.

Assertion-Based Communication Layer

OpenID Connect (OIDC) – used for authentication and assertion of user information – is the poster child for extending OAuth. A raft of other standards are following in the OIDC’s wake. Assertion profiles leveraging the RFC 7521 framework are available for signed client requests, Security Assertion Markup Language (SAML), and mutual TLS certification authentication for OAuth 2.0 clients. There is also the RFC 7523 specification for token exchange; it enables software to trade a JWT or SAML assertion for an OAuth access token.

Client Ecosystem Layer

As noted earlier, the overall architecture of the Oauth/OIDC standards stack seeks to avoid inter-dependencies among the different-colored layers. This is especially true for the client layer, where standards requirements vary immensely depending on the ecosystem. Client ecosystems range from the simple ones in which administrators can register clients manually and where the OAuth authorization and resource server are in the same domain, to complex ecosystems spanning multiple domains and requiring automation at scale.

Large software-as-a-service (SaaS) or social network environments linking together multiple applications or sites on behalf of enterprises or individuals are examples of topologies with more complex ecosystem requirements. Additional ecosystems requirements will emerge following the European PSD2 regulation, which requires banks to provide open  APIs enabling customers to leverage their financial data; the webinar suggested an example of a supermarket app interacting with multiple shopper’s banks.

To scale out the client ecosystem, RFCs 7591 and 7592 provide a dynamic client registration protocol with a management layer. Given a domain name, OAuth clients can locate the domain’s OAuth authorization server(s), discover capabilities, and register themselves. This will be important for Internet of Things (IOT) devices in the field that must manage themselves in a secure way.

Identity Layer

The identity layer is about users, their sessions, and how to interact with them. Standards create value not only by enabling products to interoperate, but also to obtain certification. Emerging EU General Data Protection Regulation (GDPR) and similar requirements for companies to obtain consent when storing or using personal information are creating a need for certified identity products.

Although OAuth is about authorization and should be loosely coupled to identity management, it also has important integration points to OIDC and SCIM [System for Cross-Domain Identity Management]. OIDC is built on OAuth and OAuth servers can use it to obtain user information, session information, and authentication context for use in authorization decisions. SCIM endpoints – enabling organizations to provision and synchronize user information to or from internal directories, databases, and/or SaaS systems – can themselves be protected by OAuth.

System Hardening / Tuning Layer

Over the years, both OAuth and SAML have been criticized for their use of “bearer tokens” that – if captured by a man in the middle (or browser) attack – could be used by cyberattackers to gain unauthorized access to protected resources. The community has sought to minimize such exposure by disseminating best practices for protecting implementations (e.g., using HTTPS to transfer any access tokens), and by building mechanisms into the system to minimize the time a “hot potato” bearer token can be requested by an authorized client (i.e., using intermediate ephemeral tokens or artifacts).

The venerable RFC 6819 Oauth Threat Model and Security Considerations should be required reading for anyone implementing an OAuth authorization server, resource server, or other identity “system” components. The fact of the matter is that much of the Internet that users see today is running on SAML and OAuth bearer tokens; these tokens tend to get the job done well-enough for most low to medium assurance application requirements.

What if we could replace bearer tokens with tokens that are cryptographically-bound to the authorized user and only that user? Tokens that carry within themselves a piece of data signed by the user’s private key, or proof of possession? What if the IETF token binding mechanisms that can lock a TLS session to particular servers could be leveraged in OAuth exchanges? RFC 7636, 7800, and some Internet Drafts continue to work in this area. Solutions may soon be available for customers that have higher-assurance requirements and are willing to accept some functionality tradeoffs.

Call to Action

As we wrote months ago in the Second Golden Age of Identity post, IAM is changing rapidly. We need a modern set of standards and architectures to enable diverse users, devices, resources, and applications to be secured and controlled in consistent ways. The identity standards community is working hard to create this stack. We’re grateful to Pam Dingle for helping make sense of it, and we’re trying to do our bit by getting the word out. To learn more, check out Pam’s webinar and see our glossary of Internet Identity Standards inspired by this work.

Questions? Contact us anytime for advice on how to assess requirements, modernize your IAM systems, or help with other IAM architecture projects.

The post The OAuth Standards Stack: An Architectural Perspective appeared first on Security Architects Partners.