Hi,
I would like to know if there is any way to create a Oauth Clients via API REST with scopes. I noted than when Oauth Clients is created, scopes by default is “sp:scopes:all”. In our case, we want to restrict the scope to only search events read-only and no other API endpoints. What would be the correct way to create a new Oauth Clients without scopes:all
We are creating the Oauth Client as described here
IdentityNow REST API - Create OAuth Client - Compass (sailpoint.com)
Currently, only the default of sp:scopes:all is supported. We have started defining some scopes for our APIs as a prerequisite for the token scope feature, but we still have work to do in defining additional scopes and implementing the configuration mechanism. This will likely not be available within the next 6 months, but is something we are working on.
Hi @colin_mckibben ,
Thanks for your early response. According to that, the other API endpoints could be called, eg. to create new identities, modify users’ credentials etc. Is there anything we can do to mitigate the risk?
Thanks in advance,
Ismael
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.
Hi, are there any updates on how to use the scope to limit the user access through the REST API?
I have a request regarding a token that will be used for modifying Roles through the REST API and giving it a token that contains an Admin user permission level, its only be viable if it is scoped.
thanks in advance
Hi Aharon,
Scopes are still being developed and are not yet implemented.
@colin_mckibben Q4 2022, we are about to release the UI for the Personal Access Tokens and API client with the new feature to select scopes and associate them with PAT/API client for least privilege access
This was extremely helpful in my understanding of APIs and access control! I was having a hard time understanding Authorizations Code vs Client Credentials vs PATs, but this was the last piece of the puzzle I needed to bring it all together! Thanks Colin!
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
