Getting Started with the Identity Domains REST API

Resources

For more information about OAuth security, access the following links:

• The OAuth 2.0 Authorization Framework

• OAuth 2.0 Threat Model and Security Considerations

• JSON Web Token (JWT)

• JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

Security Recommendations Checklist

This page lists the most relevant security recommendations as a checklist, so that you can validate your application security and address the security items according to your expectations.

Encryption

• Use TLS in Client and Resource Server Applications

  The use of TLS with all applications provides confidentiality in communications between identity domain, resource owners, client applications, and resource server applications. This prevents eavesdropping during transmission of the authorization code, access tokens, refresh tokens, client credentials, and user credentials, and preventing replay attacks.

• Establish Server Authentication (HTTPS with Trusted CA Validation)

  Server authentication allows clients, resource servers, and resource owners to establish communication between themselves and with an identity domain after verifying the public certificate against the trusted CA.

  If the server fails to provide a trusted certificate (provided by a trusted CA and with a matching hostname), the communication is considered a man-in-the-middle attack.

  Server authentication prevents spoofing, proxying, man-in-the-middle, and phishing attacks to capture authorization codes, access tokens, client credentials, and user credentials.

• Consider Using a Trusted Assertion with Identity Domains

  Critical security clients can use a client assertion with key cryptography (instead of a client secret) for authentication.

• Protect the Redirect URI with HTTPS and Trusted CA Validation

  HTTPS and using trusted CA validation prevents authorization "code" phishing and user session impersonation.

Administration

• Configure Applications Following the Least Privilege Principle

  Applications should be configured in an identity domain with only the minimum rights needed for their operation.

  Narrowing down the scope, flows, grant types, and operations improves the security posture and reduces the impact of a compromised application.

• Provide a Meaningful Name and Description for Applications

  The application information appears for users under the My Apps and the consent pages.

  The use of meaningful application names and descriptions may prevent users from making mistakes during consent authorization and also contributes to better audit reporting.

• Provide a Meaningful Description for Scopes

  The scope description appears on the consent page. Explaining the scope, which the user is about to grant, in an understandable way prevents the user from making mistakes during authorization and contributes to better audit reporting.

• Avoid Scopes Provided Without Consent

  To leverage transparency and rely on the resource owner, provide scopes without permission only when a scope is mandatory, and the user must not be able to deny it.

• Reduce the Access Token Time Out and Use Refresh Tokens

  Identity domains support JWT, an access token that can be validated in resource servers without checking the token in the identity domain. Because of this, access tokens with long duration can't be easily revoked.

  To implement timely revocation, you can configure the access token with a short lifetime, and then use the refresh token for requesting new access tokens. To perform a timely revocation, you need to revoke the refresh token.

• Rotate the Application's Client Secrets

  For security critical implementations, implement a client secret rotation. This reduces the risk of getting a compromised client secret explored.

Resource Owner (User)

• Keep the Resource Owner Informed

  Scope use with consent provides transparency to the resource owner and prevents applications from requesting scopes that aren't required.

• User Awareness

  Teach users how to protect their credentials and identify client, resource server application, and identity domain legitimacy (especially when authentication and consent pages appear). This reduces the risk of phishing attacks and the compromise of user credentials.

Application Development

• Protect Codes, Access Tokens, Refresh Tokens, and Client Credentials

  Applications must preserve the confidentiality of codes, access tokens, refresh tokens, and client credentials. When you develop the application, consider the following measures (among other application security measures):

  • Don't store codes (use the code only during runtime to obtain the access token)

  • Keep access tokens in transient memory and limit their grants

  • Store refresh tokens and client credentials in secure places that can be accessed only by the application

• Protect the Redirect URL

  The redirect URL (from where the identity domain retrieves the authorization code) is considered a key component for OAuth security. Be careful when you define this URL to avoid threats such as cross site request forgery and denial of service.

• Read Tokens from the Native Apps File System

  Attackers may try to get file system access on the device and read the refresh tokens using a malicious application. To reduce this risk, store secrets in secure storage and use device lock to prevent unauthorized device access.

• Implement Controls for Cloned and Stolen Devices with Native Apps

  To reduce risks when a device with Native Apps gets cloned or stolen, use device lock to prevent unauthorized access and revoke refresh tokens.

• Validate Application Security Prior to Publication

  Test the application and its hosting environment security before publishing the application to reduce vulnerabilities. Threats related to application hosting and development aren't addressed by identity domains. These threats include but aren't limited to indirect access to application databases and storage, select-jacking, cross-site scripting, script/SQL injection, and information confidentiality flows on the application.

• Apply Least Privilege During Scope Request

  Client applications should request tokens that contain only scopes that it will possibly or actually use.

  The use of the urn:opc:idm:__myscopes__ scope, although convenient, may retrieve more tokens than needed by the client application.

  A token with extensive scopes can increase the security impact when a token is compromised.

  See Scopes for information about using the scope parameter and an access token to grant different levels of access to identity domains.

• Validate JWT Tokens

  When receiving an access token (JWT) from any party (except the identity domain server in a direct request from your application), validate the JWT following the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants and the JWT RFCs.

  See Token Validation for more information on how to validate the token.

  Note
  
  Resource servers must process information only after the entire JWT validation is performed.

• Receive JWT Tokens Properly

  Resource server applications must receive the access token using only the Authorization: bearer <token> header to avoid threats related to parameter caching.

• Implement 2-Way TLS Between Client and Resource Server Applications

  For security critical applications, you can implement a 2-way TLS between client and resource server applications to reduce the risk of denial of service (DoS) and impersonation attacks.

  Don't write applications that collect authentication information directly from users.

• Prevent Select-Jacking

  For newer browsers, avoid iFrames during authorization by enforcing the use of the X-FRAME-OPTIONS header.

  For older browsers, JavaScript frame-busting techniques can be used but may not be effective in all browsers.

• Avoid the Use of Resource Owner Password Credentials

  The resource owner flow allows a client to request an access token using an end user's ID, password, and the client's own credentials. This grant type presents a higher risk because:

  • It's in charge of collecting the user credentials on the client application (maintains the UID/password anti-pattern).

  • Doesn't present a consent screen for scope requests.

  Except for migration reasons, avoid the use of this grant type.

• Use the Cache-Control="no-store" Header

  This header minimizes the risk of not protecting authenticated content and leaking confidential data in HTTP proxies.

• Avoid Requests with Sensitive Information Sent Using URL Parameters

  The URL parameters (used on GET requests) can be logged in any component between applications such as application logs, proxy servers, firewalls, and network edge components.

  Identity domains implement alternative search REST endpoints using POST that addresses this risk. See the Query Parameters page for more information.

Validating Identity Tokens

An Identity (ID) Token is an integrity-secured, self-contained token (in JSON Web Token format) that contains claims about the end user. It represents an authenticated user's session. Therefore, the token must be validated before an application can trust the contents of the ID Token. For example, if a malicious attacker replayed a user's ID Token that they had captured earlier, the application should detect that the token has been replayed or was used after it had expired and deny the authentication.

Validating Access Tokens

Step 1: Register a Confidential Application in Identity Domains Using the Console

When you register a confidential application in the identity domain Console, you obtain some of the key parameters that you need to work with OAuth 2.0: Client ID, Client Secret, and Scopes. OAuth 2.0 is a standard for implementing delegated authorization, and authorization is based on the access token required to access a resource. The access token can be issued for a given scope, which defines what the access token can do and what resources it can access. When you register a web application in an identity domain, you add scopes. In the following example, the required scopes to request User searches, edits, creates, and deletes are added. But, if you were to do other things-for example, manage Audit Events, that would require other scopes.

To create and register a confidential application access the OCI Console and then complete the following steps:

1. Open the navigation menu  and select Identity & Security. Under Identity, select Domains.
2. Click the name of the identity domain that you want to work in. You might need to change the compartment to find the domain that you want. Then, click Integrated applications.
3. Select Add application.
4. In the Add application dialog box, select Confidential Application, and then select Launch workflow.
5. On the Add application details page, enter an application name and description, and then select Next.
6. On the Configure OAuth page, under Client configuration, select Configure this application as a client now.
7. Under Authorization, select only Client Credentials as the Allowed Grant Type.
8. At the bottom of the page, select Add app roles and then select Add roles.
9. In the Add app roles panel, select Identity Domain Administrator, and then select Add.
10. Select Next and then select Finish.
11. On the application detail page, scroll down to General Information. Copy the Client ID and the Client Secret and store it in a safe place.
12. After the application is created, select Activate.

Step 2: Base64 Encode the Client ID and Client Secret

Windows

1. Launch Notepad, and then paste the client ID and client secret into Notepad.

2. Place the client ID and client secret on the same line and insert a colon between them: clientid:clientsecret

   Note
   
   Ensure that no spaces are the clientid:clientsecret attribute.

3. Save the file to C:\temp and name the file appCreds.txt.

4. In Windows Explorer, right-click C:\temp, and then select CMD Prompt Here from the context menu.

5. Enter the following command to encode the client ID and client secret:

   certutil -encode appCreds.txt appbase64Creds.txt

6. In Notepad, open C:\temp\appbase64Creds.txt, copy its contents, and then close the file.

   Note
   
   For security reasons, delete the appCreds.txt and the appbase64Creds.txt files after you finish.

Mac and Linux

1. Launch your preferred note utility (for example, Mac Notes, Gedit Linux, or Vi), and then paste the client ID and client secret into the note utility.

2. Place the client ID and client secret on the same line and insert a colon between them: clientid:clientsecret.

   Note
   
   Ensure no spaces in the clientid:clientsecret.
   statement.

3. Copy the clientid:clientsecret line.

4. Launch a terminal and enter the following command, replacing clientid:clientsecret with the value that you copied to the clipboard.

   echo -n "clientid:clientsecret" | base64 -w 0

   Note
   
   For Linux, add -w 0 to the command to remove line breaks.
5. Copy the value that's returned.

   Note
   
   If the value that's returned is broken into more than one line, return to your text editor and ensure the entire results are on a single line with no text wrapping.

Step 3: Obtain an Access Token

The next step in this process is to request the access token.

1. Launch a command prompt.

2. Enter the cURL command below, replacing the text in brackets ( < > ) with the appropriate values:

      curl -i
      -H "Authorization: Basic <base64encoded clientid:secret>"
      -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8"
      --request POST https://<domainURL>/oauth2/v1/token
      -d "grant_type=client_credentials&scope=urn:opc:idm:__myscopes__"

   Note
   
   If you're using a UNIX OS, you can append | awk -F"\"" '{print $4}' to the end of the cURL command to parse out just the Bearer token. Just remember that the default expiration of the token is 3600 seconds from the time of the request.
   Note
   
   Optionally, run the following cURL command to have the access token value accessible through a UNIX variable called AccessTokenValue in your environment:

      export AccessTokenValue=`curl -i
      -H "Authorization: Basic <base64encoded clientid:secret>"
      -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8"
      --request POST https://<domainURL>/oauth2/v1/token
      -d "grant_type=client_credentials&scope=urn:opc:idm:__myscopes__" | awk -F"\"" '{print $4}' |  tail -n +16`

   You can then run echo $AccessTokenValue command to get the access token value.

   Text in Brackets	Value
   base64encoded clientid:secret	Replace with the encoded credentials that you generated in the Base64 Encode the client ID and client secret section. Ensure no spaces in the clientid:clientsecret credentials.
   IDCS_Service_Instance	Replace with your identity domain URL (for example, https://<domainURL>/).

   Note
   
   The urn:opc:idm:__myscopes__ scope in the command is used as a tag by identity domain clients requesting access tokens from the OAuth authorization server. Access tokens are returned that contain all applicable identity domains scopes based on the privileges represented by the identity domains administrator roles granted to the requesting client and the user being specified by the client's request (if present). This scope isn't granted directly to any identity domains administrator role.

3. Copy the access_token value from the response. Ensure to copy only the actual token, which is the access_token value between the quotation marks:

   Status: 200
   "access_token":"eyJ4NXQiOiI4Wk. . ."
   "token":"Bearer",
   "expires_in":3600
   

   Note
   
   The response includes the expires_in: 3600 parameter. This means that your token is no longer valid after one hour from the time that you generate it. After one hour, you must refresh the token or get a new access token. To refresh the token, enter the cURL command below, replacing the text in brackets ( < > ) with the appropriate values:

   curl -i
     -H "Authorization: Basic <base64 encoded client ID and secret>"
     -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8"
     --request POST https://<domainURL>/oauth2/v1/token
     -d "grant_type=refresh_token&refresh_token=<token_value>"

Step 4: Make a REST Request to the Environment

After you obtain the OAuth 2.0 access token, you can use the token in a cURL command to send a REST request to the identity domains REST API. The following command returns a list of users in an identity domain.

   curl -X GET
   -H "Content-Type:application/scim+json"
   -H "Authorization: Bearer <access_token>"
   https://<domainURL>/admin/v1/Users

Populate Risk

This endpoint is used to submit risk data to an identity domain to increase the user's risk score.

   curl -k -X POST 'https://<domainURL>/admin/v1/sdk/adaptive/PopulateRisks' 
   -H 'Authorization: Bearer <Access_Token>' 
   -H 'Accept:application/json' 
   -d '<Request_Body>'

{
    "userName": "<User_Name>",
    "data": [
        {
            "name": "device",
            "value": "<result_of_the_devicefingerprint_javascript_file>"
        },
        {
            "name": "client-ip",
            "value": "<ip_address_of_the_user_browser>"
        }
    ],
    "event": "MAX_PASSWORD_FAILED_ATTEMPTS"
}

The event attribute is optional. If not present in the request then all risk events are going to be used to evaluate risk score. You can use MAX_MFA_FAILED_ATTEMPTS or MAX_PASSWORD_FAILED_ATTEMPTS values.

   curl -k -X POST https://<domainURL>/v1/sdk/adaptive/PopulateRisks \
     -H 'Content-Type: application/json' \
  
   -H 'Authorization: Bearer <Access_Token>' \
  
   -d '{
    "userName": "johndoe@example.com",
    "data": [
        {
            "name": "device",
            "value": "{\"currentTime\":\"Wed Nov 13 2019 16:57:34 GMT-0700 (Pacific Daylight Time)\",\"screenWidth\":1920,\"screenHeight\":1080,\"screenColorDepth\":24,\"screenPixelDepth\":24,\"windowPixelRatio\":1,\"language\":\"en-US\",\"userAgent\":\"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Firefox/68.0\"}"
        },
        {
            "name": "client-ip",
            "value": "10.11.12.13"
        }
    ]
}'

{
    "userName": "johndoe@example.com",
    "riskLevel": "LOW",
    "riskScores": [
        {
            "lastUpdateTimestamp": "2022-11-12T10:41:57.997Z",
            "score": 15,
            "riskLevel": "LOW",
            "value": "ORACLE_IDCS",
            "status": "ACTIVE",
            "source": "Default Risk Provider",
            "$ref": "https://<domainURL>/admin/v1/RiskProviderProfiles/ORACLE_IDCS"
        }
    ]
}

Fetch Risk Info

This endpoint enables clients to get current risk information for a single user, multiple users, or for all users in an identity domain.

   curl -k 
   -X POST 'https://<domainURL>/admin/v1/sdk/adaptive/FetchRisks' 
   -H 'Authorization: Bearer <Access_Token>' 
   -H 'Accept:application/json' 
   -d '<Request_Body>'

{
    "userNames": [
        "<user_name>"
    ]
}

{
    "userNames": [
        "<user_name_1>",
        "<user_name_2>"
    ]
}

{}

   curl -k -X POST https://<domainURL>/admin/v1/sdk/adaptive/FetchRisks \
     -H 'Content-Type: application/json' \
  
   -H "Authorization: Bearer <Access_Token>' \
  
   -d '{
    "userNames": [
        "johndoe@example.com"
    ]
}'

{
    "totalResults": 1,
    "resources": [
        {
            "userName": "johndoe@example.com",
            "riskLevel": "LOW",
            "riskScores": [
                {
                    "lastUpdateTimestamp": "2022-11-13T18:41:57.997Z",
                    "score": 15,
                    "riskLevel": "LOW",
                    "value": "ORACLE_IDCS",
                    "status": "ACTIVE",
                    "source": "Default Risk Provider",
                    "$ref": "https://<domainURL>/admin/v1/RiskProviderProfiles/ORACLE_IDCS"
                }
            ]
        }
    ],
    "startIndex": 1,
    "itemsPerPage": 50
}

Mitigate Risk

This endpoint enables client applications to request mitigation of a user's risk score because the user has logged in or reset their password successfully.

   curl -k 
   -X POST 'https://<domainURL>/admin/v1/sdk/adaptive/MitigateRisks' 
   -H 'Authorization: Bearer <Access_Token>' 
   -H 'Accept:application/json' 
    -d '<Request_Body>'

{
    "userName": "<User_Name>",
    "data": [
        {
            "name": "device",
            "value": "<result_of_the_devicefingerprint_javascript_file>"
        },
        {
            "name": "client-ip",
            "value": "<ip_address_of_the_user_browser>"
        }
    ],
    "event": "SSO_THREAT_MITIGATION_SUCCESS"
}

   curl -X POST \
  https://<domainURL>/admin/v1/sdk/adaptive/MitigateRisks \
     -H 'Content-Type: application/json' \
     -H 'Authorization: Bearer <Access_Token>' \
  -d '{
    "userName": "johndoe@example.com",
    "data": [
        {
            "name": "device",
            "value": "{\"currentTime\":\"Thu Nov 14 2019 10:11:18 GMT-0700 (Pacific Daylight Time)\",\"screenWidth\":1440,\"screenHeight\":900,\"screenColorDepth\":24,\"screenPixelDepth\":24,\"windowPixelRatio\":2,\"language\":\"en-US\",\"userAgent\":\"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.81 Safari/537.36\"}"
        },
        {
            "name": "client-ip",
            "value": "10.11.12.13"
        }
    ],
    "event": "SSO_THREAT_MITIGATION_SUCCESS"
}'

{
    "userName": "johndoe@example.com",
    "riskLevel": "LOW",
    "riskScores": [
        {
            "lastUpdateTimestamp": 1574726401582,
            "score": 10,
            "riskLevel": "LOW",
            "providerId": "ORACLE_IDCS",
            "providerStatus": "ACTIVE",
            "providerDescription": "Default Risk Provider",
            "reference": "https://<domainURL>/admin/v1/RiskProviderProfiles/ORACLE_IDCS"
        }
    ]
}

Sample Request: /Users

{
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:PatchOp"
    ],
    "Operations": [
        {
            "op": "replace",
            "path": "phoneNumbers",
            "value": [
                {
                    "type": "home",
                    "value": "555-555-0100"
                }
            ]
        },
        {
            "op": "add",
            "path": "urn:ietf:params:scim:schemas:oracle:idcs:extension:selfChange:User:allowSelfChange",
            "value": true
        }
    ]
}

Sample Request: /UserCapabilitiesChanger

{
    "canUseApiKeys": true,
    "canUseAuthTokens": false,
    "canUseConsolePassword": true,
    "canUseCustomerSecretKeys": true,
    "canUseOAuth2ClientCredentials": true,
    "canUseSmtpCredentials": true,
    "canUseDbCredentials": true,
    "urn:ietf:params:scim:schemas:oracle:idcs:extension:selfChange:User:allowSelfChange": true,
    "schemas": [
        "urn:ietf:params:scim:schemas:oracle:idcs:UserCapabilitiesChanger"
    ]
}

Sample Request: /UserLockedStateChanger

{
    "schemas": [
        "urn:ietf:params:scim:schemas:oracle:idcs:UserLockedStateChanger"
    ],
    "userId": "<unique_ID>",
    "locked": false,
    "urn:ietf:params:scim:schemas:oracle:idcs:extension:selfChange:User:allowSelfChange": true
}

Sample Request: /UserPasswordChanger

{
    "password": "example-password",
    "urn:ietf:params:scim:schemas:oracle:idcs:extension:selfChange:User:allowSelfChange": true,
    "schemas": [
      "urn:ietf:params:scim:schemas:oracle:idcs:UserPasswordChanger"
    ]
  }

Sample Request: /UserPasswordResetter

{
    "schemas": [
      "urn:ietf:params:scim:schemas:oracle:idcs:UserPasswordResetter"
    ],
    "urn:ietf:params:scim:schemas:oracle:idcs:extension:selfChange:User:allowSelfChange": true
  }

Sample Request: /UserStatusChanger

{
    "active": true,
    "urn:ietf:params:scim:schemas:oracle:idcs:extension:selfChange:User:allowSelfChange": true,
    "schemas": [
      "urn:ietf:params:scim:schemas:oracle:idcs:UserStatusChanger"
    ]
  }

Sample Requests: /ApiKeys

{
    "user": {
        "value": "<unique_ID>"
    },
    "key": "-----BEGIN PUBLIC KEY-----<your_public_key>
 -----END PUBLIC KEY-----",
    "urn:ietf:params:scim:schemas:oracle:idcs:extension:selfChange:User:allowSelfChange": true,
    "schemas": [
        "urn:ietf:params:scim:schemas:oracle:idcs:apikey"
    ]
}

{
      "Operations": [
        {
          "op": "replace",
          "path": "description",
          "value": "<updated_api_key>"
        },
        {
            "op": "add",
            "path": "urn:ietf:params:scim:schemas:oracle:idcs:extension:selfChange:User:allowSelfChange",
            "value": true
        }
      ],
      "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:PatchOp"
      ]
    }

Sample Requests: /SmtpCredentials

{
    "description": "John's smtp credential",
    "user": {
        "value": "<unique_ID>"
    },
    "urn:ietf:params:scim:schemas:oracle:idcs:extension:selfChange:User:allowSelfChange": true,
    "schemas": [
        "urn:ietf:params:scim:schemas:oracle:idcs:smtpCredential"
    ]
}

{
      "Operations": [
        {
          "op": "replace",
          "path": "description",
          "value": "updated_credential_description"
        },
        {
            "op": "add",
            "path": "urn:ietf:params:scim:schemas:oracle:idcs:extension:selfChange:User:allowSelfChange",
            "value": true
        }
      ],
      "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:PatchOp"
      ]
    }

Operation: DELETE /admin/v1/SmtpCredentials/e1eaf8a28e58485fb86f16f914fd08c7?allowSelfChange=true

Sample Requests: /AuthTokens

{
    "description": "John's auth token",
    "user": {
        "value": "<unique_ID>"
    },
    "urn:ietf:params:scim:schemas:oracle:idcs:extension:selfChange:User:allowSelfChange": true,
    "schemas": ["urn:ietf:params:scim:schemas:oracle:idcs:authToken"]
}

{
      "Operations": [
        {
          "op": "replace",
          "path": "description",
          "value": "<updated_credential_description>"
        },
        {
            "op": "add",
            "path": "urn:ietf:params:scim:schemas:oracle:idcs:extension:selfChange:User:allowSelfChange",
            "value": true
        }
      ],
      "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:PatchOp"
      ]
    }

Operation: DELETE /admin/v1/SmtpCredentials/e1eaf8a28e58485fb86f16f914fd08c7?allowSelfChange=true

Sample Requests: /CustomerSecretKeys

{
    "diplayName": "Alice Customer Secret Key",
    "description": "Alice's Customer Secret Key",
    "user": {
        "value": "<unique_ID>"
    },
    "urn:ietf:params:scim:schemas:oracle:idcs:extension:selfChange:User:allowSelfChange": true,
    "schemas": [
        "urn:ietf:params:scim:schemas:oracle:idcs:customerSecretKey"
    ]
}

{
      "Operations": [
        {
          "op": "replace",
          "path": "description",
          "value": "<updated_credential_description>"
        },
        {
            "op": "add",
            "path": "urn:ietf:params:scim:schemas:oracle:idcs:extension:selfChange:User:allowSelfChange",
            "value": true
        }
      ],
      "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:PatchOp"
      ]
    }

Operation: DELETE /admin/v1/CustomerSecretKeys/e1eaf8a28e58485fb86f16f914fd08c7?allowSelfChange=true

Sample Requests: /OAuth2ClientCredentials

{
  "name": "User's oauth2 client credential",
  "scopes": [
    {
      "audience": "urn:opc:idm",
      "scope": "__myscopes__"
    }
  ],
  "user": {
    "value": "<unique_ID>"
  },
    "urn:ietf:params:scim:schemas:oracle:idcs:extension:selfChange:User:allowSelfChange": true,
  "schemas": [
    "urn:ietf:params:scim:schemas:oracle:idcs:oauth2ClientCredential"
  ]
}

{
      "Operations": [
        {
          "op": "replace",
          "path": "description",
          "value": "<updated_credential_description>"
        },
        {
            "op": "add",
            "path": "urn:ietf:params:scim:schemas:oracle:idcs:extension:selfChange:User:allowSelfChange",
            "value": true
        }
      ],
      "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:PatchOp"
      ]
    }

Operation: DELETE /admin/v1/OAuth2ClientCredentials/e1eaf8a28e58485fb86f16f914fd08c7?allowSelfChange=true

Sample Request: /SupportAccounts

{
    "schemas": [
        "urn:ietf:params:scim:schemas:oracle:idcs:supportAccount"
    ],
    "token": "dummy",
    "user": {
        "ocid": "ocid1.user.region1..<unique_ID>"
    },
    "urn:ietf:params:scim:schemas:oracle:idcs:extension:selfChange:User:allowSelfChange": true
}

Operation: DELETE /admin/v1/ApiKeys/e1eaf8a28e58485fb86f16f914fd08c7?allowSelfChange=true

Attribute Definitions

Examples

{
  "Operations": [
    {
      "op": "replace",
      "path": "socialJitProvisioningEnabled",
      "value": true
    },
    {
      "op": "replace",
      "path": "jitProvGroupStaticListEnabled",
      "value": true
    },
    {
        "op": "add",
        "path": "jitProvAssignedGroups",
        "value": [
            {
              "value": “<identitydomain-group-id>”
            }
        ]
    }
  ],
  "schemas": [
    "urn:ietf:params:scim:api:messages:2.0:PatchOp"
  ]
}

{
    "idcsCreatedBy": {
        "type": "User",
        "display": "admin opc",
        "value": “<user-id>",
        "$ref": "https://<domainURL>/admin/v1/Users/<user-id>"
    },
    "id": "<identity-provider-id>",
    "meta": {
        "created": "2024-04-29T17:26:15.646Z",
        "lastModified": "2024-06-06T22:03:43.284Z",
        "version": "<version number>",
        "resourceType": "IdentityProvider",
        "location": "https://<domainURL> /admin/v1/IdentityProviders/<identity-provider-id>"
    },
    "enabled": true,
    "idcsLastModifiedBy": {
        "value": "<user-id>",
        "display": "admin opc",
        "type": "User",
        "$ref": "https://<domainURL>/admin/v1/Users/15ae5123456123456aa123456xxx123456"
    },
    "partnerName": "Google",
    "ocid": “<domain-ocid>",
    "socialJitProvisioningEnabled": true,
    "jitProvGroupStaticListEnabled": true,
    "accountLinkingEnabled": true,
    "registrationEnabled": true,
    "serviceProviderName": "Google",
    "consumerSecret": "clientSecret12345",
    "idAttribute": "email",
    "consumerKey": "clientID12345",
    "jitProvAssignedGroups": [
        {
            "value": "<idcs-group-id>",
            "$ref": "https://<domain-id>/admin/v1/Groups/"<idcs-group-id>"
        }
    ],
    "schemas": [
        "urn:ietf:params:scim:schemas:oracle:idcs:SocialIdentityProvider"
    ],
    "name": "Google",
    "showOnLogin": true
}

{
    "id": "<identity-provider-id>",
    "jitProvAssignedGroups": [
        {
            "value": "<idcs-group-id>",
            "$ref": "https://<domain-id>/admin/v1/Groups/"<idcs-group-id>"
        }
    ],
    "name": "Google"
}

{
  "schemas": [
    "urn:ietf:params:scim:api:messages:2.0:PatchOp"
  ],
  "Operations": [
    {
      "op": "remove",
      "path": "jitProvAssignedGroups[value eq \"<idcs-group-id>\"]"
    }
  ]
}

{
    "idcsCreatedBy": {
        "type": "User",
        "display": "admin opc",
        "value": “<user-id>",
        "$ref": "https://<domainURL>/admin/v1/Users/<user-id>"
    },
    "id": "<identity-provider-id>",
    "meta": {
        "created": "2024-04-29T17:26:15.646Z",
        "lastModified": "2024-06-06T22:16:47.515Z",
        "version": "<version number>",
        "resourceType": "IdentityProvider",
        "location": "https://<domainURL> /admin/v1/IdentityProviders/<identity-provider-id>"
    },
    "enabled": true,
    "idcsLastModifiedBy": {
        "value": "<user-id>",
        "display": "admin opc",
        "type": "User",
        "$ref": "https://<domainURL>/admin/v1/Users/15ae5123456123456aa123456xxx123456"
    },
    "partnerName": "Google",
    "ocid": “<domain-ocid>",
    "socialJitProvisioningEnabled": true,
    "jitProvGroupStaticListEnabled": true,
    "accountLinkingEnabled": true,
    "registrationEnabled": true,
    "serviceProviderName": "Google",
    "consumerSecret": "clientSecret12345",
    "idAttribute": "email",
    "consumerKey": "clientID12345",
    "schemas": [
        "urn:ietf:params:scim:schemas:oracle:idcs:SocialIdentityProvider"
    ],
    "name": "Google",
    "showOnLogin": true
}

{
  "schemas": [
    "urn:ietf:params:scim:api:messages:2.0:PatchOp"
  ],
  "Operations": [
    {
      "op": "remove",
      "path": "jitProvAssignedGroups"
    }
  ]
}

{
    "idcsCreatedBy": {
        "type": "User",
        "display": "admin opc",
        "value": “<user-id>",
        "$ref": "https://<domainURL>/admin/v1/Users/<user-id>"
    },
    "id": "<identity-provider-id>",
    "meta": {
        "created": "2024-04-29T17:26:15.646Z",
        "lastModified": "2024-06-06T22:16:47.515Z",
        "version": "<version number>",
        "resourceType": "IdentityProvider",
        "location": "https://<domainURL> /admin/v1/IdentityProviders/<identity-provider-id>"
    },
    "enabled": true,
    "idcsLastModifiedBy": {
        "value": "<user-id>",
        "display": "admin opc",
        "type": "User",
        "$ref": "https://<domainURL>/admin/v1/Users/15ae5123456123456aa123456xxx123456"
    },
    "partnerName": "Google",
    "ocid": “<domain-ocid>",
    "socialJitProvisioningEnabled": true,
    "jitProvGroupStaticListEnabled": true,
    "accountLinkingEnabled": true,
    "registrationEnabled": true,
    "serviceProviderName": "Google",
    "consumerSecret": "clientSecret12345",
    "idAttribute": "email",
    "consumerKey": "clientID12345",
    "schemas": [
        "urn:ietf:params:scim:schemas:oracle:idcs:SocialIdentityProvider"
    ],
    "name": "Google",
    "showOnLogin": true
}

Step 1: Create a User

This step shows how to create a user by submitting a POST request on the REST resource using cURL. For more information about cURL, see Use cURL.

   curl
   -X POST
   -H "Content-Type:application/json"
   -H "Authorization: Bearer <Access Token Value>"https://<domainURL>/admin/v1/Users

Example of Request Body

The following shows an example of a request body in JSON format:

{
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User",
        "urn:ietf:params:scim:schemas:oracle:idcs:extension:userState:User"
    ],
    "userName": "bjensen@example.com",
    "password": "{{password}}",
    "name": {
        "familyName": "Jensen",
        "givenName": "Barbara",
        "middleName": "Jane"
    },
    "emails": [
        {
            "value": "bjensen@example.com",
            "type": "work",
            "primary": true
        }
    ]
}

Example of Response Body

The following shows an example of the response body:

{
    "idcsCreatedBy": {
        "type": "User",
        "display": "admin opc",
        "value": "6aa2585abd464991929bcf05ace532e9",
        "$ref": "[https://<domainURL>/admin/v1/Users/6aa2585abd464991929bcf05ace532e9]"
    },
    "id": "ff9a9207fc8c4fd2b3d76af84235e8fd",
    "meta": {
        "created": "2022-03-01T05:19:52.765Z",
        "lastModified": "2022-03-01T05:19:52.765Z",
        "resourceType": "User",
        "location": "[https://<domainURL>/admin/v1/Users/ff9a9207fc8c4fd2b3d76af84235e8fd]"
    },
    "active": true,
    "displayName": "Barbara Jensen",
    "idcsLastModifiedBy": {
        "value": "6aa2585abd464991929bcf05ace532e9",
        "display": "admin opc",
        "type": "User",
        "$ref": "[https://<domainURL>/admin/v1/Users/6aa2585abd464991929bcf05ace532e9]"
    },
    "userName": "bjensen2",
    "emails": [
        {
            "verified": false,
            "primary": false,
            "secondary": false,
            "value": "[bjensen@example.com|mailto:bjensen@example.com]",
            "type": "recovery"
        },
        {
            "verified": false,
            "primary": true,
            "secondary": false,
            "value": "[bjensen@example.com|mailto:bjensen@example.com]",
            "type": "work"
        }
    ],
    "urn:ietf:params:scim:schemas:example:idcs:extension:userState:User": {
        "locked": {
            "on": false
        }
    },
    "name": {
        "familyName": "Jensen",
        "givenName": "Barbara",
        "formatted": "Barbara Jane Jensen",
        "middleName": "Jane"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User",
        "urn:ietf:params:scim:schemas:example:idcs:extension:userState:User"
    ]
}

Step 2: Get a User

This step shows how to retrieve a user by the user's ID by submitting a GET request on the REST resource using cURL. For more information about cURL, see Use cURL.

   curl
   -X GET
   -H "Content-Type:application/scim+json"
   -H "Authorization: Bearer <Access Token Value>"https://<domainURL>/admin/v1/Users/<user_ocid or user_id>

Example of Response Body

The following example shows the contents of the response body in JSON format:

{
    "displayName": "Barbara Jensen",
    "name": {
        "givenName": "Barbara",
        "formatted": "Barbara Jane Jensen",
        "middleName": "Jane",
        "familyName": "Jensen"
    },
    "urn:ietf:params:scim:schemas:oracle:idcs:extension:userState:User": {
        "locked": {
            "on": false
        }
    },
    "userName": "bjensen@example.com",
    "id": "ff9a9207fc8c4fd2b3d76af84235e8fd",
    "active": true,
    "emails": [
        {
            "verified": "false",
            "value": "bjensen@example.com",
            "type": "recovery"
        },
        {
            "primary": true,
            "value": "bjensen@example.com",
            "type": "work"
        }
    ],
    "schemas": [
        "urn:ietf:params:scim:schemas:oracle:idcs:extension:userState:User",
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "meta": {
        "resourceType": "User",
        "created": "2022-07-13T07:28:59.227Z",
        "lastModified": "2022-07-13T07:28:59.227Z",
        "location": "http://<domainURL>/admin/v1/Users/ff9a9207fc8c4fd2b3d76af84235e8fd"
    },
    "idcsCreatedBy": {
        "value": "f8fa30db0f5f41f98de00bc07c05a73d",
        "$ref": "/OAuthClients/f8fa30db0f5f41f98de00bc07c05a73d",
        "type": "OAuthClient",
        "display": "admin"
    },
    "idcsLastModifiedBy": {
        "value": "f8fa30db0f5f41f98de00bc07c05a73d",
        "$ref": "/OAuthClients/f8fa30db0f5f41f98de00bc07c05a73d",
        "type": "OAuthClient",
        "display": "admin"
    }
}

Step 3: Initiate Self-Service Email Verification

This step shows how to initiate email validation of either the user's primary or recovery email address by submitting a PUT request on the REST resource using cURL. For more information about cURL, see Using cURL.

   curl
   -X PUT
   -H "Content-Type:application/scim+json"
   -H "Authorization: Bearer <Access Token Value>"https://<domainURL>/admin/v1/MeEmailVerifier

Example of Request Body

The following shows an example of a request body in JSON format:

{
    "email": "bjensen@example.com",
    "schemas": [
        "urn:ietf:params:scim:schemas:oracle:idcs:MeEmailVerifier"
    ],
    "id": "ff9a9207fc8c4fd2b3d76af84235e8fd",
    "userFlowControlledByExternalClient": true,
    "triggerEmailVerificationFlowIfEmailAlreadyVerified": true
}

Example of Response Body

The following example shows the contents of the response body in JSON format:

{
    "email": "bjensen@example.com",
    "schemas": [
        "urn:ietf:params:scim:schemas:oracle:idcs:MeEmailVerifier"
    ],
    "id": "ff9a9207fc8c4fd2b3d76af84235e8fd",
    "userFlowControlledByExternalClient": true,
    "triggerEmailVerificationFlowIfEmailAlreadyVerified": true,
    "meta": {
        "resourceType": "MeEmailVerifier",
        "location": "https://<domainURL>/admin/v1/MeEmailVerifier/57044ca14d274d789a586e5ec77c26f3"
    },
    "userToken": {
        "value": "db21a3578d27439ca9fab6349be46c30",
        "$ref": "https://<domainURL>/admin/v1/UserTokens/db21a3578d27439ca9fab6349be46c30"
    }
}

Step 4: Obtain a User Token

This step shows how to retrieve a user token using its ID by submitting a GET request on the REST resource using cURL. For more information about cURL, see Using cURL.

   curl
-X GET
   -H "Content-Type:application/scim+json"
   -H "Authorization: Bearer <Access Token Value>"https://<domainURL>/admin/v1/UserTokens/{{usertokenid}}

Example of Response Body

The following example shows the contents of the response body in JSON format:

{
    "expiryTime": "2022-07-13T07:28:59.227Z",
    "token": "KtXTrZkyIC2OWYVChbYEtfWnE7zhxlYJ0roEvsj0F2I=",
    "tokenType": "email",
    "userId": "5a7550ad5cfa4f50bdc608da1831481b",
    "data": "bjensen@example.com",
    "eventId": "admin.user.password.reset.success",
    "status": 0,
    "id": "3e4b69e99ddf472989e089a904a3c1a7",
    "meta": {
        "created": "2022-07-13T07:28:59.227Z",
        "lastModified": "2022-07-13T07:28:59.227Z",
        "resourceType": "UserToken",
        "location": "$baseUri/UserTokens/{id}"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:oracle:idcs:UserToken"
    ],
    "idcsCreatedBy": {
        "value": "14171fc6031a417cac680cdb9d82c2ea",
        "display": "admin",
        "type": "OAuthClient",
        "$ref": "$baseUri/OAuthClient/{id}"
    },
    "idcsLastModifiedBy": {
        "value": "14171fc6031a417cac680cdb9d82c2ea",
        "display": "admin",
        "type": "OAuthClient",
        "$ref": "$baseUri/OAuthClient/{id}"
    }
}

Step 5: Self-Verify Email Address

This step shows how to verify a new email address by submitting a POST request on the REST resource using cURL. This endpoint validates the token, and then marks the email address as verified. For more information about cURL, see Use cURL.

   curl
   -X POST
   -H "Content-Type:application/scim+json"
   -H "Authorization: Bearer <Access Token Value>"https://<domainURL>/admin/v1/MeEmailVerified

Example of Request Body

The following shows an example of a request body in JSON format:

{
  "token": "YzQwYTc4NmE5YmEzNGU4MDg0YjFkY2FhZWRmNThlOTc6TEFGaWtuTXI5OjIwMTUtMDctMjRUMDI6Mjk6NDEuNzEwWg==",
  "schemas": [
    "urn:ietf:params:scim:schemas:oracle:idcs:MeEmailVerified"
  ]
}

Example of Response Body

The following example shows the contents of the response body in JSON format:

{
    "schemas": [
        "urn:ietf:params:scim:schemas:oracle:idcs:extension:MeEmailVerified"
    ],
    "id": "5fed0efce51f40b4a42b0773a65178c3",
    "meta": {
        "resourceType": "MeEmailVerified",
        "location": "https://<domainURL>/admin/v1/MeEmailVerified/57044ca14d274d789a586e5ec77c26f3"
    }
}

Step1: Create the Self Service Enrollment Using the SMS Factor

This step initiates SMS enrollment in a POST request to the /admin/v1/MyAuthenticationFactorEnroller endpoint. The client must include the following attributes:

Request Example

The following example shows the contents of the POST request body in JSON format:

{
  "schemas": [
    "urn:ietf:params:scim:schemas:oracle:idcs:AuthenticationFactorEnroller"
  ],
  "user": {
    "value": "c810ff4522eb437abac013291c1984d1"
  },
  "displayName": "Joe's Personal Phone",
  "countryCode": "+44",
  "phoneNumber": "1122334455",
  "authnFactors": [
    "SMS"
  ]
} 

Response Example

The following example shows the contents of the response body in JSON format:

{
    "schemas": [
        "urn:ietf:params:scim:schemas:oracle:idcs:AuthenticationFactorEnroller"
    ],
    "user": {
        "value": "c810ff4522eb437abac013291c1984d1",
        "$ref": "https://example.identitycloud.com/admin/v1/Users/c810ff4522eb437abac013291c1984d1"
    },
    "displayName": "Joe's Personal Phone",
    "countryCode": "+44",
    "phoneNumber": "XXXXXXX455",
    "authnFactors": [
        "SMS"
    ],
    "meta": {
        "resourceType": "MyAuthenticationFactorEnroller",
        "location": "https://example.identitycloud.com/admin/v1/MyAuthenticationFactorEnroller"
    },
    "deviceId": "92142250e2ab4608b5c6532eb73e3d7c",
    "requestId": "a0a7f9bf-13a8-43f3-bcc7-2087dc3f7a18o-o1548346179"
}

In the response, the deviceId and the requestId should be passed in the next step.

Error Response Examples

{
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:Error",
        "urn:ietf:params:scim:api:oracle:idcs:extension:messages:Error"
    ],
    "detail": "AuthenticationFactorEnroller.user references a User with ID 1fa35f74491d44ef5a7cc25bfdb1c8b1c that does not exist.",
    "status": "400",
    "urn:ietf:params:scim:api:oracle:idcs:extension:messages:Error": {
        "messageId": "error.common.validation.invalidReferenceResource"
    }
}

The following example shows the error message in JSON format if a phoneNumber is incorrect. You get a 400 HTTP response code.

{
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:Error",
        "urn:ietf:params:scim:api:oracle:idcs:extension:messages:Error"
    ],
    "detail": "Your phone number +91123 is not valid.",
    "status": "400",
    "urn:ietf:params:scim:api:oracle:idcs:extension:messages:Error": {
        "messageId": "error.ssocommon.auth.invalidPhoneNumber",
        "additionalData": {
            "params": "+91123",
            "msgId": "error.ssocommon.auth.invalidPhoneNumber"
        }
    }
}

Step 2: Initiate the Self Service Enrollment Using the OTP by SMS

This step requests that the OTP be sent through SMS in a POST request to the /admin/v1/MyAuthenticationFactorInitiator endpoint. The client must include the following attributes:

requestId: received in the Step 1 response

deviceId: received in the Step 1 response

userName: username of the user

Request Example

The following example shows the contents of the POST request body in JSON format:

{
  "schemas": [
    "urn:ietf:params:scim:schemas:oracle:idcs:AuthenticationFactorInitiator"
  ],
  "deviceId": "92142250e2ab4608b5c6532eb73e3d7c",
  "requestId": "a0a7f9bf-13a8-43f3-bcc7-2087dc3f7a18o-o1548346179",
  "userName": "jbloggs",
  "authFactor": "SMS"
}

Response Example

The following example shows the contents of the response in JSON format:

{
    "deviceId": "92142250e2ab4608b5c6532eb73e3d7c",
    "requestId": "a0a7f9bf-13a8-43f3-bcc7-2087dc3f7a18o-o1548346179",
    "authFactor": "SMS",
    "userName": "jbloggs",
    "displayName": "Joe's Personal Phone",
    "schemas": [
        "urn:ietf:params:scim:schemas:oracle:idcs:AuthenticationFactorInitiator"
    ]
}

An OTP code is sent by using SMS to the user's mobile device. In the response deviceId and requestId should be passed in the next step.

2a. Initiate the Self Service Enrollment Request to Resend OTP by SMS

In case the user wants the server to "resend" the OTP, then same payload as mentioned in the Step 2 should be sent to the server again.

Request Example

The following example shows the contents of the POST request body in JSON format:

{
  "schemas": [
    "urn:ietf:params:scim:schemas:oracle:idcs:AuthenticationFactorInitiator"
  ],
  "deviceId": "92142250e2ab4608b5c6532eb73e3d7c",
  "requestId": "a0a7f9bf-13a8-43f3-bcc7-2087dc3f7a18o-o1548346179",
  "userName": "jbloggs",
  "authFactor": "SMS"
}

Response Example

The following example shows the contents of the response in JSON format:

{ 
    "deviceId": "92142250e2ab4608b5c6532eb73e3d7c",
    "requestId": "a0a7f9bf-13a8-43f3-bcc7-2087dc3f7a18o-o1548346179",
    "authFactor": "SMS",
    "userName": "jbloggs",
    "displayName": "Joe's Personal Phone",
    "schemas": [
        "urn:ietf:params:scim:schemas:oracle:idcs:AuthenticationFactorInitiator"
    ]
}

An OTP code is sent using SMS to the user's mobile device. In the response deviceId and requestId should be passed in the next step.

Step 3: Validate the Self Service Enrollment Using the OTP

This step validates the SMS enrollment of a user in a POST request to the /admin/v1/MyAuthenticationFactorValidator endpoint.

The client must include the following attributes:

Request Example

The following example shows the contents of the POST request in JSON format:

{
  "schemas": [
    "urn:ietf:params:scim:schemas:oracle:idcs:AuthenticationFactorValidator"
  ],
  "deviceId": "92142250e2ab4608b5c6532eb73e3d7c",
  "requestId": "a0a7f9bf-13a8-43f3-bcc7-2087dc3f7a18o-o1548346179",
  "otpCode": "191224",
  "authFactor": "SMS",
  "scenario": "ENROLLMENT"
}
    

Response Example

The following example shows the contents of the response in JSON format:

{
    "authFactor": "SMS",
    "deviceId": "92142250e2ab4608b5c6532eb73e3d7c",
    "requestId": "a0a7f9bf-13a8-43f3-bcc7-2087dc3f7a18o-o1548346179",
    "scenario": "ENROLLMENT",
    "status": "SUCCESS",
    "displayName": "Joe's Personal Phone",
    "schemas": [
        "urn:ietf:params:scim:schemas:oracle:idcs:AuthenticationFactorValidator"
    ],
    "mfaStatus": "ENROLLED",
    "mfaPreferredDevice": "2b27b8c072d64b899d41c8470acea32a",
    "mfaPreferredAuthenticationFactor": "SMS",
    "securityQuestionsPresent": false,
    "devicesCount": 3,
    "emailFactorEnrolled": true
} 

Error Response Examples

The following example shows the error message in JSON format if OTP is incorrect. You get a 401 HTTP response code and the enrollment fails.

{
  "schemas": [
    "urn:ietf:params:scim:api:messages:2.0:Error",
    "urn:ietf:params:scim:api:oracle:idcs:extension:messages:Error"
  ],
  "detail": "Invalid passcode.",
  "status": "401",
  "urn:ietf:params:scim:api:oracle:idcs:extension:messages:Error": {
    "messageId": "error.ssocommon.auth.invalidPasscode"
  }
}

Sample Request

curl
-X POST
-H "Content-Type:application/scim+json"
-H "Authorization: Bearer <Access_Token>"
https://<domainURL>/admin/v1/Bulk

Sample Payload

{
   "schemas": [
      "urn:ietf:params:scim:api:messages:2.0:BulkRequest"
   ],
   "Operations": [
      {
         "method": "POST",
         "path": "/AuthenticationFactorsRemover",
         "bulkId": "<bulkid1>",
         "data": {
            "schemas": [
               "urn:ietf:params:scim:schemas:oracle:idcs:AuthenticationFactorsRemover"
            ],
            "user":
{                "value": "<user_1_id>"             }
         }
      },
      {
         "method": "POST",
         "path": "/AuthenticationFactorsRemover",
         "bulkId": "<bulkid2>",
         "data": {
            "schemas": [
               "urn:ietf:params:scim:schemas:oracle:idcs:AuthenticationFactorsRemover"
            ],
            "user":
{                "value": "<user_2_id>"             }
         }
      }
   ]
}

Enabling the onBehalfOf Allowed Operation

Use the identity domains REST API to create or update an OAuth application, and specify onBehalfOfUser as an allowed operation. When you create an OAuth application using the identity domains UI, on the Authorization page, select the checkbox for the On behalf Of allowed operation. When users access the application, they can perform various functions based on their permissions.

Example

The example shows how to create an application and specify the onBehalfOfUser allowed operation (in bold in the example).

cat</tmp/OAuthClientApp.json << __EOF__
{
  "schemas": [
    "urn:ietf:params:scim:schemas:oracle:idcs:App"
  ],
  "displayName": "publicClientApp",
  "isOAuthClient": true,
  "description": "public client",
  "active": true,
  "clientType": "public",
  "basedOnTemplate": {
    "value": "CustomBrowserMobileTemplateId"
  },
  "redirectUris": [
    "http://example.com:9090/demoapp/return",
    "http://example.com:9090/IDCSPlayground"
  ],
  "logoutUri": "http://example.com:9090/demoapp/logout.jsp",
  "postLogoutRedirectUris": ["http://example.com:9090/demoapp/logout.jsp"],
  "allowedScopes": [
    {
      "fqs": "http://example.com/photos"
    },
    {
      "fqs": "http://example.com/presentations"
    },
    {
      "fqs": "http://example.com/documents"
    }
  ],
  "allowedOperations": [
    "onBehalfOfUser"   ],
  "allowedGrants": [
    "authorization_code",
    "implicit"
  ]
}
__EOF__
   
curl -X POST 
-H "Content-type: application/json" 
-H "Authorization: Bearer <access token value>" 
--data @/tmp/OAuthClientApp.json http://<domainURL>/admin/v1/Apps

Audit Schema

You can find the Audit Schema using the identity domains REST API. The Audit Schema contains all the information discussed in the tables of this use case.

Example Request

Perform a GET on the /Schemas endpoint using the AuditEvent schema.

GET <domainURL>>/admin/v1/Schemas/urn:ietf:params:scim:schemas:oracle:idcs:AuditEvent

Example Response Snapshot

The following is a snapshot of the response.

{
    "attributes": [
        {
            "caseExact": false,
            "description": "Unique URI of the schema",
            "idcsDisplayName": "ID",
            "idcsSearchable": true,
            "multiValued": false,
            "mutability": "readOnly",
            "name": "id",
            "required": true,
            "returned": "always",
            "type": "string",
            "uniqueness": "global"
        },
        {
            "caseExact": false,
            "description": "An identifier for the Resource as defined by the Service Consumer. The externalId may simplify identification of the Resource between Service Consumer and Service Provider by allowing the Consumer to refer to the Resource with its own identifier, obviating the need to store a local mapping between the local identifier of the Resource and the identifier used by the Service Provider. Each Resource MAY include a non-empty externalId value. The value of the externalId attribute is always issued by the Service Consumer and can never be specified by the Service Provider. The Service Provider MUST always interpret the externalId as scoped to the Service Consumer's tenant.",
            "idcsDisplayName": "External ID",
            "idcsSearchable": false,
            "multiValued": false,
            "mutability": "readWrite",
            "name": "externalId",
            "required": false,
            "returned": "default",
            "type": "string",
            "uniqueness": "none"
        },
        {
            "caseExact": true,
            "description": "Event correlation ID (ECID) correlating a chain of events as belonging to the same business operation (root task). ECID is generated when the request enters the IDCS web tier.",
            "idcsDisplayName": "Execution Context Id",
            "idcsSearchable": true,
            "multiValued": false,
            "mutability": "readWrite",
            "name": "ecId",
            "required": false,
            "returned": "default",
            "type": "string",
            "uniqueness": "none"
        },
        {
            "caseExact": true,
            "description": "Relationship Identifier (RID). This value indicates the position of a particular event/sub-operation within the tree of tasks that begins with the root task.",
            "idcsDisplayName": "Relationship Id",
            "idcsSearchable": true,
            "multiValued": false,
            "mutability": "readWrite",
            "name": "rId",
            "required": false,
            "returned": "default",
            "type": "string",
            "uniqueness": "none"
        },
        {
            "caseExact": false,
            "description": "Timestamp of when the event occurred, provided by the Event Manager (not supplied by clients)",
            "idcsDisplayName": "Timestamp",
            "idcsSearchable": true,
            "multiValued": false,
            "mutability": "readWrite",
            "name": "timestamp",
            "required": false,
            "returned": "default",
            "type": "dateTime",
            "uniqueness": "none"
        },