Today, we have standards that define SSO protocols for browser-based applications. SAML is the most widely deployed standard in the enterprise world, working with browsers on any platform or device including mobile.
Separately, we are seeing adoption of OAuth 2.0 for access control for non-browser-based (or: native) mobile application scenarios. OAuth 2.0 is a protocol framework that defines how to secure APIs on the web, which include APIs to remote services that are accessed by native mobile applications.
There's an interesting scenario emerging here: how to achieve SSO between mobile applications and browser-based applications, when both are accessed from the same mobile device at the same time.
That particular question is coming up more and more with our customers these days. Users start out with a mobile app on a device and at some point they hit a URL in the app and a browser is launched to access that URL. Since the URL requires user authentication, they have to sign-in to the browser application again, separately and independently from the mobile application. The flow should better than that and it can be!
But there's a caveat: assuming that the native mobile application uses OAuth 2.0 we need to take into account that OAuth 2.0 is a protocol for delegated authorization. At some point in the past, a user has authorized an application to access an API on behalf of that user. Browser-based SSO is semantically quite different: the browser accesses web applications as the user. In the OAuth 2.0 scenario, the user is not present (or at least does not need to be logged in or present), while in the browser-based SSO scenario the user himself is present and logged in.
Thus bootstrapping browser-based SSO from delegated API access is not a trivial technical task. If the intent is to pass a token between native application and browser, there's a semantic difference between the two worlds and ignoring that difference could have severe security implications. So how do we cross that chasm?
First of all, we should realize that a native mobile application is indeed different from a generic OAuth 2.0 client. When a mobile device is in use, we can assume that the user is present even though not logged in per se. (I'm deliberately staying away from a discussion on stolen devices, PINs, app locks etc. because that is not specific to the problem at hand). So if we can ensure that a particular OAuth 2.0 client/app running on a mobile device on behalf of its owner can be identified as such, we can swap its OAuth 2.0 token for an SSO token without the risk of "elevation of rights" type of attacks.
OAuth 2.0 defines the concept of "scopes," which will allow us to complete such a swap in a secure way.
We can define an OAuth 2.0 scope that represents a "bootstrap login/SSO" capability. We can ensure (through proper user consent and client authentication mechanisms) that only authorized mobile applications can bootstrap user login to a browser because they are trusted to do so. [Note: for those already familiar with OAuth 2.0: mobile apps using the Resource Owner Password Credentials flow by definition are trusted to do so]
At Ping Identity, we have been working with partners and customers to solve this issue by passing on OAuth 2.0 tokens from mobile applications to browsers and converting them to SSO tokens via a so-called IDP adapter. George Fletcher, chief architect for identity services at AOL, discussed a variant that allows an OAuth 2.0 authorization server to create sessions for web applications. Of course, a standardized protocol is the best way forward and right now there are discussions on this topic happening in the relevant standardization bodies.