Call Fusion Field Service API with OAuth token provided by Fusion Applications Identity Domain

OAuth in the context of Oracle Applications uses an auto-generated token (a JSON Web Token, also known as JWT) to grant access to the required resources. The process to get that token involves a few steps. The following content provides you the configuration instructions along with explanatory content to help you understand the overall setup.

Use the Oracle Cloud Infrastructure Identity and Access Management (IAM) identity domain associated with your Fusion Applications environment to configure the OAuth flow.

NOTE: Functionality is supported only in Fusion Field Service but not supported in Oracle Field Service. It is because Fusion Field Service is automatically provisioned with IAM. You can use OAuth in Oracle Field Service but it will require configuration at Configurations --> Applications. See section Integrate with REST APIs of the Administering Oracle Fusion Field Service manual.

Only "Client Credentials" OAuth Grant Type is implemented within this feature. It will allow you to directly connect your application to Fusion Field Service without user involvement. In this configuration, you store the client credentials with the application, which can request the authorization server on your behalf to provide the access token. Later, that token is used to request access to the REST resources on the resource server. In this case, there's no user involvement. No configuration is needed inside Fusion Field Service for it to work. All configuration is done in IAM with other Fusion Applications.

Business Benefit

Allows a user to call Field Service API using OAuth token with Client Credentials grant type provided by  Fusion Applications Identity and Access Management (IAM) that is provisioned together with Fusion Applications. There is no need to do additional configuration in Field Service. All configuration is done in IAM with other Fusion Applications.

Steps to Enable

Configuring OAuth requires you to be familiar with Oracle Cloud Infrastructure Identity and Access Management, and have experience with creating and maintaining identity domains. To learn more, see Overview of IAM.

At a high-level, the configuration involves the following:

1. Identify the identity domain where you'll create your confidential application. The domain will be the authorization server.

   NOTE: Make sure that you or other required users have the necessary privileges to access the Identity and Access Management Admin Console to navigate to the identity domain. For details, see Managing Users.

2. Specify "Client Credentials" grant type for your OAuth flow.
3. Define the scope of the access. Several scopes from the same audience can be combined together.
4. Generate the access token.
5. Use the token to access the REST resources.

Typically, this setup is recommended for a client-server interaction handling automated application-level requests. Let's look at how to set it up in the application.

1. Create an application that allows users to access the resources.
   1. Sign in to the identity domain as an Administrator.
   2. From the list of identity domains, click Integrated applications and click Add application.
   3. On the Add application dialog box, select Confidential Application and click Launch workflow.
   4. On the Add Confidential Application page, enter a name for the application that you're adding.
   5. Skip all other fields and click Next.
   6. In the Configure OAuth section, select Configure this application as a client now to proceed with the client configuration settings. Since you're creating a client application, only this option is relevant.
   7. In the Authorization section, select the Client credentials checkbox to specify the grant type.
   8. Skip the next few fields and go to the Token issuance policy section.
   9. In Authorized resources, select specific so that the user is granted access only to the specific resources.
2. Add resources for your product.
   1. Select the Add resources checkbox to include the resources that are accessible to the users.
   2. In the Resources subsection, click Add scope.
   3. On the Add scope dialog box, select the applications containing the resources, and click Add. The resources are added. You'll notice that the scope defined by your application administrator is available in the format: <resource audience><resource scope>.
   4. Review the added resources. If you don't need any resource, select and click Remove to exclude it from the scope.
3. Complete application creation and activate the application.
   1. After adding the resources, click Next and go with the default settings for the Web tier policy section. You don't have to modify any settings on this page.
   2. Click Finish. A confirmation dialog box appears displaying the auto-generated Client ID and the Client Secret values.

      NOTE: Make a note of the Client ID and Client Secret values because you'll need them for requesting the access token.

   3. Click Close. You're taken to the application page that you just created.
   4. Click Activate. A confirmation message appears asking for a confirmation to activate the application.
   5. Click Activate application. The confidential application is activated and ready for use.
4. Request an access token. You can do so using a client application such as Postman, or cURL command. Let's look at both these options.

   Table: Request an access token using Postman and cURL

   Sl.No.	Using Postman	Using cURL
   1	In Postman, create a new request.	Launch the command prompt.
   2	On the Authorization tab, select OAuth 2.0 as the Authorization Type.	Enter the cURL command below, replacing the text in angle brackets ( < > ) with the appropriate values:  curl -u <clientid:clientsecret> --basic -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" --request POST https://<domainURL>/oauth2/v1/token -d "grant_type = client_credentials&scope= <scope>"
   3	In the Configure New Token section, enter the following client configuration: Token Name: Enter a generic name for the token. Grant Type: Select Client Credentials. Access Token URL: The IDCS URL appended with /oauth2/v1/token is used as the Access Token URL. You can get the URLs from https://idcs-<idcs-id>.identity.oraclecloud.com/.well-known/idcs-configuration. Client ID: Enter the Client ID value that was auto-generated after creating the confidential application. Client Secret: Enter the Client Secret value that was auto-generated after creating the confidential application. Scope: Mention the scope defined in the identity domain. Several scopes from the same audience can be combined together. Client Authentication: Select Send as Basic Auth Header.	You can expect the response in a format as shown here:  Status: 200 "access_token":"eyJ4NXQiOiI4Wk. . ." "token" : "Bearer", "expires_in":3600
   4	Click Get New Access Token. Postman passes on the information to the identity domain to authenticate and returns the access token.	Copy the value displayed for access token. This is the token that you'll need to request access to the resources.

5. Access the resource using the access token.

In Postman, click the Use Token to use the token.(auto-fill the Token field) and access the resource from the resource server. Or, if you need the cURL command in the previous step, you could continue with the command prompt to send the REST request and get access to the resources.

You'd need to structure your request as shown here:

curl -X GET -H "<as needed by your REST endpoint, such as application/json>" -H "Authorization: Bearer <access_token>" "https://<REST API endpoint URL>"

Note that the Authorization header is set to Bearer token and you'd provide the access token retrieved earlier as its value.

Scopes defined for Field Service

1. / - Default scope. Provides access to Open API/Swagger metadata for APIs and to the APIs in read-only mode for those APIs defined in the Metadata, Parts Catalog, and Statistics section of the documentation.
2. /use - Day-to-day operations such as managing activities or resources, defining capacity and calling booking APIs. No access to APIs defined in the Collaboration section of the documentation because those APIs require user identity.
3. /view - Same as "Use", but read only access
4. /events - Subscribe to and retrieve events
5. /setup - Setup and Administration. Provides access to APIs in read/write mode for those APIs defined in the Metadata, Parts Catalog, and Statistics section of the documentation.