SSO for mobile with OpenID Connect
Use cases for mobile SSO
In this article we go over two typical use cases for SSO on mobile devices.
SSO - Single Sign-On¶
Single sign-on - SSO - is an authentication process that allows users or clients to log in to one domain and thereby be provided automatic authentication to another domain without further interaction.
Single sign-on allows for continuous use of multiple connected independent or related systems or services. The user identity is maintained across the system and the user is assigned roles and permissions according to the different system settings.
The process ensures that the authenticated session is stored and passed seamlessly between involved services in order to provide access, although the user may be asked to provide consent for new resources in some cases.
Since different services may require different authentication mechanisms, single sign-on also ensures that only systems with the same requirements utilize the authenticated session.
The benefits of SSO¶
The main benefit of using SSO is that users can move quickly, yet still securely, between applications and services.
With SSO, the user is authenticated for an entire session for all authorized resources. This provides better user experience with fewer authentication prompts.
The applications benefit from this since many applications can act as a single application as the user moves back and forth without noticing that authentication is performed silently.
SSO For Mobile¶
In the mobile world, although the basic need is to allow a single user to move across domains, the mobile use cases for SSO are slightly different, and largely fall into the following categories;
- from web to app
- from app to web
- from app to app
- from to device
Web to App¶
In the web to app scenario, the user performs login in a browser, and authentication establishes a SSO Session which is shared to a mobile app.
App to Web¶
In the app to web scenario, the user is logged in to an app and opens a link to a web application. The user should be automatically logged in to that web application since it is already logged in to the app.
App to App¶
It is also possible to share the SSO session between apps, for example when the same organization has interacting apps and desire that the user login once and be logged in to all apps.
Web/App to Device¶
An increasingly important use case for SSO is to allow a user to sign in on the web or a mobile/tablet device in order to access services on a smart TVs, wearables or more generally the Internet of Things.
OpenID Connect for Mobile¶
OpenID Connect was designed from the beginning to allow for mobile use. By following the core standard the above use-cases can be solved. The last use-case Web/App to Device is solved by using an additional OAuth standard called the Device Flow.
On mobile, this is compounded, since mobile apps are not websites. Both iOS and Android apps are separate packages outside of the web context, which interferes with many standard techniques for SSO, since sharing of local storage is not allowed or strictly limited.
With OpenID Connect, SSO works by having the first session be opened in a browser user agent, which forwards the authentication request, allowing the local data to be shared.
The Curity Solution¶
With Curity, you get a Single Sign-On solution with all the benefits of the OpenID Connect standard, but also offers expanded features based on these standards, with a clearly implemented Neo-Security Architecture.
Curity does provide the standard OpenID Connect benefits for SSO, but also enables a range of other options that further improve the SSO experience and security.
The unified experience¶
Since you are sharing the SSO session between domains, it makes sense to also make that clear to the user through a unified user experience. In Curity, this is automatically enabled through the configuration.
Define the data¶
In Curity you can define in detail not only how to share the SSO session, but also specify which other data to share, allowing for differentiated security based on which client is making requests.
Embeddable OpenID Connect¶
In Curity, it's possible to run an OpenID Connect flow in a secure iframe. This means that the frame is only embeddable from the sites that have been pre-configured in Curity. Any other attempt to embed the frame will cause the frame to not load or to break out.
This makes it possible for organizations keep the user on the same site even when authenticating.
For more information, see the Curity Developer Portal.