Go to primary content
Oracle® Retail Integration Cloud Service Oracle® Universal Service Mapper User Guide
Release 19.1.000
F31998-01
  Go To Table Of Contents
Contents

Previous
Previous
 
 

8 OAuth 2.0

OAuth 2.0 is the industry-standard protocol for authorization. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

IDCS provides out of the box OAuth Services, which allows a Client Application to access protected resources that belong to an end-user (that is, the Resource Owner).

OAuth 2.0 Architecture Diagram

Figure 8-1 OAuth 2.0 Architecture Diagram

Surrounding text describes Figure 8-1 .

OAuth 2.0 Concepts

Business to Business (2-legged flow)

  • It usually represents an application that calls another application or service without end-user intervention.

  • A client (Business Client application) will make a call to a service, business service (in OAuth spec, a resource server), and request some business information while passing the access token.

  • Because there is no end-user intervention, the client is pre-authorized to have access to the resource.

OAuth 2.0 Use Case Flow

Figure 8-2 OAuth 2.0 Use Case Flow

Surrounding text describes Figure 8-2 .

OAuth 2.0 Terms

  • Resource Server - The server hosting the protected resource.

  • Resource Owner - An entity capable of granting access to a protected resource.

  • Client - An application making protected resource requests on behalf of the resource owner. It can be a server-based, mobile, or a desktop application.

  • Authorization Server - The server issuing access tokens to the clients after successfully authenticating the resource owner and obtaining authorization.

OAuth2 Service Consumer

A step-by-step guide to get a clientId and secret for grant_type=Password (Resource Owner Password Credentials) when configuring Logfile/WMS.

  1. Create a screen using module api/oauth2/applications.

  2. Log in to the oracle WMS cloud using credentials https://<wms-domain>/<env-name>/.

    For example: https://***.wms.ocs.oraclecloud.com/lgf_int_qa/

    • Username: <username>

    • Password: <password>

  3. Append api/oauth2/applications to the above URI.

    For example: https://<wms-domain>/<env-name>/api/oauth2/applications


    Note:

    If you access the URL without first signing you, you will receive a 'Forbidden error'.

  4. Open the URL created in step 3 in a web browser. The 'Your applications' screen opens:

    Surrounding text describes new_app_button.png.
  5. Click the New Application button.

    The 'Register a new application' screen opens.

    Surrounding text describes register_new_app.png.
  6. Register a new application using this screen.

    • Enter the Provide Name, Client Type, Authorization grant type and Redirect uris.

    • Client type can be public/confidential.

    • Client Id and Secret are generated.

  7. Click the Save button.

  8. Provide steps for grant type Resource Owner Password Credentials.

  9. Redirect uri is optional for grant type Resource Owner Password Credentials, but without a URI, it is not able to register.

    So provide the Redirect uri as:

    <wms-domain>/<env-name>/icsapis/agent/oauth/callback - https://<wms-domain>/<env-name>/icsapis/agent/oauth/callback
    
  10. Request an access token for grant type Resource Owner Password Credentials. Scope is optional.

    Enter the following values:

    • Client id - <Value generated in the 'Register a new application' screen (step 5-)6>

    • Client secret - <Value generated in the 'Register a new application' screen> (step 5-)6

  11. Retrieve the token using the clientId and secret through a curl statement.

    curl -v -X POST -u  "<ClientId>:<Secret>" -d "grant_type=password&username=<username>&password=<pwd>" <wms-domain>/<env-name>/api/oauth2/token/
    

    For example:

    curl -v -X POST -u  "<ClientId>:<Secret>" -d "grant_type=password&username=rgbu5_adm&password=welcome1#" https://***.wms.ocs.oraclecloud.com/lgf_int_qa/api/oauth2/token/
    

    A successful response will be in the following format:

    {"access_token": "<access-token>", "token_type": "Bearer", "expires_in": 36000, "refresh_token": "<refresh-token>", "scope": "read write"
    
  12. Test the token by accessing the Logfile URL using the access_token with a curl statement:

    curl -X POST -i -H 'Authorization: Bearer <access-token>' \
    'https://***.wms.ocs.oraclecloud.com/lgf_int_qa/wms/api/init_stage_interface/' --data "@./ItemLgfDataNoNewLine.xml"
    

    A successful response has the following format:

    <?xml version="1.0" encoding="utf-8"?>
    <root><success>True</success><response><message>Stage table processing com-plete</message></response></root>
    

Access Logfire Services Using OAuth2 Consumer

The Logfire services are consumed by using the following security policies:

  • Basic Authentication 2.OAuth2.

    By configuring this property in the configuration file, you can switch between basic and oauth2 authentication.

  • OAuth2 Consumer Configuration:

    Table 8-1 external_env_info.LogFireIntegration.json

    Configuration Property Description

    "name": "Lgf_Oauth2_Authentication","value": "true"

    1. To enable OAuth for logfire, change the value of flag 'Lgf_Oauth2_Authentication' to 'true'.

    2. To enable basic auth for logfire, change the value of 'Lgf_Oauth2_Authentication' to 'false'.

    "name": "lgf_oauth2_alias_key",

    "value": "lgfOauth2ApplicationClientAlias"

    Save the ClientId and Secret in the credential store using the alias lgfOauth2ApplicationClientAlias.

    "name": "LogFire_Host_Url_Key",

    "value": "<Logfire Login URL>

    Logfire URL used for the OAuth token.


After receiving a Logfire clientId and secret from the above steps:

  1. Store these credentials in the credential store for further reference in the USM application to create an OAuth token.

    Once the OAuth token is issued, further API calls are made.

  2. Save the clientId and secret in the credential store with the alias name lgfOauth2ApplicationClientAlias, as defined in the JSON.

    The USM application uses this alias to make a call to Logfire and get the OAuth token. Once obtained, the OAuth2 token services calls are made.

  3. Pass the JSON request to the service. This saves the credentials(clientId/secret combination.

    JSON request format:

    {
    "userAlias": "<Alias>",
    "userName": "<Id>",
    "userPassword": "<password>"
    }
    

    For example:

    Surrounding text describes save_credential_json_exmpl.png.

USM consumer simplifies access of services protected by OAuth 2.0. The USM consumer executes the following steps:

  1. Gets the token from the Logfire server using client ID, client secret, and scope.

  2. Adds the "Authorization Bearer <token>" HTTP header.

  3. Calls the service.