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

Previous
Previous
 
 

6 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.

ORACLE CLOUD INFRASTRUCTURE CONSOLE AND THE IDENTITY AND ACCESS MANAGEMENT (OCI IAM) 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 6-1 OAuth 2.0 Architecture Diagram

OAuth 2.0 Architecture Diagram

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 6-2 OAuth 2.0 Use Case Flow

OAuth 2.0 Use Case Flow Diagram

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 retrieve 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:

    Your Applications Screen
  5. Click the New Application button.

    The Register a new application screen opens.

    Register a New Application Screen
  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 6-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 authorization 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 retrieve 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:

    Example clientId secret Combination

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.