48.4 Using Mobile and Social Services

Practical aspects of using and operating Mobile and Social Services include:

48.4.1 Protecting the Mobile Client Registration Endpoint

A mobile device attempting to access a protected resource must register with the Mobile and Social server as the server rejects anonymous requests sent to its registration endpoint.

Additionally, each Service Domain should be configured to require either a User password or a User Token to register an application. The following is a sample registration endpoint for mobile clients and mobile applications:

https:// host : port /idaas_rest/rest/mobileservice1/register

When registering with the Mobile and Social server, client applications using either the Java Client SDK or the REST API must present valid credentials to the server using one or more of the following schemes:

  • HTTP Basic Authentication

  • User ID and Password (UIDPASSWORD)

  • OAM Token Authentication

Client applications using the Android or iOS SDK will acquire a Client Registration Handle which uses the UIDPASSWORD authentication scheme to secure registration.

48.4.2 Token Requirements for Mobile and Social Server

The Android, iOS, and Java SDKs will send the tokens, credentials, and other data required by the Mobile and Social server.

Table 48-4 describes the tokens required and returned based on the client device or application.

Note:

For a detailed look at the credentials, see “Mobile and Social Services REST Reference: Authentication and Authorization" in the “Sending Mobile and Social REST Calls With cURL" chapter of the Oracle Fusion Middleware Developer's Guide for Oracle Access Management.

Table 48-4 Token Requirements for the Mobile and Social Server

Device or App Type Seeking to Register Token(s), Credentials, and/or Data Required by the Mobile and Social Server Type of Token Returned

Non-Mobile Device (Unregistered)

An ID and password associated with a client application sent over HTTPS.

Client Token

Mobile SSO Agent App

  • A user ID and password sent over HTTPS.

  • Device profile data for the Mobile Device.

  • The name of the application (that is, the Client ID).

    Note - An Administrator must also add the name of the mobile SSO Agent to a Service Domain.

Client Registration Handle

Mobile SSO Client App

(For example, a business application that uses the Mobile SSO Agent App to register with Mobile and Social.)

  • One of the following:

    A user ID and password sent to the Mobile and Social server over HTTPS.

    - or -

    A User Token.

  • Device profile data for the Mobile Device.

  • The name of the application (that is, the Client ID).

    Note - An Administrator must also add the name of the mobile SSO Client application to a Service Domain.

  • The oaam.device handle (if Mobile and Social is integrated with OAAM).

  • Mobile SSO Client Registration Handle (previously obtained for the SSO agent), if the SSO Client application tries to register through the SSO agent application.

Client Registration Handle

48.4.3 Protecting User Profile Services And Authorization Services

You can choose to protect User Profile Services and Authorization Services when configuring a Mobile and Social Services Service Domain.

User Profile Services - Configure User Profile Services security by making the following selections for the Service Profile:

  • Choose the Authentication Service Provider (OAMAuthentication, MobileOAMAuthentication, JWTAuthentication, Mobile JWT Authentication, Social Identity Authentication, and so on)

  • Protect the service by requiring a “Secured Application" security token and a “Secured User" security token

  • Set the “Allow Read" and “Allow Write" options

Authorization Services - Configure Authorization Services security by making the following selections for the Service Profile:

  • Choose the Authentication Service Provider (OAMAuthentication, MobileOAMAuthentication, JWTAuthentication, Mobile JWT Authentication, Social Identity Authentication, and so on)

  • Protect the service by requiring a “Secured Application" security token and a “Secured User" security token.

48.4.4 How Mobile and Social Services Work with Oracle Access Manager

Developers can quickly create applications that access resources protected by either Oracle Access Management Access Manager, or the 10g or 11gR1 PS1 (11.1.1.5) versions of Oracle Access Manager.

The Mobile and Social SDK handles authentication programatically after it collects user credentials using the credential collection interface. The SDK then uses the Mobile and Social REST interfaces to authenticate the user with the token service configured for the application. For more information about the Mobile and Social Services' authentication flow with Access Manager, see Registration Flow for a Mobile Device With User Authentication.

48.4.5 How Mobile and Social Services Work with Oracle Adaptive Access Manager Services

Oracle Adaptive Access Manager (OAAM) can be used to make runtime authentication decisions, such as blocking authentication if the user is authenticating from an unauthorized country or location.

The following functionality is also supported.

  • Multi-part login flows - for example, OAAM can challenge the user with knowledge-based authentication questions, or require the user to authenticate using one-time password (OTP) functionality if OAAM detects a risky or unusual usage pattern (using the device at unusual hours or if the user is geographically distant from the place where authentication last took place).

  • Check device attributes (such as the MAC Address assigned to a device) and verify that the device is not jail broken. Based on device attributes, OAAM can allow or deny access.

  • Device-selective wipeouts are also an option when using OAAM together with Mobile and Social.

  • Based on registered device info, OAAM can white-list or black-list specific devices.

For more information about using Mobile and Social with OAAM, see Configuring Mobile and Social Services for Oracle Adaptive Access Manager.