52.3 Understanding OAuth Services Authorization for Mobile Clients

The Mobile OAuth Services authorization scenario supports mobile apps that run in a browser as well as device-native apps that do not use a browser or just use the browser during user authentication.

This scenario provides enhanced security support (in addition to the baseline security measures defined in the OAuth 2.0 specification) including:

• Client apps must be registered with OAuth Services in the Identity Domain that your organization uses to manage Mobile OAuth Services clients.

• Mobile applications must register with Oracle Access Management prior to using OAuth Services and each registration is specific to one app on the device. After the application registration, the mobile app will have a client token. It uses this token as the security credential for making Access Token requests. In comparison, the OAuth web client uses either a credential-like password or an assertion to identify itself.

• This scenario supports user consent management. If consent management is enabled, the client app prompts the user to accept or decline the app's request to register with Access Manager.

  Note:

  This consent is controlled with the "Require User Consent for Client Registration" attribute under the Service Profiles. If set, the user will be asked to confirm app registration; if off, the user will not be asked. See Configuring Service Profiles.

• Except for access tokens (and user tokens if server-side SSO is disabled), the server does not send security material, such as OAAM device and session handles to the client on the mobile device, but stores it in the Server-Side Device Store. Access tokens are both sent to the client and stored in the Server-Side Device Store to provide for validation and life cycle management.

• The OAM server component can restrict token delivery to a specific app installed on a specific device by sending part of a token through HTTPS, and sending the other part through push notification using either the Apple Push Notification Service (APNS) or Google Cloud Messaging (GCM). Figure 52-2 illustrates this.

  Figure 52-2 Using a Split Request to get a Client Verification Code

  
  Description of "Figure 52-2 Using a Split Request to get a Client Verification Code"

The following scenario describes the additional interactions that Oracle Access Management undertakes when authenticating with a mobile client. The process is illustrated in Figure 52-3.

1. The Resource Owner opens the Client mobile app.

   An Oracle Access Management administrator has already registered this Client app as a Mobile OAuth Services Client.

2. The Mobile Client sends the client ID and the device token to OAuth Services and requests a client verification code.

3. OAuth Services returns half of the client verification code over HTTPS or HTTP.

   See Figure 52-2. This behavior can be configured in the Mobile Service Settings section of the OAuth Services Profile configuration page.

   • If the security level is set to Advanced, all codes and tokens are returned using both HTTP and push notification.

   • If the security level is set to Standard mode, all codes and tokens are sent over HTTP only.

   The rest of this scenario (beginning with step 4) contains details for when the security level is set to Advanced.

4. The Mobile client requests the second half of the client verification code from the OAuth Services push endpoint.

   The push endpoint forwards the request to the APNS or the GCM service depending on the mobile device's operating system.

5. The APNS or GCM service sends the second half of the client verification code to the Client app.

6. The Mobile client requests an authorization code from OAuth Services by sending the client verification code and the device token.

7. OAuth Services redirects the request to Access Manager.

8. Access Manager sends a login page to the user-agent so that the user can log in.

9. The Resource Owner (user) enters a user ID and password.

10. Access Manager validates the login and redirects to OAuth Services.

11. OAuth Services is configured to obtain the user's approval to register the device. (It will not ask for the user's consent to register if Require User Consent for Client Registration is disabled on the OAuth Services Profile Configuration page.)

12. The consent page is sent to the Resource Owner.

13. The Resource Owner provides (or denies) consent.

14. OAuth Services checks the Oracle Adaptive Access Manager (OAAM) plug-in to determine if additional authentication steps are required.

15. The plug-in determines that an additional challenge question is required.

16. The OAAM challenge question is sent to the Resource Owner.

17. The Resource Owner provides the challenge answer which is forwarded to the OAAM plug-in.

18. The OAAM plug-in validates the challenge answer.

19. OAuth Services uses the mobile redirect URI to return half of the authorization code that the mobile app will need to request a client token.

20. The Mobile OAuth Services client requests the second half of the authorization code from OAuth Services push endpoint.

    The push endpoint forwards the request to the APNS or GCM service.

21. The mobile client app receives the second half of the authorization code from the APNS or GCM service.

    The mobile client app assembles the authorization code in preparation for requesting a client token.

22. After validating the authorization code, the Mobile OAuth client uses the code to request the first half of the client token from the OAuth Services token endpoint.

23. The token endpoint returns the first half of the client token to the mobile client.

24. The mobile client requests the second half of the client token from the OAuth Services push endpoint.

25. The APNS or GCM service sends the second half of the client token to the mobile client app.

    The mobile client assembles the client token as well as a refresh token. The client can use the refresh token to request a new client token.

26. The mobile client prepares to request an access token by completing the following steps:

    • The Client requests and receives a client verification code from OAuth Services.

    • The Client requests and receives the first part of the authorization code from OAuth Services.

    • The resource owner does not need to log in if the user session is still valid.

    • User consent may be required based on the Resource Server scope to which the Client is requesting access.

    • The OAAM plug-in does not repeat its challenge.

    • The client requests the second part of the authorization code.

27. The APNS or GCM service returns the second half of the authorization code for the access token.

    The Client assembles the authorization code in preparation for the access token request.

28. The mobile client requests an access token by sending the client token and the access token authorization code.

29. The token endpoint sends the access token to the client. This behavior depends on whether the Security Level setting in the Mobile Service Settings section of the OAuth Services Profile configuration page is set to Advanced or Standard.

30. The Mobile OAuth Services client requests access to the protected resources by sending the access token to the Resource Server.

31. The Resource Server validates the access token with the OAuth Services token service. The Resource Server can also validate the token locally. If the certificates are configured correctly, JWT token signing is verified at the Resource Server.

32. The OAuth Services token service sends a response to the Resource Server.

33. The Resource Server sends the requested resources to the mobile client.

Figure 52-3 The Complete Mobile App Authorization Request Flow

Description of "Figure 52-3 The Complete Mobile App Authorization Request Flow"