Create Oauth Clients with scopes via API REST

UPDATE 7/12/2023: IdentityNow now has support for API scopes. Please read this guide for more information. Authorization | SailPoint Developer Community

API tokens are limited in what they can do based on the user level of the user that the token was created for. For example, if an IdentityNow admin user generated their own personal access token, that token would be tied to their user and would have the ability to call any API. However, if a token was generated for a user with the CERT_ADMIN user level, then that API token can only perform API operations needed to fulfill that user level’s function. You can find a list of IdentityNow user levels and their permissions here.

To answer your question, the only way you can limit the access of a token at this time is by assigning users the appropriate user levels in IdentityNow using this chart as a guideline. Personal access tokens and OAuth tokens with grant type “Authorization Code” are generated for users, so their level of access is dictated by the user level’s access, as shown in this chart. OAuth tokens generated with the grant type “Client Credentials” have no associated user, and are very restricted in the APIs they can call.

So how will scopes play into this when they are released? The JWT token for the IdentityNow API has an authorities and a scope property. If you decode the access_token using a tool like jwt.io, you’ll see the following:

This particular token has the authority ORG_ADMIN and scope sp:scopes:all (the FA== is a bitmap representation of the full scope name to save space). What this means in practice is that this token has access to all APIs as defined by this chart. The scope property of the JWT token will be used to further limit a token’s access based on the access they are granted from their authority. So having a token with authority ORG_ADMIN and scope sp:scopes:all means this token has full ORG_ADMIN rights. When scopes are released, you will have the ability to limit the rights a token with authority ORG_ADMIN has by specifying them in the scopes property when creating the client.

It’s important to note that scopes is an intersection of the rights granted by the token’s authority. So a token with authority CERT_ADMIN and scope sp:scopes:all will be granted all the rights for a CERT_ADMIN user level and nothing more. Scopes will not be able to give additional access outside of what is defined for the authority, as defined by this chart. Scopes will only be able to further limit the rights of an authority.