In this article we go over two typical use cases for SSO on mobile devices.
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 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.
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
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.
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.
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.
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 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.
Learn MoreLearn how to integrate OpenID Connect for mobile SSO
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.
With the Curity Identity Server, 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.
The Curity Identity Server 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.
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 the Curity Identity Server, this is automatically enabled through the configuration.
In the Curity Identity Server 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.
In the Curity Identity Server, 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 the Curity Identity Server. 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.
Not only does the Curity Identity Server support SSO but it also supports all single logout mechanisms defined in the OpenID Connect standard, giving you the perfect tools for ensuring that SSO is securely cleaned up.
For more information, see the Curity Developer Portal.