Introduction In the realm of the web, it’s common to seamlessly transition between different web applications without the need to repeatedly input our user credentials. Take, for instance, the scenario where we’re on our bank’s website and wish to access our rewards points. When the bank’s website redirects us to the rewards point platform hosted by a third-party application, we’re not prompted to enter any login details. This seamless access experience is what’s commonly known as single sign-on (SSO). In its simplest terms, single sign-on (SSO) entails signing in just once using your credentials and thereafter, gaining access to other web applications without the hassle of re-entering your login information. The initial web application where you logged in with your credentials employs certain techniques to facilitate this seamless access across different web applications. In this article, the focus is on different SSO techniques across channels (browser and mobile app) using modern Identity and Access Management (IAM) technology, Okta. Scope There are primarily two industry-approved solution mechanisms to implement SSO — Security Assertion Markup Language (SAML) and OAuth-OIDC. OAuth-OIDC is the newer pattern out of these two, while SAML is something that has existed for decades. There are several technologies that are available to facilitate SSO — this includes Ping Identity, Azure Active Directory, Okta, Auth0, etc. This article demonstrates how using Okta SSO can be accomplished across web applications and mobile devices. For each of the scenarios described below, a configuration app needs to be created in the Okta admin console to import service provider (SP) metadata information and also to share identity provider (IDP) Okta’s metadata information with a service provider (SP). The reference links provided below from the Okta website cover that. This documentation skips that generic IDP-SP SAML metadata exchange part and focuses on the actual process flow for each of the use cases. Likewise, the metadata configuration in the SP website or the configuration of the OAuth-OIDC app is also skipped. In the following sections, we will discuss Okta-based SSO techniques for 3 common use cases. Website → Website SSO using SAML
Native Mobile App → Website using SAML
Native Mobile App → Native Mobile App using OAuth-OIDC Website → Website SSO using SAML Native Mobile App → Website using SAML Native Mobile App → Native Mobile App using OAuth-OIDC Website → Website SSO Using SAML In this approach, the user first logs in to the identity provider website (e.g., your bank). After that, the user clicks on a link/tab/button on the website to access a different website (e.g., rewards point website) in a new browser tab or within the webpage of the main website through an embedded iFrame. User launches the identity provider website login page. The identity provider website displays the Okta widget as the login page.
User enters user ID/password. The credentials are validated by Okta, and Okta issues a session cookie in the browser.
User clicks on a link/tab/button to access the service provider website.
The service provider website makes a request to Okta, asking to provide information about the user making the request. The request is sent in the form of SAML.
Okta validates the issuer of the SAML request by checking the signature. Then it looks for a session cookie in the browser. If found, Okta checks for the validity of the cookie, extracts the user information, and prepares a SAML response for a service provider. Okta passes the user information as part of the SAML response payload.
The service provider website validates the issuer of the SAML response by checking the signature. After that, it extracts the user information from the SAML payload, looks for the presence of the user in its own user repository, and if the user is found, it presents the webpage in the browser. User launches the identity provider website login page. The identity provider website displays the Okta widget as the login page. User enters user ID/password. The credentials are validated by Okta, and Okta issues a session cookie in the browser. User clicks on a link/tab/button to access the service provider website. The service provider website makes a request to Okta, asking to provide information about the user making the request. The request is sent in the form of SAML. Okta validates the issuer of the SAML request by checking the signature. Then it looks for a session cookie in the browser. If found, Okta checks for the validity of the cookie, extracts the user information, and prepares a SAML response for a service provider. Okta passes the user information as part of the SAML response payload. The service provider website validates the issuer of the SAML response by checking the signature. After that, it extracts the user information from the SAML payload, looks for the presence of the user in its own user repository, and if the user is found, it presents the webpage in the browser. Native Mobile App → Website SSO Using SAML This is a special access pattern. In this case, the user has logged in to a mobile app (e.g. bank’s native mobile app). However, the web app they want to access (e.g., rewards points) does not have a native mobile app. In that case, the SSO needs to happen from the mobile app to a browser-based web application. To enable single sign-on (SSO), the identity provider mobile app initiates the process by launching an embedded browser web-view within the mobile app itself. This embedded browser facilitates the SSO process, seamlessly connecting the user from the mobile app to the browser-based web application. User opens mobile app. Mobile app displays native mobile login screen.
User enters user ID/password. The credentials are validated by Okta. In this case, Okta API is used as the login screen and is custom-developed and not a browser-based Okta sign-in widget.
The mobile app also uses the credentials to generate a session token. The session token will later be used to generate a session cookie to facilitate single-sign-on. This is the key step to facilitate the single-sign-on from a native mobile app to a website.
Okta issues ID/access/refresh tokens after successful authentication. The mobile app stores the session token in the context of the user session or cache for later use.
The user now clicks a link/tab/button in the mobile app to access the service provider website.
Mobile app launches an embedded mobile browser web-view and uses the session token from cache to generate a session cookie in the web-view. After that mobile app launches the service provider website in web view.
The rest of the steps are the same as documented above for the website-to-website SSO process. Repeating the same to makes it easier for the readers to follow.
The service provider website makes a request to Okta, asking to provide information about the user making the request. The request is sent in the form of SAML.
Okta validates the issuer of the SAML request by checking the signature. Then it looks for a session cookie in the browser. If found, Okta checks for the validity of the cookie, extracts the user information, and prepares a SAML response for the service provider. Okta passes the user information as part of the SAML response payload.
The service provider website validates the issuer of the SAML response by checking the signature. After that, it extracts the user information from the SAML payload, looks for the presence of the user in its own user repository, and if the user is found, it presents the webpage in the browser. User opens mobile app. Mobile app displays native mobile login screen. User enters user ID/password. The credentials are validated by Okta. In this case, Okta API is used as the login screen and is custom-developed and not a browser-based Okta sign-in widget. The mobile app also uses the credentials to generate a session token. The session token will later be used to generate a session cookie to facilitate single-sign-on. This is the key step to facilitate the single-sign-on from a native mobile app to a website. Okta issues ID/access/refresh tokens after successful authentication. The mobile app stores the session token in the context of the user session or cache for later use. The user now clicks a link/tab/button in the mobile app to access the service provider website. Mobile app launches an embedded mobile browser web-view and uses the session token from cache to generate a session cookie in the web-view. After that mobile app launches the service provider website in web view. The rest of the steps are the same as documented above for the website-to-website SSO process. Repeating the same to makes it easier for the readers to follow. The service provider website makes a request to Okta, asking to provide information about the user making the request. The request is sent in the form of SAML. Okta validates the issuer of the SAML request by checking the signature. Then it looks for a session cookie in the browser. If found, Okta checks for the validity of the cookie, extracts the user information, and prepares a SAML response for the service provider. Okta passes the user information as part of the SAML response payload. The service provider website validates the issuer of the SAML response by checking the signature. After that, it extracts the user information from the SAML payload, looks for the presence of the user in its own user repository, and if the user is found, it presents the webpage in the browser. Native Mobile App → Native Mobile App SSO using OAuth-OIDC In this particular use case, the objective is to achieve single sign-on (SSO) from one native mobile app to another native mobile app on a mobile device. Unlike the previous scenarios where SAML was utilized for SSO, this approach relies on the OAuth-OIDC pattern. The assumption is, the service provider's native mobile app is also already installed on the mobile device of the user.
The user opens the identity provider mobile app. Mobile app displays native mobile login screen.
User enters user ID/password. Mobile app gets the credentials validated by Okta using the Okta API. In this case, the mobile app makes the request with scope device_sso. This is a key difference in authentication compared to the previous scenario, where the native mobile app SSO is performed on a website.
Okta issues ID/access/refresh tokens and also a device secret. The device secret is stored in the mobile device.
User clicks a link/tab/button in the identity provider mobile app to access the service provider mobile app.
The service provider mobile app is launched, and the app retrieves the ID token and device secret from the storage of the mobile device.
The service provider mobile app sends the ID token and device secret to Okta to get an access token to allow the requester to access the service provider app.
Okta verifies the device secret, extracts the user information from the ID token, and issues an access token and a refresh token for the user.
Service provider app grants access. The assumption is, the service provider's native mobile app is also already installed on the mobile device of the user. The user opens the identity provider mobile app. Mobile app displays native mobile login screen. User enters user ID/password. Mobile app gets the credentials validated by Okta using the Okta API. In this case, the mobile app makes the request with scope device_sso. This is a key difference in authentication compared to the previous scenario, where the native mobile app SSO is performed on a website. Okta issues ID/access/refresh tokens and also a device secret. The device secret is stored in the mobile device. User clicks a link/tab/button in the identity provider mobile app to access the service provider mobile app. The service provider mobile app is launched, and the app retrieves the ID token and device secret from the storage of the mobile device. The service provider mobile app sends the ID token and device secret to Okta to get an access token to allow the requester to access the service provider app. Okta verifies the device secret, extracts the user information from the ID token, and issues an access token and a refresh token for the user. Service provider app grants access. Conclusion Even though single sign-on (SSO) has existed in web platforms for decades, the techniques of implementation are evolving with the emergence of new solution providers as well as the need to implement such a solution across various web access channels (browser and native mobile app). In this article, we demonstrated techniques on how to implement SSO across browser-based websites and native mobile apps using the modern identity & access management solution Okta. References https://developer.okta.com/docs/guides/build-sso-integration/saml2/main/
https://help.okta.com/en-us/content/topics/apps/apps-about-saml.htm?cshid=ext-apps-about-saml
https://developer.okta.com/docs/guides/configure-native-sso/main/
https://developer.okta.com/docs/guides/session-cookie/main/
https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Session/ https://developer.okta.com/docs/guides/build-sso-integration/saml2/main/ https://developer.okta.com/docs/guides/build-sso-integration/saml2/main/ https://help.okta.com/en-us/content/topics/apps/apps-about-saml.htm?cshid=ext-apps-about-saml https://help.okta.com/en-us/content/topics/apps/apps-about-saml.htm?cshid=ext-apps-about-saml https://developer.okta.com/docs/guides/configure-native-sso/main/ https://developer.okta.com/docs/guides/configure-native-sso/main/ https://developer.okta.com/docs/guides/session-cookie/main/ https://developer.okta.com/docs/guides/session-cookie/main/ https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Session/ https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Session/

The Patterns of Single Sign-On Using Okta

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Why Your Browser Knows What You Want Before You Do: A Deep Dive Into Caching

A Tour of API Underprotection

The Rise of DID Authorization Mechanism in Client-Server Model

Adapting OAuth2 for Internet of Things (IoT) API Security

Adding OAuth2 to Mobile Android and iOS Clients Using the AppAuth SDK

Why Your Browser Knows What You Want Before You Do: A Deep Dive Into Caching

A Tour of API Underprotection

The Rise of DID Authorization Mechanism in Client-Server Model

Adapting OAuth2 for Internet of Things (IoT) API Security

Adding OAuth2 to Mobile Android and iOS Clients Using the AppAuth SDK

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps