Introduction
In this blog, we’ll go through the steps to authenticate and access the v1 REST APIs (those that include /api/boss/ in the path). For example, this applies to the v1 APIs listed under REST API for Common Features
Steps to Access the V1 APIs
1. Create an OAuth Confidential Application
OAuth in the context of Oracle Fusion Applications uses an auto-generated token (a JSON Web Token, also known as JWT) to grant access to the APIs. To set this up, you need to configure the OAuth flow using the Oracle Cloud Infrastructure Identity and Access Management (IAM) domain linked to your Fusion Applications instance.
At a high level, the configuration process includes:
-
Identify the Identity Domain: Determine the domain where you will create your confidential application. This domain acts as the authorization server.
-
Specify Grant Types: Choose the OAuth grant types based on your requirements. You can configure either a 2-legged or 3-legged OAuth flow. In this blog, we will go through the steps to configure 2-legged OAuth flow.
-
Define Access Scope: Set the scope that determines the level of access the token will provide.
-
Generate Access Token: Obtain the OAuth token after configuring the application.
-
Use the Token: Utilize this token to authenticate and access the REST API resources.
Following are the details to configure the Confidential Application.
-
Log in to the IDM Admin Console and navigate to your pod’s identity domain of type Oracle Apps.
- Click Integrated applications
- Click Add application
- Select Confidential Application and click Launch workflow
- Create a Confidential application and click on Submit.
6. Open the application you created.
7. Click on Edit OAuth Configuration and do the following
7.1 Select Configure this application as a client now
7.2. Choose Allowed Grant Types as Client Credentials or Resource Owner and JWT Assertion.
Resource Owner Grant Type :
Use this when operating in a highly secure and trusted environment. In this model, the resource owner authenticates directly in the client application rather than being redirected to an identity provider. Since the client is a trusted application registered with the authorization server, the server validates the resource owner’s credentials and issues an access token.
Client Credentials Grant Type :
Use this for applications that process requests without user interaction and don’t require user-level permissions. Here, the client credentials are embedded in the application and validated by the authorization server. This flow is typically recommended for automated client–server interactions handling application-level requests.
7.3. Choose Client type as Confidential
7.4 Choose Allowed operations as On behalf of
. 7.5. Enable Bypass consent
7.6. Select Add resources
7.7. Click Add scope, then search and select the scope, Oracle Boss Cloud (Spectra)
8. Click Add and Submit
9. Click on Activate to activate the application
10. Take note of Client ID and Client Secret of the application. This is used for generating tokens.
Role Access
V1 APIs are secured using SAS which adds new security technology that introduces elements called permission groups.Follow the steps below to ensure that your role is updated with the required permission groups to access the V1 REST API.
1.Go to Setup and Maintenance
- Search for Manage Administrator Profile Values and enter this task
- Search for the profile value by profile option code ORA_ASE_SAS_INTEGRATION_ENABLED
- Set its value to Yes at the Site level
- Save the profile value
2. Go to Tools → Security Console
- Search for the role you want to update, say for example ORA_FND_APPLICATION_DEVELOPER_JOB and click Actions > Edit.The Basic Information page now includes an Enable Permission Groups button.
- Click Enable Permission Groups and confirm
- Go to the Permission Groups train stop. You can see the permission groups enabled to the role. For example, read: Common Lookup Type Permission Group gives the Permission to read an artifact type OraBusinessObject with Artifact Name as Common Lookup Type. This is the permission required to read the common Lookup v1 REST API Business Objects.
3. If you are using Client Credentials grant type, remember to configure the Client ID as a user in Fusion Applications, using the Security Console. Make sure that the user name is the same as the auto-generated Client ID. If you are using Resource Owner grant type, the user you are using to execute the API should have the roles which has permission groups enabled to access the Business Objects.
Generate the Access Token
You should use the urn:opc:resource:fusion:<<replace with your podname>>:boss/ scope, while running the commands shown below.
To generate the access token using Resource Owner grant type OAuth, use
curl -u <clientid:clientsecret> --basic -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" --request POST https://<Identity domainURL>/oauth2/v1/token -d "grant_type=password&username=<username>&password=<password>&scope=urn:opc:resource:fusion:<<replace with your podname>>:boss/"
To generate the access token using Client Credential grant type OAuth, use
curl -u <clientid:clientsecret> --basic -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" --request POST https://<Identity domainURL>/oauth2/v1/token -d "grant_type=client_credentials&scope=urn:opc:resource:fusion:<<replace with your podname>>:boss/"
Expect a response as shown below,
Status: 200
"access_token":"eyJ4NXQiOiI4Wk. . ."
"token":"Bearer",
"expires_in":3600
Copy the value displayed for access_token. This is the token that you’ll need to request access the API.
Execute REST APIs
Now that you have the access token generated by the OAuth 2.0 API provided by IDCS, you can use that token to authenticate calls to APIs . Make sure to specify the token as a Bearer token in the authorization header of your requests so that it can be properly processed.
Example,
curl --location 'https://fa-exfh-test-saasfaprod1.fa.ocs.oraclecloud.com/api/boss/data/objects/ora/commonAppsInfra/objects/v1/territories' --header 'Authorization: Bearer kkkkk....'