48.6 Understanding Social Identity Processes

Various flows govern the authentication scenarios involving the user, the Mobile and Social server (the relying party), and related parties:

48.6.1 Basic Flow for Social Identity Authentication

The following scenario documents the basic authentication process when using Social Identity.

  1. A user requests access to a protected resource and is redirected to Mobile and Social.

  2. Mobile and Social (RP) asks the user if they would like to log in using their credentials from, for example, Google (the Identity Provider).

  3. Mobile and Social redirects the user to a Google login page where a user name and password is entered.

  4. Google verifies the credentials and redirects the user back to Mobile and Social. At the same time the Identity Provider returns identity attributes to Mobile and Social based on its configuration.

    If the user does not have an account with your organization, the user can be prompted to register for one; the registration form will be prepopulated with the information that the Identity Provider returns.

Note:

In the case of Access Manager, a user MUST register locally, otherwise access is not given. If not using Access Manager, the user is redirected to the protected resource and allowed access even if they don't register. For details, see How Social Identity Works with Oracle Access Manager.

48.6.2 Authentication Flow for a Returning User With a Local Account

The local Identity repository determines that the user already has a local account. Consequently Mobile and Social does not prompt to create one.

This scenario describes the authentication flow between the User, the Mobile and Social server (the relying party), the Identity Provider, and the local user authentication service (represented by Local Auth and ID Repository in the diagram).Figure 48-8, following the text, illustrates the process.

  1. The user opens a URL for a protected resource in a web browser and the Mobile and Social server presents the user with a login page and a menu of Identity Providers (Google, Yahoo, Facebook, Windows Live, Foursquare, Twitter, or LinkedIn) from which to choose.

  2. The user chooses an Identity Provider.

  3. The Mobile and Social server redirects the user to the selected Identity Provider and a login page is displayed.

  4. The user enters a user name and password and, upon authentication, the Identity Provider sends the Mobile and Social server an authentication assertion.

  5. The Mobile and Social server checks with the Identity repository to see if the user has a local account.

    The Identity repository could be a directory server, a database, Oracle Identity Manager, or similar. The user is determined to be a User with a local account:

    • If a mobile application or a directly-integrated Web application is authenticating with Mobile and Social, the Mobile and Social server sends an authentication assertion to the user's browser.

    • If an application protected by Access Manger is authenticating, Access Manager creates the session for the user only if the user has a local account. (Newly registered users count as local account holders.)

  6. The user's browser sends the authentication assertion sent by Mobile and Social to the protected resource's Access Management Service.

  7. The Access Management Service carries out additional authentication steps as needed.

  8. The Access Management Service allows the user access to the protected resource.

Figure 48-8 Authenticating a Returning User with a Local Account

Description of Figure 48-8 follows
Description of "Figure 48-8 Authenticating a Returning User with a Local Account"

48.6.3 Authentication Flow for a New User With No Local Account

For a user who does not have a local account, the Mobile and Social prompts to create one.

This scenario describes the authentication flow between the User, the Mobile and Social server (the relying party), the Identity Provider, and the local User authentication service (represented by Local Auth and ID Repository in the diagram).Figure 48-9, following the text, illustrates the process.

  1. The user opens a URL for a protected resource in a web browser and the Mobile and Social server (RP in the diagram) presents the user with a login page and a menu of Identity Providers (Google, Yahoo, Facebook, Twitter, or LinkedIn) from which to choose.

  2. The user chooses an Identity Provider.

  3. The Mobile and Social server redirects the user to the selected Identity Provider which displays a login page.

  4. The user enters a user name and password and, upon user authentication, the Identity Provider sends the Mobile and Social server an authentication assertion.

  5. The Mobile and Social server checks with the Identity repository to see if the User has a local account.

    The Identity repository could be a directory server, a database, Oracle Identity Manager or similar. The user is determined to be a user who does not have a local account. Mobile and Social proceeds as follows:

    • If the Identity Provider uses the Open ID protocol, the Mobile and Social server retrieves the user's profile attributes by processing data in the previously obtained authentication assertion.

    • If the Identity Provider uses the OAuth protocol, the Mobile and Social server makes a separate HTTP call to the Identity Provider with the previously obtained Access Token to retrieve the user's profile attributes.

  6. The Mobile and Social server sends a new user registration form to the user's browser.

    The registration form is pre-populated with the user profile attributes sent by the Identity Provider in the previous step.

  7. The user completes the registration form and sends it to which interfaces with the user registry (either a directory server or Oracle Identity Manager) to create the account.

    In cases where an Access Token is retrieved from the Identity Provider, the Access Token is also returned to the client application by way of Mobile and Social.

  8. The Access Management Service for the client application carries out additional authentication steps as needed.

  9. The Access Management Service allows the user access to the protected resource.

Figure 48-9 Authenticating a New User with No Local Account

Description of Figure 48-9 follows
Description of "Figure 48-9 Authenticating a New User with No Local Account"

48.6.4 OAuth Flow For Access Token Retrieval

OAuth authentication and Access Token retrieval flow is between the User, the relying party, and OAuth Identity Provider. The server interfaces with the OAuth Identity Provider to get an authorization code and Access Token to access a resource protected by the OAuth Identity Provider.

This section provides supplemental detail about the OAuth authentication and Access Token retrieval flow between the User, the Mobile and Social server (the relying party), and an OAuth Identity Provider. (Facebook, Foursquare, and Windows Live use the OAuth 2.0 protocol, and LinkedIn and Twitter use the OAuth 1.0 protocol.) The Client application in this scenario could be either a Web application running on a Java-compliant application server, or a mobile application. Figure 48-10, following the text, illustrates the process.

  1. The user opens the client application which returns a protected web page to the user's browser.

  2. The user attempts to open the protected resource on the client application.

  3. The client application asks the Mobile and Social server for an Access Token so that the user can access the protected resource.

    If Mobile and Social has the valid Access Token in its cache, it will forward the Access Token to the client application and the authentication scenario would skip to step 10. This flow assumes Mobile and Social does not have the Access Token in its local cache.

  4. Because the Access Token is not in its local cache, on behalf of the user, Mobile and Social initiates an authorization request (utilizing HTTP headers to embed an OAuth Client ID, scope information, and a redirect URL) with the OAuth Identity Provider.

  5. The OAuth Identity Provider displays a login page.

  6. The user enters a user name and password into the OAuth Identity Provider login page and gives consent to the Identity Provider to provide the user's profile attributes to the Mobile and Social server (and, by extension, the client application).

  7. The OAuth Identity Provider sends an authorization code to the Mobile and Social server.

  8. The Mobile and Social server sends an Access Token request to the OAuth Identity Provider.

    Included in the request is the authorization code received in the previous step and the OAuth Client ID and client credential.

  9. The OAuth Identity Provider returns an Access Token to the Mobile and Social server.

  10. The Mobile and Social server caches the Access Token (with the User ID and the OAuth Client ID) and forwards the Access Token to the client application.

  11. The client application uses the Access Token to access the protected resource and returns the protected page to the user's browser.

Figure 48-10 Authenticating a User With an OAuth Identity Provider

Description of Figure 48-10 follows
Description of "Figure 48-10 Authenticating a User With an OAuth Identity Provider"

48.6.5 Authentication Flow for a User With Access Manager and Social Identity

The user must either have a local account or must register for a local account when prompted; otherwise Access Manager will not let the user access the protected resource and the User will be redirected to the login page.

This scenario describes the authentication process between the User, Access Manager, the Mobile and Social server (the relying party), and the Identity Provider. Figure 48-11, following the text, illustrates the process.

  1. The user attempts to open a protected resource on the client application.

  2. The WebGate protecting the resource intercepts the access request.

  3. Access Manager identifies the authentication policy protecting the resource and redirects the user to a login page provided by the Mobile and Social server.

  4. The login page presents a menu of Social Identity Providers.

  5. The user chooses an OpenID Identity Provider and Access Manager redirects the user's browser to the Mobile and Social server, which redirects the user's browser to the login page for the selected Social Identity Provider (Google, Facebook, Twitter, and so on).

  6. The user types a user name and password into the Social Identity Provider's login page.

    The Identity Provider completes the authentication process and requests the User's consent to share Identity information (if applicable).

  7. When authentication is complete, the Social Identity Provider redirects the browser back to the Mobile and Social server.

    After further processing of Identity assertions supplied by the Identity Provider and after retrieving user identity information, the Mobile and Social server redirects the user's browser to Access Manager. This time HTTP headers in the page request provide Access Manager with the user's authentication status and attributes.

  8. Access Manager creates a user session and redirects the user to the protected resource.

Figure 48-11 Authenticating a User with Access Manager

Description of Figure 48-11 follows
Description of "Figure 48-11 Authenticating a User with Access Manager"

48.6.6 Authentication Flow for a Local User

When the user chooses not to authenticate through a Social Identity Provider, the authentication can be done using a local account.

Figure 48-12, following the text, illustrates the process.

  1. The user opens a URL for a protected resource in a web browser and the Mobile and Social server presents the user with a login page and a menu of Identity Providers from which to choose.

  2. The user chooses to use local authentication and types a user name and password at the login page.

  3. The client application's Access Management Service carries out additional authentication steps as needed.

    • If using the JWT Token Service, a User Token may be created.

    • The OAM Token Service does not return tokens during the local authentication flow.

  4. The Access Management Service creates a session for the user and the user accesses the protected resource.

Figure 48-12 Authenticating a User Locally

Description of Figure 48-12 follows
Description of "Figure 48-12 Authenticating a User Locally"