The server-side single sign-on (SSO) feature allows multiple mobile apps on a device to share a single user session that resides on the OAM server and not with the client.
This feature saves JWT and OAM user tokens in the Server-Side Device Store, and maintains the user session in the browser with cookies. Thus, the server session is not tied to the client. Session time-out values are configurable at the Service Profile level for the client token, user token, and access token. The access token time-out value can also be overridden at the Resource Server level.
Keeping sensitive session info on the server (and not on the device) reduces the risk of the tokens being copied if the device or client app is compromised. For 2-legged flows, if server-side single sign-on is turned off (it is on by default), the user token is not stored on the server but sent to the client on the mobile device. You can enable and disable this feature using the Mobile OAuth Services Service Profile configuration page. For 3-legged flows, server-side single sign-on is always automatically enabled.
Developers in your organization can implement single sign-on in a client app by using an external browser, an embedded browser, or by using a native app registered with Mobile and Social Services as an SSO proxy.
This section briefly discusses the different approaches.
The mobile app switches to an external browser, which executes the logic for user authentication and user consent management.
A shared browser cookie maintains the user session and can be used to provide SSO across multiple apps. The external browser uses a typical Web SSO mechanism that supports OAM user authentication, JWT user authentication, third-party user authentication, and social authentication (using the Social Identity service). One drawback to using an external browser is the screen “flickering" that occurs when the application context switches between the browser and the application.
The mobile app uses its own embedded browser. Because the browser cookie cannot be shared across multiple apps, OAM and third-party user authentication cannot be used.
Instead, Mobile OAuth Services uses a JWT user session token stored in the Server-Side Device Store. When additional apps are launched, SSO is established using device identification together with the shared JWT user session token. The embedded browser approach eliminates the screen “flickering" that occurs when the application context switches between the application and the external browser (as discussed in External Browser Approach).
If a native app is already installed on the device, it can facilitate SSO by serving as a proxy between the browser-based app and the Mobile OAuth Services SSO Servlet on the OAM server.
As needed, the Servlet registers the device and app with OAM and obtains the tokens required to authenticate the app in the browser so that it can access the OAM-protected resource. To use this approach, native apps must use Mobile and Social Services to authenticate with Access Manager. This approach can be used for 2-legged flows.
Users log in once and gain access to all systems without being prompted to log in again. For JWT, third-party, and social authentication, the OAM server stores the user token in the Device Store, whereas OAM authentication stores the OAM_ID (representing an OAM session) in the Device Store. When the user token or OAM_ID expires, the user is prompted to log in again.
When implementing mobile 3-legged scenarios, enable the Authorization Code grant type by going to the Mobile OAuth Services Clients configuration page in the Oracle Access Management Console. Apps should implement the mobile 3-legged flows documented in the Oracle Fusion Middleware Developer's Guide for Oracle Access Management.
Apps that use a Mobile OAuth Services 3-legged scenario should collect credentials using a mobile browser (as discussed in Understanding the Server-Side Single Sign-On Credential Collection Options). To specify an authentication type using the Oracle Access Management Console, open the Mobile OAuth Services Service Profile configuration page and under Mobile Service Settings, choose an option for Consent Service Protection. The following sections describe these options.
OAM Authentication or Third-Party Access Management
If using OAM authentication or Third-Party Access Management, Access Manager (or a third-party access management product) is responsible for user authentication. Any OAM authentication method that supports login through the browser is an option. Because Access Manager supports SSO using an OAM_ID cookie, this flow must use an external browser (as discussed in External Browser Approach). Following authentication, the user token is stored in the Server-Side Device Store.
Oracle Access Management supports session synchronization so that 2-legged flows can get OAM tokens later. For example, the first app registers with the server using the 3-legged flow. Next, a second app completes the 2-legged registration using the existing session established by the first app. Thus a 3-legged flow session can register additional apps using a 2-legged flow by using the same session created during the first app registration.
JWT Authentication
JWT authentication is an authentication mechanism provided by Mobile and Social for mobile applications. In this case, Mobile and Social hosts the user interface for user login. It accepts a user name and password for authentication, using the configured user store for user authentication. The user store can be configured in Mobile and Social or in Oracle Access Management. It is configured using the User Authenticator under User Store in OAuth Services profile.
As discussed previously, JWT user authentication is the only authentication type that supports single sign-on using an embedded browser. (If the ability to use multiple apps on the same mobile device is not a requirement, then either OAM authentication or third-party authentication is sufficient.) JWT authentication can also be used with external browsers, but the application will need to switch from the app to the browser and back again when Mobile and Social checks the user token in the Device Store for single sign-on.
Social Authentication
Social authentication allows app users to authenticate using social identity providers such as Facebook and Twitter. This type of authentication requires the Oracle Access Management Social Identity service (part of Mobile and Social). If using social authentication, the Oracle Access Management server redirects the user to the social identity provider for authentication. For single sign-on, an external browser is required. Following authentication, the user token is stored in the Server-Side Device Store. Social Authentication is supported for 3-legged flows only.
Apps that use Mobile OAuth Services 2-legged scenarios should collect user credentials using the native iOS or Android user interface although you are limited to username/password-based OAM authentication or IDS (directory server).
By switching to an external browser, you can use the usual supported authentication schemes, including OAM user authentication, third-party authentication, and JWT user authentication.
Unlike with mobile 3-legged scenarios, you can choose to disable the server-side single sign-on feature with mobile 2-legged scenarios. To disable it, open the Mobile OAuth Services Service Profile Configuration page and clear the Enable Server-Side Single Sign-On option. (Server-Side SSO can also be set using WLST.)
If Server-Side SSO is enabled, the server collects user credentials on behalf of the client and provides SSO. Additional apps (that is, apps that share the same device profile) have to register with the server the first time they are launched. You can require the user to authenticate every time an app is registered, or you can allow the registration to happen automatically in the background without involving the user. Configure the msAlwaysShowLogin attribute on the Service Profile page to select the desired behavior.
If the msAlwaysShowLogin Service Profile attribute is set to true, the user has to enter a user name and password in the native app to register the app and get a client token.
If the attribute is set to false, the server automatically registers apps using the server-side user token.
Once registered, subsequent access requests from apps on the device typically result in the server providing a client token and allowing access. (In some cases the user may not get access right away—for example, if Oracle Adaptive Access Manager rules are active.)
If Server-Side SSO is disabled, the client collects the user credentials and must also provide SSO. On a first access attempt the user enters a user name and password in the native app to register the device. The server returns a user token that the device stores locally. Subsequent access requests from apps on the device must use the stored user token to register the apps and gain access.
For mobile 2-legged scenarios, enable the Resource Owner grant type by going to the Mobile OAuth Services Clients configuration page in the Mobile Oracle Access Management Console. Apps should implement the mobile 2-legged flows documented in the Oracle Fusion Middleware Developer's Guide for Oracle Access Management. The following sections give an overview of SSO options.
If a user using a mobile browser (external or embedded) needs to access a protected Web resource, and there is a native app that uses Mobile and Social Services to authenticate with OAM already installed on the device, the native app can register the device on behalf of the Web app and gain access to the resource without requiring the user to sign on.
This single sign-on approach utilizes the OAuth Mobile SSO Servlet that was added to the OAM server in release 11.1.2.3. For configuration steps, see Configuring Mobile OAuth for SSO Servlet Authentication.
Another alternative utilizing a native app and an app running in an external browser is to implement 2-legged flows in the native app using the OAuth Services REST API.
Server-side SSO can be enabled or disabled. The native app registers the device and user, and exchanges an OAM token to get an OAM_ID cookie (which is the OAM master token). The native app can then launch the external browser and inject the OAM_ID cookie so that users accessing WebGate-protected resources with an external browser will not be prompted to log in every time. For information about implementing the 2-legged flows, see the Oracle Fusion Middleware Developer's Guide for Oracle Access Management.