48.3 Understanding the Mobile and Social Services Processes

When a user tries to access a protected resource, Mobile and Social requires either a Client Token (if the user is connecting through a server or a computer which securely stores client credentials) or a Client Registration Handle (if the user is using a mobile device). Client devices (including mobile devices) and client applications must register with Mobile and Social before access to protected resources can be granted.

Note:

Applications are also typically configured to require a User Token and an Access Token.

Client applications running on mobile devices follow this high-level authentication process before the mobile application can access a protected resource.

1. The user enters a user name and password at the application login screen and authenticates with the Mobile and Social server.

2. If a mobile device has not previously registered with the Mobile and Social server, the server sends the mobile device a Client Registration Handle after authenticating the user.

3. The Client Registration Handle is submitted back to the Mobile and Social server to get a User Token.

4. The Client Registration Handle and User Token are submitted back to the Mobile and Social server to get an Access Token.

A non-mobile application can also make use of Authentication Services provided by Mobile and Social Services. In such cases, a Client Token takes the place of the Client Registration Handle. After the Client Token is obtained, a User Token and Access Token can be requested as documented above. Additional scenarios are documented in these sections.

• Registration Flow for a Mobile Device With User Authentication

• Authentication Flow for a User With a Registered Device

• Flow of REST Calls for User Authentication

• Authentication Flow for User With a Mobile Browser-Based Web App

• Authorization Using the Mobile OAuth Authorization Flow

48.3.1 Registration Flow for a Mobile Device With User Authentication

When the mobile device attempting to access a protected resource has not previously registered with Mobile and Social, a Mobile SSO Agent must be installed.

The registration authentication process is documented in the following flow. Figure 48-1 and Figure 48-2 follow the text and illustrate the process.

1. The user launches an application on a mobile device.

2. The application redirects the user to the Mobile SSO Agent.

3. The Mobile SSO Agent displays a login page.

4. The user enters a user name and password.

5. The Mobile SSO Agent sends the user name and password to the Mobile and Social server along with the device attributes and application ID.

6. The Mobile and Social server forwards the user name and password to Access Manager which authenticates the user.

7. The Mobile and Social server sends device attributes and other authentication results to the OAAM Mobile Security Handler Plug-in which executes the policy stored on the OAAM server.

   Note:

   OAAM has two registration flows—active and passive. The active flow prompts the user with a challenge before allowing the device registration process to proceed. The passive flow continues without challenging the user.

   The OAAM Security Handler Plug-in creates two security handles (snippets of data that Mobile and Social stores with either the Mobile SSO Agent or the business application itself). Each handle stores a name, value, and expiration timestamp.

   • The oaam.device handle represents the mobile device. (Different client applications on the same device all have the same device handle value.) OAAM uses this handle as a key to retrieve the full device profile stored in the OAAM database. This handle has a relatively long life span.

   • The oaam.session handle represents an OAAM login session for a client application. (Each client application on a device has a unique session handle value.) OAAM uses this handle as a key to retrieve details about the OAAM session stored in the OAAM database. When the user logs out from the client application, the oaam.session handle is removed.

8. The Mobile and Social server returns the Mobile Client Registration Handle and OAAM device and session handles to the Mobile SSO Agent.

9. The Mobile SSO Agent gets a User Token by passing the Client Registration Handle and OAAM device handles that it previously received to the server.

10. The Mobile SSO Agent requests an Access Token from Access Manager. The request contains the Client Registration Handle and OAAM device handles. See Figure 48-2.

Figure 48-1 First Time Device/Application Registration and Authentication Process

Description of "Figure 48-1 First Time Device/Application Registration and Authentication Process"

Figure 48-2 Mobile SSO Agent Requests Access Token from Access Manager

Description of "Figure 48-2 Mobile SSO Agent Requests Access Token from Access Manager"

48.3.2 Authentication Flow for a User With a Registered Device

When a user with a mobile device (already registered with Mobile and Social) is launching a Mobile and Social compatible business application, the Mobile SSO Agent is already installed and the user needs to access a protected resource that requires an Access Token.

The business application must first acquire the User Token before it can request the Access Token. The accompanying figures (Figure 48-3 and Figure 48-4) illustrate the process.

1. The user launches the business application on a mobile device.

2. The business application asks the Mobile SSO Agent for a User Token and one of the following occurs.

   1. If a valid User Token exists in the local credential store, the Mobile SSO Agent returns it to the business application. The business application inserts the User Token into a direct request to the Mobile and Social server for the Access Token. The flow completes when the business application uses the Access Token returned by the server to access the protected resource (as in Figure 48-3).

      Figure 48-3 Mobile SSO Agent Has Valid Access Token in Credential Store

      
      Description of "Figure 48-3 Mobile SSO Agent Has Valid Access Token in Credential Store"

   2. If a valid User Token does not exist in the local credential store, the login flow continues (as in Figure 48-4).

3. The Mobile SSO Agent presents a login page and the user enters a user name and password.

4. The Mobile SSO Agent sends the user name, password, and Client Registration Handle to the Mobile and Social server. (Step 2 in Figure 48-4).

5. The Mobile and Social server validates the Client Registration Handle, authenticates the user credentials (with either the JWT token service or the Access Manager token service), invokes OAAM for risk analysis and then returns the User Token to the Mobile SSO Agent. (Step 3 in Figure 48-4).

6. The Mobile SSO Agent stores a copy of the user token in its local credential store and returns the User Token to the business application. (Step 4 in Figure 48-4).

7. The business application uses the User Token to make a direct request to the Mobile and Social server for the Access Token. (This step is not shown in the diagram.)

8. The Mobile and Social server returns the Access Token to the Mobile SSO Agent.

9. The business application uses the Access Token to make calls to the resource protected by Access Manager or Oracle Enterprise Gateway (OEG). (Step 5 in Figure 48-4).

Figure 48-4 Mobile SSO Agent Does Not Have Valid Access Token in Credential Store

Description of "Figure 48-4 Mobile SSO Agent Does Not Have Valid Access Token in Credential Store"

48.3.3 Flow of REST Calls for User Authentication

An application running on a mobile device interfaces with the Mobile SSO Agent, which communicates with the Mobile and Social server using REST calls.

The server interfaces with Access Manager and OAAM as needed and returns the necessary tokens to the Mobile SSO Agent (again using REST calls). The agent forwards the tokens back to the application, which can now access the protected resource using either REST or SOAP calls. The process is documented in the following flow. Figure 48-5 follows the text and illustrates the process.

1. The user launches an application on a mobile device.

2. Because the client application needs to access a resource protected by Access Manager, the client application asks the Mobile SSO Agent for an Access Token.

3. The Mobile SSO Agent gets the Application Profile from the Mobile and Social server.

4. The Mobile SSO Agent prompts for a user name and password.

5. The Mobile SSO Agent sends the user name and password to the Mobile and Social server along with the device attributes and application ID.

6. The Mobile and Social server registers the device and authenticates the user.

7. The server returns an Access Token to the Mobile SSO Agent.

8. The Mobile SSO Agent saves the hashed password in its local credential store.

9. The Mobile SSO Agent passes the Access Token to the client application.

10. The client application accesses the protected resource by presenting the Access Token.

Figure 48-5 User Authentication Using REST

Description of "Figure 48-5 User Authentication Using REST"

48.3.4 Authentication Flow for User With a Mobile Browser-Based Web App

When a user with a Mobile and Social registered mobile device is launching a Mobile and Social compatible browser-based web application, the Mobile SSO Agent is installed.

The legacy authentication process is documented in the following flow. Figure 48-6 follows the text and illustrates the process.

1. The user opens a URL in a web browser on a mobile device.

2. The application web server redirects the browser to Access Manager.

3. Access Manager sends the web browser a URL redirect.

4. The web browser responds to the redirect by launching the Mobile SSO Agent.

   If the agent is not installed, a link with instructions to install the Mobile SSO Agent application is displayed.

5. The Mobile SSO Agent displays the User login page.

6. The user enters a user name and password.

7. The Mobile SSO Agent sends the user name, password, and Client Registration Handle to the Mobile and Social server. (This step is not shown in the diagram.)

8. The Mobile and Social server validates the Client Registration Handle, authenticates the credentials with Access Manager, publishes the ID context to the Access Manager server, and invokes OAAM for risk analysis.

9. Access Manager returns a User Token or an Access Token to the Mobile and Social server which, in turn, returns the User Token or the Access Token to the Mobile SSO Agent. (This step is not shown in the diagram.)

10. The Mobile SSO Agent directs the browser to the Mobile and Social server where it injects a cookie.

11. The Mobile SSO Agent sends the web browser a URL redirect and an Access Token.

12. The mobile web browser responds to the redirect and opens the original web URL because the access request now includes an Access Token.

13. The application web server sends the requested pages to the mobile web browser.

Figure 48-6 Authenticating User From Browser-based Web App on Registered Mobile Device

Description of "Figure 48-6 Authenticating User From Browser-based Web App on Registered Mobile Device"

48.3.5 Authorization Using the Mobile OAuth Authorization Flow

Interactions between a mobile app and the Oracle Access Management OAuth service in the context of Mobile and Social Services describe the Mobile OAuth authorization flow.

To understand the difference between the legacy authorization flow and the Mobile OAuth authorization flow, see Understanding the Mobile and Social Services Authorization Flow.

For a detailed look at the OAuth authorization flow in the context of the OAuth Service, see Understanding OAuth Services Authorization for Mobile Clients.

1. The mobile app requests a client verification code by sending a device token.

   The OAuth service returns the client verification code. If the APNS/GCM option is enabled, the OAuth service returns half of the code using push notification, and the other half over HTTPS. Push notification provides an extra level of assurance for confirming the identity of the application and device.

2. The mobile app requests an authorization code by sending device claims and the client verification code.

   The OAuth service:

   • Authenticates the user

   • Requests the user's consent to register the app (optional)

   • Invokes OAAM for risk analysis

   • Returns the authorization code using push notification (optional) and HTTPS

3. The mobile app requests a Client Token by sending the authorization code and device claims.

   The OAuth service returns the Client Token using push notification (optional) and HTTPS.

4. The mobile app requests an Access Token by sending the Client Token, the authorization code, and the device claims.

   The OAuth service returns the Access Token.

5. The mobile app requests access to the protected resources using the Access Token. (Not shown in the diagram.)

   The resource server returns the protected resources to the client application. (Not shown in the diagram.)

Figure 48-7

Description of "Figure 48-7 "