Getting Started
Authentication
API Versioning
V3 API Standard Collection Parameters
Access Requests
Account Activities
Certifications
Certification Summaries
Public Identities
Public Identities Config
Requestable Objects
Saved Search
Scheduled Search
Search
Reference
Models
IAI Recommendations
IAI Peer Group Strategies
Access Request Approvals
Access Requests
Account Activities
Accounts
Certifications
Certification Campaigns
Lifecycle States
Managed Clusters
Non-Employee Lifecycle Management
Notifications
OAuth Clients
Password Dictionary
Personal Access Tokens
Public Identity Config
Requestable Objects
Role Insights
Service Desk Integration
Sources
Tagged Objects
Task Management
Triggers
SOD Policy
Reference
Models

Authentication

Overview

In order to use IdentityNow REST API web-services, you must first authenticate with IdentityNow and get an accessToken. This token is used in all IdentityNow web-services calls to authorize its usage. Steps of the flow are as follows:

Flow

  1. Access Token Request - The HTTP client (a script, application, Postman, CURL, etc.) makes a request to IdentityNow to get an access token. The details and nuances of how this is done are described in detail in the Authentication Details section.
  2. Access Token Response - Assuming the request is valid, IdentityNow will issue an access token to the HTTP client in response.
  3. API Request - The HTTP client makes a request to an IdentityNow’s API. Included in that request as part of the HTTP headers, is a bearer authorization with the access token granted by the previous step.
  4. API Response - Assuming the request and the access token is valid, IdentityNow will issue a response to the requested API. If unexpected errors occur, see the Troubleshooting section of this document.

SailPoint authentication and authorization model is fully OAuth 2.0 compliant, with issued access tokens leveraging the JSON Web Token (JWT) token standard. This document describes the details around this and should be essential to any developer seeking to leverage IdentityNow REST APIs.

OAuth 2.0

OAuth 2.0 is an industry-standard protocol for authorization, and provides a variety of authorization flows for web applications, desktop applications, mobile phones, and devices. This specification and its extensions are developed within the IETF OAuth Working Group.

There are several different authorization flows that OAuth 2.0 supports, and each of these has a grant-type which defines the different use cases. Some of the common ones which might be used with IdentityNow are as follows:

  1. Authorization Code - This grant type is used by clients to exchange an authorization code for an access token. This is mainly used for web applications as there is a login into IdentityNow, with a subsequent redirect back to the web application / client.
  2. Client Credentials - This grant type is used by clients to obtain an access token outside the context of a user. Because this is outside of a user context, only a subset of IdentityNow REST APIs may be accessible with this kind of grant type.
  3. Refresh Token - This grant type is used by clients in order to exchange a refresh token for an access token when the existing access token has expired. This allows clients to continue to have a valid access token without further interaction with the user.

JSON Web Token (JWT)

JSON Web Token (JWT) is an industry-standard protocol for creating access tokens which assert various claims about the resource who has authenticated. The tokens have a specific structure consisting of a header, payload, and signature.

In IdentityNow they look something like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0ZW5hbnRfaWQiOiI1OGViMDZhNC1kY2Q3LTRlOTYtOGZhYy1jY2EyYWZjMDNlNjEiLCJpbnRlcm5hbCI6dHJ1ZSwicG9kIjoiY29vayIsIm9yZyI6ImV4YW1wbGUiLCJpZGVudGl0eV9pZCI6ImZmODA4MTgxNTVmZThjMDgwMTU1ZmU4ZDkyNWIwMzE2IiwidXNlcl9uYW1lIjoic2xwdC5zZXJ2aWNlcyIsInN0cm9uZ19hdXRoIjp0cnVlLCJhdXRob3JpdGllcyI6WyJPUkdfQURNSU4iXSwiY2xpZW50X2lkIjoibktCUE93akpIOExYU2pJbCIsInN0cm9uZ19hdXRoX3N1cHBvcnRlZCI6dHJ1ZSwidXNlcl9pZCI6IjU5NTgyNiIsInNjb3BlIjpbInJlYWQiLCJ3cml0ZSJdLCJleHAiOjE1NjU4ODgzMTksImp0aSI6ImM5OGQxMjM2LTQ1MTMtNGM4OS1hMGQwLTBjYjlmMzI3NmI1NiJ9.SAY4ZQkXGi2cY_qz57Ah9_zDq4-bnF-oDJKotXa-LCY

If you were to decode the access token data, it might look something like this:

Header

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload

{
  "tenant_id": "58eb06a4-dcd7-4e96-8fac-cca2afc03e61",
  "internal": true,
  "pod": "cook",
  "org": "example",
  "identity_id": "ff80818155fe8c080155fe8d925b0316",
  "user_name": "slpt.services",
  "strong_auth": true,
  "authorities": [
    "ORG_ADMIN"
  ],
  "client_id": "nKBPOwjJH8LXSjIl",
  "strong_auth_supported": true,
  "user_id": "595826",
  "scope": [
    "read",
    "write"
  ],
  "exp": 1565888319,
  "jti": "c98d1236-4513-4c89-a0d0-0cb9f3276b56"
}

Signature

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  {secret}
)

You can check the JWT access token data online at jwt.io.

Authentication Details

This section details how to call the SailPointpPlatform OAuth 2.0 token end-points to get an access token.

Prerequisites

Before any OAuth 2.0 token requests can be initiated, a Client ID and secret are necessary. This can be generated by following these instructions: Create OAuth Client

OAuth 2.0 Token Request

When authenticating against IdentityNow, the OAuth 2.0 token end-point resides on the IdentityNow API Gateway at:

POST https://{org}.api.identitynow.com/oauth/token

How you call this end-point to get your token, depends largely on the OAuth 2.0 flow and grant type you wish to implement. While there are other grant flows in OAuth 2.0, the common OAuth 2.0 grant flows used with IdentityNow are:

  1. Authorization Code - This grant type is used by clients to exchange an authorization code for an access token. This is mainly used for web applications as there is a login into IdentityNow, with a subsequent redirect back to the web application / client.
  2. Client Credentials - This grant type is used by clients to obtain an access token outside the context of a user. Because this is outside of a user context, only a subset of IdentityNow REST APIs may be accessible with this kind of grant type.
  3. Refresh Token - This grant type is used by clients in order to exchange a refresh token for an access token when the existing access token has expired. This allows clients to continue to have a valid access token without further interaction with the user.

The specifics (and example calls) for each grant type flow with IdentityNow is detailed in the following sections.

Authorization Code Grant Flow

Further Reading: https://oauth.net/2/grant-types/authorization-code/

This grant type is used by clients to exchange an authorization code for an access token. This is mainly used for web apps as there is a login into IdentityNow, with a subsequent redirect back to the web app / client.

The client ID and secret must always be kept secure, so SailPoint recommends storing this configuration server-side as a web-app configuration.

The OAuth 2.0 client you are using must have AUTHORIZATION_CODE as one of its grantTypes. The redirect URLs must also match the list in the client as well:

{
  "enabled": true,
  "created": "2019-05-23T02:06:20.685Z",
  "name": "My Application",
  "description": "My Application",
  "id": "b61429f5-203d-494c-94c3-04f54e17bc5c",
  "secret": null,
  "grantTypes": [
    "AUTHORIZATION_CODE"
    ...
  ],
  "redirectUris": [
    "http://localhost:8080/myApp/code"
  ],
  ...
}

The overall authorization flow is as follows:

Flow

  1. The user clicks the login link on a web app.

  2. The web app sends an authorization request to IdentityNow in the form:

    GET https://{tenant}.identitynow.com/oauth/authorize?client_id={client-id}&client_secret={client-secret}&response_type=code&redirect_uri={redirect-url}
    
  3. IdentityNow redirects the user to a login prompt to authenticate to IdentityNow.

  4. The user authenticates to IdentityNow.

  5. Once authentication is successful, IdentityNow issues an authorization code back to the web app.

  6. The web app submits an OAuth 2.0 Token Request to IdentityNow in the form:

    POST https://{tenant}.api.identitynow.com/oauth/token?grant_type=authorization_code&client_id={client-id}&client_secret={client-secret}&code={code}&redirect_uri={redirect-url}
    
  7. IdentityNow validates the token request and submits a response. If successful, the response will contain a JWT access token as indicated in the Token Response section.

The query parameters for in the OAuth 2.0 Token Request for the Authorization Code grant are as follows:

Key Description
grant_type Set to authorization_code for the authorization code grant type.
client_id This is the client ID describing for the API client.
e.g. b61429f5-203d-494c-94c3-04f54e17bc5c
This can be generated by following these instructions: Create OAuth Client
client_secret This is the client secret describing for the API client.
e.g. c924417c85b19eda40e171935503d8e9747ca60ddb9b48ba4c6bb5a7145fb6c5
This can be generated by following these instructions: Create OAuth Client
code This is a code returned by /oauth/authorize.
redirect_uri This is a URL to redirect to once the token has been granted.

Here is an example call OAuth 2.0 Token Request for the Authorization Code grant.

curl -X POST \
  'https://example.api.identitynow.com/oauth/token?grant_type=authorization_code&client_id=b61429f5-203d-494c-94c3-04f54e17bc5c&client_secret=c924417c85b19eda40e171935503d8e9747ca60ddb9b48ba4c6bb5a7145fb6c5&code=6688LQJB0y652z6ZjFmkCKuBUjv2sTIqKS2JthWrZ7qlPgI9TClJ6FnpweEhO6w7&redirect_uri=http://localhost:8080/oauth/redirect' \
  -H 'cache-control: no-cache'

Client Credential Grant Flow

Further Reading: https://oauth.net/2/grant-types/client-credentials/

This grant type is used by clients to obtain an access token outside the context of a user. This is probably the simplest authentication flow.

Special attention must be paid to what client credentials are used in this call, as this will affect the user context associated with the client credential, and ultimately the JWT token. Outside of a user context, only a subset of IdentityNow REST APIs may be accessible with an API authority. As an example, access request or administrative APIs may not work, as they require a user or administrative context to work.

If the client credential grant flow uses client credentials derived from a Personal Access Token, there will be a user context. - i.e., access request or administrative APIs should be available to the API caller.

If the client credential grant flow uses client credentials derived from the OAuth 2.0 Client, there will not be a user context, only an API context. - i.e., access request or administrative APIs may not be available to the API caller.

For more information, see: Best Practices: Using Personal Access Tokens in IdentityNow.

For any OAuth 2.0 client you are using, must have CLIENT_CREDENTIALS as one of its grantTypes:

{
  "enabled": true,
  "created": "2019-05-23T02:06:20.685Z",
  "name": "My Application",
  "description": "My Application",
  "id": "b61429f5-203d-494c-94c3-04f54e17bc5c",
  "secret": null,
  "grantTypes": [
    "CLIENT_CREDENTIALS"
    ...
  ],
  ...
}

Personal Access Tokens are implicly granted a CLIENT_CREDENTIAL grant type.

The overall authorization flow looks like this:

  1. The client submits an OAuth 2.0 Token Request to IdentityNow in the form:

  2. POST https://{tenant}.api.identitynow.com/oauth/token?grant_type=client_credentials&client_id={client-id}&client_secret={client-secret}
    
  3. IdentityNow validates the token request and submits a response. If successful, the response will contain a JWT access token as indicated in the Token Response section.

The query parameters for in the OAuth 2.0 Token Request for the Client Credential grant are as follows:

Key Description
grant_type Set to client_credentials for the authorization code grant type.
client_id This is the client ID describing for the API client.
e.g. b61429f5-203d-494c-94c3-04f54e17bc5c
This can be generated by following these instructions: Create OAuth Client or Create Personal Access Token.
client_secret This is the client secret describing for the API client.
e.g. c924417c85b19eda40e171935503d8e9747ca60ddb9b48ba4c6bb5a7145fb6c5
This can be generated by following these instructions: Create OAuth Client or Create Personal Access Token.

Here is an example call OAuth 2.0 Token Request for the Client Credential grant.

curl -X POST \
  'https://example.api.identitynow.com/oauth/token?grant_type=client_credentials&client_id=b61429f5-203d-494c-94c3-04f54e17bc5c&client_secret=c924417c85b19eda40e171935503d8e9747ca60ddb9b48ba4c6bb5a7145fb6c5' \
  -H 'cache-control: no-cache'

Refresh Token Grant Flow

Further Reading: https://oauth.net/2/grant-types/refresh-token/

This grant type is used by clients in order to exchange a refresh token for an access token when the existing access token has expired. This allows clients to continue to have a valid access token without further interaction with the user.

The OAuth 2.0 client you are using must have REFRESH_TOKEN as one of its grantTypes:

{
  "enabled": true,
  "created": "2019-05-23T02:06:20.685Z",
  "name": "My Application",
  "description": "My Application",
  "id": "b61429f5-203d-494c-94c3-04f54e17bc5c",
  "secret": null,
  "grantTypes": [
    "REFRESH_TOKEN"
    ...
  ],
  ...
}

The overall authorization flow looks like this:

  1. The client grants a token via one of the other OAuth grant flows.

  2. The client notices that the token is about to expire, based on the expires_in attribute.

  3. The client submits an OAuth 2.0 Token Request to IdentityNow in the form:

  4. POST https://{tenant}.api.identitynow.com/oauth/token?grant_type=refresh_token&client_id={client-id}&client_secret={client-secret}&refresh_token={refresh-token}
    
  5. IdentityNow validates the token request and submits a response. If successful, the response will contain a JWT access token as indicated in the Token Response section.

The query parameters for in the OAuth 2.0 Token Request for the Refresh Token grant are as follows:

Key Description
grant_type Set to refresh_token for the authorization code grant type.
client_id This is the client ID describing for the API client.
e.g. b61429f5-203d-494c-94c3-04f54e17bc5c
This can be generated by following these instructions: Create OAuth Client
client_secret This is the client secret describing for the API client.
e.g. c924417c85b19eda40e171935503d8e9747ca60ddb9b48ba4c6bb5a7145fb6c5
This can be generated by following these instructions: Create OAuth Client
refresh_token This is the refresh_token as given with the expiring JWT access token.

Here is an example call OAuth 2.0 Token Request for the Refresh Token grant.

curl -X POST \
  'https://example.api.identitynow.com/oauth/token?grant_type=refresh_token&client_id=b61429f5-203d-494c-94c3-04f54e17bc5c&client_secret=c924417c85b19eda40e171935503d8e9747ca60ddb9b48ba4c6bb5a7145fb6c5&refresh_token=ey...4M' \
  -H 'cache-control: no-cache'

OAuth 2.0 Token Response

Once the OAuth 2.0 token end-point is called with for the appropriate grant type, the response body might look like this:

{
    "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0ZW5hbnRfaWQiOiI1OGViMDZhNC1kY2Q3LTRlOTYtOGZhYy1jY2EyYWZjMDNlNjEiLCJpbnRlcm5hbCI6ZmFsc2UsInBvZCI6ImNvb2siLCJvcmciOiJuZWlsLXRlc3QiLCJpZGVudGl0eV9pZCI6ImZmODA4MTgxNTVmZThjMDgwMTU1ZmU4ZDkyNWIwMzE2IiwidXNlcl9uYW1lIjoic2xwdC5zZXJ2aWNlcyIsInN0cm9uZ19hdXRoIjp0cnVlLCJhdXRob3JpdGllcyI6WyJPUkdfQURNSU4iXSwiZW5hYmxlZCI6dHJ1ZSwiY2xpZW50X2lkIjoiZmNjMGRkYmItMTA1Yy00Y2Q3LWI5NWUtMDI3NmNiZTQ1YjkwIiwiYWNjZXNzVHlwZSI6Ik9GRkxJTkUiLCJzdHJvbmdfYXV0aF9zdXBwb3J0ZWQiOmZhbHNlLCJ1c2VyX2lkIjoiNTk1ODI2Iiwic2NvcGUiOlsicmVhZCIsIndyaXRlIl0sImV4cCI6MTU2NTg5MTA2MywianRpIjoiOTQ5OWIyOTktOTVmYS00N2ZiLTgxNWMtODVkNWY2YjQzZTg2In0.zJYfjIladuGHoLXr92EOJ3A9qGNkiG5UJ9eqrtSYXAQ",
    "token_type": "bearer",
    "refresh_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0ZW5hbnRfaWQiOiI1OGViMDZhNC1kY2Q3LTRlOTYtOGZhYy1jY2EyYWZjMDNlNjEiLCJpbnRlcm5hbCI6ZmFsc2UsInBvZCI6ImNvb2siLCJvcmciOiJuZWlsLXRlc3QiLCJpZGVudGl0eV9pZCI6ImZmODA4MTgxNTVmZThjMDgwMTU1ZmU4ZDkyNWIwMzE2IiwidXNlcl9uYW1lIjoic2xwdC5zZXJ2aWNlcyIsInN0cm9uZ19hdXRoIjp0cnVlLCJhdXRob3JpdGllcyI6WyJPUkdfQURNSU4iXSwiZW5hYmxlZCI6dHJ1ZSwiY2xpZW50X2lkIjoiZmNjMGRkYmItMTA1Yy00Y2Q3LWI5NWUtMDI3NmNiZTQ1YjkwIiwiWYNjZXNzVHlwZSI6Ik9GRkxJTkUiLCJzdHJvbmdfYXV0aF9zdXBwb3J0ZWQiOmZhbHNlLCJ1c2VyX2lkIjoiNTk1ODI2Iiwic2NvcGUiOlsicmVhZCIsIndyaXRlIl0sImF0aSI6Ijk0OTliMjk5LTk1ZmEtNDdmYi04MTVjLTg1ZDVmNmI0M2U4NiIsImV4cCI6MTU2NTk3NjcxMywianRpIjoiODliODk1ZDMtNTdlNC00ZDAwLWI5ZjctOTFlYWVjNDcxMGQ3In0.pfDcB0sGChdHk-oDNmiIxsKFLxq9CcPQV5-eXWgIcp4",
    "expires_in": 749,
    "scope": "read write",
    "accessType": "OFFLINE",
    "tenant_id": "58eb06a4-dcd7-4e96-8fac-cca2afc03e61",
    "internal": false,
    "pod": "cook",
    "strong_auth_supported": false,
    "org": "example",
    "user_id": "595826",
    "identity_id": "ff80818155fe8c080155fe8d925b0316",
    "strong_auth": true,
    "enabled": true,
    "jti": "9499b299-95fa-47fb-815c-85d5f6b43e86"
}

The access_token contains the JSON Web Token which is subsequently used in any further REST API calls through the IdentityNow API gateway. To use this access token simply include it in an authorization header as a bearer token. For example:

curl -X GET \
  'https://example.api.identitynow.com/beta/accounts' \
  -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0ZW5hbnRfaWQiOiI1OGViMDZhNC1kY2Q3LTRlOTYtOGZhYy1jY2EyYWZjMDNlNjEiLCJpbnRlcm5hbCI6ZmFsc2UsInBvZCI6ImNvb2siLCJvcmciOiJuZWlsLXRlc3QiLCJpZGVudGl0eV9pZCI6ImZmODA4MTgxNTVmZThjMDgwMTU1ZmU4ZDkyNWIwMzE2IiwidXNlcl9uYW1lIjoic2xwdC5zZXJ2aWNlcyIsInN0cm9uZ19hdXRoIjp0cnVlLCJhdXRob3JpdGllcyI6WyJPUkdfQURNSU4iXSwiZW5hYmxlZCI6dHJ1ZSwiY2xpZW50X2lkIjoiZmNjMGRkYmItMTA1Yy00Y2Q3LWI5NWUtMDI3NmNiZTQ1YjkwIiwiYWNjZXNzVHlwZSI6Ik9GRkxJTkUiLCJzdHJvbmdfYXV0aF9zdXBwb3J0ZWQiOmZhbHNlLCJ1c2VyX2lkIjoiNTk1ODI2Iiwic2NvcGUiOlsicmVhZCIsIndyaXRlIl0sImV4cCI6MTU2NTg5MTA2MywianRpIjoiOTQ5OWIyOTktOTVmYS00N2ZiLTgxNWMtODVkNWY2YjQzZTg2In0.zJYfjIladuGHoLXr92EOJ3A9qGNkiG5UJ9eqrtSYXAQ' \
  -H 'cache-control: no-cache'

The expires_in describes the lifetime in seconds of the access token. For example, the values “3600” denotes that the access token will expire in one hour from the time the response was generated.

The refresh_token contains a JSON Web Token for usage in a Refresh Token grant flow (see above).

The user_id and identity_id define the identity context of the person logged in with. This is not set for the client credential grant type.

Which OAuth 2.0 Grant Flow should I use?

Deciding which OAuth 2.0 grant flow you should use largely depends on your use cases.

Daily Work or Quick Actions

For daily work or short, quick administrative actions, you may not really need to worry about grant types, as the access token can easily be obtained in the user interface. In order to see this:

  1. Login to IdentityNow.
  2. Go to /ui/session in the IdentityNow URL.
  3. The JWT token is accessToken as visible in the user interface.
  4. Use this access token in whatever HTTP client you prefer (Postman, CURL, etc)

While this is very simple to use, this is only valid for a short period of time (a few minutes).

Postman

If you are using the popular HTTP client, Postman, you have a couple options on how you might setup your authorization. You can just leverage the Bearer token as mentioned in the previous section, or you can also configure Postman to use OAuth 2.0 directly.

For details on how to set this up, see the following article: Leveraging OAuth 2.0 in Postman

Web Applications

If you are making a web application, the best grant flow that you should use is the Authorization Code grant flow. This will allow users to be directed to IdentityNow to login, and then redirected back to the web application via a URL redirect. This also works well with SSO, strong authentication, or pass-through authentication mechanisms as well.

SailPoint does not recommend using a password grant flow for web applications as it would involve entering IdentityNow credentials in the web application. This flow also doesn’t allow you to work with SSO, strong authentication, or pass-through authentication.

Scripts or Programs

If you are writing any sort of scripts or programs that leverage the IdentityNow APIs, which OAuth 2.0 grant from you should use typically depends on what you are doing, and which user context you need in order to operate under.

Because scripts, code, or programs do not have an interactive web-interface it is difficult (but not impossible) to implement a working Authorization Code flow. Because of this most scripts or programs typically run as a Client Credential or Password grant flow. If your APIs can work under and API context without a user, then Client Credential is ideal. However, if your APIs need a user or admin context, then Password grant flow might be more apt for usage.

For more information, see: Best Practices: Using Personal Access Tokens in IdentityNow.

Troubleshooting

Having issues? Follow these steps.

  1. Verify the API End Point Calls

    1. Verify the structure of the API call:
      1. Verify that the API calls are going through the API gateway: https://tenant.api.identitynow.com
      2. Verify that end-points and are calling their version correctly, a:
        • Private APIs: https://tenant.api.identitynow.com/cc/api/endpoint
        • V2 APIs: https://tenant.api.identitynow.com/v2/endpoint
        • V3 APIs: https://tenant.api.identitynow.com/v3/endpoint
        • Beta APIs: https://tenant.api.identitynow.com/beta/endpoint
      3. Verify that the API calls have the correct and supplying the correct headers (e.g., content-type), query parameters, and body data.
    2. If the HTTP response is 401 Unauthorized , this is an indication that the there is no authorization header, or if the JWT token is expired. Verify that the API calls are supplying the token as a bearer authorization header: authorization: bearer {token} and verify that the access tokens have not expired.
    3. If the HTTP response is 403 Forbidden, this is an indication that the access token is valid, but the user you are running as doesn’t have access to this end-point. Check the access rights which are associated with the user.
      Note: This can also be due to calling an API which expects a user, but your authorization grant type might have a necessary user context. Calling most administrative APIs with a CLIENT_CREDENTIAL grant will often produce this result.
  2. Verify the OAuth 2.0 Client

    1. Verify that the OAuth 2.0 Client is not a Legacy OAuth client. Legacy OAuth clients will not work. This is very apparent by looking at the Client ID, as OAuth 2.0 Client IDs have dashes. Here is an example: Legacy Client ID: G6xLlBBOKIcOAQuK OAuth 2.0 Client ID: b61429f5-203d-494c-94c3-04f54e17bc5c

    2. Verify the OAuth 2.0 Client ID exists. This can be verified by calling:

      GET /beta/oauth-clients/{client-id}
      

      or

      GET /beta/oauth-clients/
      
    3. Verify the OAuth 2.0 Client grantTypes match the OAuth 2.0 grant type flow you are using. For instance, this would work with Authorization Code and Password flows, but not Refresh Token flows:

      {
        "enabled": true,
        "created": "2019-05-23T02:06:20.685Z",
        "name": "My Application",
        "description": "My Application",
        "id": "b61429f5-203d-494c-94c3-04f54e17bc5c",
        "secret": null,
        "grantTypes": [
          "AUTHORIZATION_CODE",
          "PASSWORD",
          ...
        ],
        ...
      }
      
    4. If using an Authorization Code flow, verify the redirect URLs match the redirectUris values.

    5. You can’t get the Client Secret once it is generated. Generate a new client for testing if necessary.

  3. Verify the OAuth 2.0 Calls

    1. Verify that the OAuth call flow is going to the right URLs, with the correct query parameters, and data values.