JOIN OUR BLOG BLOG

STAY AT THE CENTER OF IDENTIVERSE


Sometimes, Standards Aren’t Enough

Whether through merger or acquisition, bringing together two companies with different identity systems is a huge challenge. To make matters more complicated, you need to address web apps and mobile apps differently. Leveraging standards can help solve and smooth over the technology consolidation issues, but they’re not always enough. In this post, I’ll share what we did at Oath, show how we leveraged standards to solve the problem. And I’ll end with some advice you can use if you face a similar situation.

Identity standards have been a critical part of the Internet ecosystem over the last 20+ years. From single-sign-on and identity federation with SAML; to the newer Identity protocols including OpenID Connect, OAuth2, JOSE, and SCIM; to the explorations of “self-sovereign identity” based on distributed ledger technologies; standards have long played a key role in providing a secure identity layer for the Internet.

As these standards evolve and the security best practices with them, the body of knowledge of how to apply these standards increases. Today, with the current RESTful stack of OAuth2, OpenID Connect and JOSE, that body of knowledge is still being built. The standards provide a framework and direction for solving common (and not-so-common) use cases. But they don’t speak to every situation.

Assuming that a secure identity layer should be ubiquitous and available to all consumers of the Internet, there’s still a lot of work to be done in documentation of best practices, use case success stories and new specifications. But before diving into one such use case, I want to say how important it is to have someone on the team who’s passionate about identity standards and is allocated time to learn and gain a grasp of the current state of the identity standards landscape.

There’s a lot of work already completed, and it’s so important to research and understand what’s available in order to make the best design decision possible.

As we worked on technology consolidation between AOL and Yahoo, one use case that we encountered at Oath was the issue of moving from two existing identity systems into a single identity platform for Oath to support all its brands. As part of this technology consolidation, we needed to migrate users from one identity platform to the new platform. For most desktop (e.g., browser) use cases, this doesn’t present a huge problem. Some DNS magic and HTTP redirects and the user will login at the correct endpoint. Also it’s expected for users accessing services via their browser to have to login now and then.

However, for mobile applications, it’s a completely different story. The normal user pattern for mobile apps is for the user to login (via OpenID Connect or OAuth2) and for the app to then be issued long-lived tokens (well, the refresh token is long lived) and the user never has to login again on the device (entering a password on the device is NOT a good experience for the user).

So the issue is, how do we allow the mobile app to move from one identity provider to another without the user having to re-enter their credentials? The solution came from researching the above “Standards Landscape” and finding the OAuth 2.0 Token Exchange draft specification (https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-13).

The Token Exchange draft allows for a given token to be exchanged for new token(s) in a different domain. For example, this could be used to manage the “audience” of a token that needs to be passed among a set of microservices to accomplish a task on behalf of the user. For this use case, we profiled the Token Exchange specification to allow the refresh token from the originating IdP to be exchanged for new tokens from the consolidated IdP. By profiling this draft standard, we were able to create a much better user experience for our consumers and do so without inventing proprietary mechanisms.

Reflecting on the final solution, a key lesson learned from the effort is that a good understanding of the “standards landscape” is critical for resolving these kinds of use cases. I’ll cover this use case and others in my talk at Identiverse, “When Standards Don’t Suffice”.

I hope to see you there!

 

By George Fletcher

Identity Standards Architect, Oath

View More Posts

Leave a Reply

Your email address will not be published. Required fields are marked *