Part 6 of 12 in the Oracle EPM Cloud REST API series.
Before Oracle EPM Cloud acts on any request, it needs to know who is asking. Two authentication methods are supported, and picking the right one depends on what you are building.
Basic authentication
Basic Auth is the simpler option and a reasonable place to start. Credentials travel base64 encoded inside the Authorization header:
Authorization: Basic <base64 encoded "identitydomain.username:password">
Depending on how your environment is configured, the username portion is either just your username or prefixed with your identity domain, in the form identitydomain.username. You can find your identity domain in the top left corner of the Activity Report inside your environment, or by parsing it out of your instance's URL. Most HTTP clients, including curl, handle the base64 encoding automatically if you pass credentials with the -u flag rather than building the header by hand.
Basic Auth is quick to set up and fine for a first script or a test in Postman, but it means a real password sits somewhere in your script or configuration file. Keep that tradeoff in mind for anything you plan to leave running unattended.
OAuth 2.0
OAuth 2.0 is the option Oracle recommends for production automation on its current OCI (Gen 2) architecture, and it avoids that tradeoff entirely. Instead of a password, a domain administrator registers a client application in Identity Cloud Service, commonly called IDCS, which issues a client ID. From there, your script exchanges a refresh token for a short-lived access token as needed.
The token request looks like this:
curl --location --request POST 'https://idcs-<value>.identity.oraclecloud.com/oauth2/v1/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=refresh_token' \
--data-urlencode 'client_id=<your client id>' \
--data-urlencode 'refresh_token=<your refresh token>'
Oracle responds with a JSON payload containing the access token:
{
"access_token": "eyJj5M4QjUkI.........abSjZaa86PlseS4lrt7R2",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "AAyyilYBAWD4....FVkxefd8kjoJr6HJPA="
}
That access token then replaces Basic Auth in every subsequent call, using the Bearer scheme:
Authorization: Bearer <access_token>
By default, access tokens last 3600 seconds, one hour, and the refresh token used to get new ones lasts up to 604800 seconds, seven days. A script meant to run for weeks or months needs logic to request a fresh access token once the old one expires, but that logic is simple once it exists, and no plaintext password ever needs to sit in the script itself.
Which one to use
For a quick test or your very first call, Basic Auth gets you moving with the least setup. For anything you intend to schedule and leave running unattended, OAuth 2.0 is worth the extra registration step, since there is no long-lived password to protect or rotate.
With authentication settled, it is time to look at everything else that goes into a request alongside the URL, method, and credentials.