<p><a href="https://yahoodevelopers.tumblr.com/post/175238617378/innovating-on-authentication-standards" class="tumblr_blog">yahoodevelopers</a>:</p><blockquote> <p>By George Fletcher and Lovlesh Chhabra </p> <p>When Yahoo and AOL came together a year ago as a part of the new Verizon subsidiary Oath,  we took on the challenge of unifying their identity platforms based on current identity standards. 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 name a few); to the explorations of “self-sovereign identity” based on distributed ledger technologies; standards have played a key role in providing a secure identity layer for the Internet.</p> <p>As we navigated this journey, we ran across a number of different use cases where there was either no standard or no best practice available for our varied and complicated needs. Instead of creating entirely new standards to solve our problems, we found it more productive to use existing standards in new ways. </p> <p>One such use case arose when we realized that we needed to migrate the identity stored in mobile apps from the legacy identity provider to the new Oath identity platform. For most browser (mobile or desktop) use cases, this doesn’t present a huge problem; some DNS magic and HTTP redirects and the user will sign in at the correct endpoint. Also it’s expected for users accessing services via their browser to have to sign in now and then.</p> <p>However, for mobile applications it’s a completely different story. The normal user pattern for mobile apps is for the user to sign in (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 sign in again on the device (entering a password on the device is NOT a good experience for the user).</p> <p>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 what standards currently exist that might addres this use case (see figure “Standards Landscape” below) and finding the OAuth 2.0 Token Exchange draft specification (<a href="https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-13">https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-13</a>).</p> <p><a href="https://s.yimg.com/cv/api/YahooMail_MobileWeb_US/transcoded/image2.jpg"></a></p> <a href="https://s.yimg.com/cv/api/YahooMail_MobileWeb_US/transcoded/image2.jpg"><figure class="tmblr-full" data-orig-height="1125" data-orig-width="1999" data-orig-src="https://s.yimg.com/cv/api/YahooMail_MobileWeb_US/transcoded/image2.jpg"><img src="https://66.media.tumblr.com/5dd024c4183ef2e478c14cd74a7e1574/tumblr_inline_pavti6CjC81rgj0aw_540.jpg" alt="image" data-orig-height="1125" data-orig-width="1999" data-orig-src="https://s.yimg.com/cv/api/YahooMail_MobileWeb_US/transcoded/image2.jpg"/></figure></a><p>The Token Exchange draft allows for a given token to be exchanged for new tokens in a different domain. 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, as an example. For the use case at hand, we created a specific implementation of the Token Exchange specification (a profile) to allow the refresh token from the originating Identity Provider (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.</p> <p>During this identity technical consolidation we also had to address how to support sharing signed-in users across mobile applications written by the same company (technically, signed with the same vendor signing key). Specifically, how can a signed-in user to Yahoo Mail not have to re-sign in when they start using the Yahoo Sports app? The current best practice for this is captured in OAuth 2.0 for Natives Apps (<a href="https://tools.ietf.org/html/rfc8252">RFC 8252</a>). However, the flow described by this specification requires that the mobile device system browser hold the user’s authenticated sessions. This has some drawbacks such as users clearing their cookies, or using private browsing mode, or even worse, requiring the IDPs to support multiple users signed in at the same time (not something most IDPs support).</p> <p>While, RFC 8252 provides a mechanism for single-sign-on (SSO) across mobile apps provided by any vendor, we wanted a better solution for apps provided by Oath. So we looked at how could we enable mobile apps signed by the vendor to share the signed-in state in a more “back channel” way. One important fact is that mobile apps cryptographically signed by the same vender can securely share data via the device keychain on iOS and Account Manager on Android.</p> <p>Using this as a starting point we defined a new OAuth2 scope, <i>device_sso</i>, whose purpose is to require the Authorization Server (AS) to return a unique “secret” assigned to that specific device. The precedent for using a scope to define specification behaviour is OpenID Connect itself, which defines the “openid” scope as the trigger for the OpenID Provider (an OAuth2 AS) to implement the OpenID Connect specification. The device_secret is returned to a mobile app when the OAuth2 code is exchanged for tokens and then stored by the mobile app in the device keychain and with the id_token identifying the user who signed in.</p> <p>At this point, a second mobile app signed by the same vendor can look in the keychain and find the id_token, ask the user if they want to use that identity with the new app, and then use a profile of the token exchange spec to obtain tokens for the second mobile app based on the id_token and the device_secret. The full sequence of steps looks like this:</p> <p><a href="https://s.yimg.com/cv/api/default/20180625/image1.png"></a></p> <a href="https://s.yimg.com/cv/api/default/20180625/image1.png"><figure class="tmblr-full" data-orig-height="893" data-orig-width="802" data-orig-src="https://s.yimg.com/cv/api/default/20180625/image1.png"><img src="https://66.media.tumblr.com/861136619c641fd03a33f97d208b7e5d/tumblr_inline_pavti7IbMJ1rgj0aw_540.png" alt="image" data-orig-height="893" data-orig-width="802" data-orig-src="https://s.yimg.com/cv/api/default/20180625/image1.png"/></figure></a><p>As a result of our identity consolidation work over the past year, we derived a set of principles identity architects should find useful for addressing use cases that don’t have a known specification or best practice. Moreover, these are applicable in many contexts outside of identity standards:</p> <ol><li>Spend time researching the existing set of standards and draft standards. As the diagram shows, there are a lot of standards out there already, so understanding them is critical.</li> <li>Don’t invent something new if you can just profile or combine already existing specifications.</li> <li>Make sure you understand the spirit and intent of the existing specifications.</li> <li>For those cases where an extension is required, make sure to extend the specification based on its spirit and intent.</li> <li>Ask the community for clarity regarding any existing specification or draft.</li> <li>Contribute back to the community via blog posts, best practice documents, or a new specification.</li> </ol><p>As we learned during the consolidation of our Yahoo and AOL identity platforms, and as demonstrated in our examples, there is no need to resort to proprietary solutions for use cases that at first look do not appear to have a standards-based solution. Instead, it’s much better to follow these principles, avoid the NIH (not-invented-here) syndrome, and invest the time to build solutions on standards.</p> </blockquote>