How to lock down an API token to only access what our application needs

We interact with okta in many ways. Our customers would like to make sure that the account that creates the API token is locked down to only have the entitlements the API token needs.

Based on this in the documentation: “API token are generated with the permissions of the user that created the token. If a user’s permissions changes, then so does that of the token.” - we just don’t know how to create a group that would allow an admin to create the API token and only have access to what the application needs.

I have a list of all the operations we call, and can provide that if it’s helpful.

@eric.prickett yes, API token are generated with the permissions of the user and they are used to authenticate requests to Okta APIs.
For more info, you can refer the doc below:
What is your end goal? Any example of the operations you will call?

Hi Lijia, thanks for your reply. We would like to know specifically which permissions/entitlements a service account should have in order to create an API token that has access to precisely the okta operations our software will call.

Example: If the user that creates the token has access to every single okta operation available, then our app will have access to all those operations. Our clients would like to ensure the API token only has access to the okta operations our app calls.

I’ve got a list of every single operation we call, but don’t know how to attach it here.

@Lijia I was just curious what your advice is on this, thanks for your help.

@eric.prickett Here is our API token definition.
An API token is issued for a specific user and all requests with the token act on behalf of the user.
If you want to limit users accessing to your app, you can assign limited users to this app.

Hi @Lijia (or anyone else that can help). I don’t think you quite understand what I’m looking for so I’ll try and be more explicit.

The following is the list of ALL operations we hit on Okta’s platform, and I need to map out precisely what entitlements the user creating the API token would need to make every single one of them work, but not be a super / org admin.

Ultimately we are only interacting with /api/v1/users, /groups, and /authn. I can infer that the user creating the API token needs to be at least group admin (for access to all user & group functions) - but what about auth? I don’t see anything listed here about that: Administrator roles and permissions | Okta

- create user POST: /api/v1/users/{userId}?activate=false
- activate user POST: /api/v1/users/{userId}/lifecycle/activate?sendEmail=false
- get user GET: /api/v1/users/{userId}
- suspend user POST: /api/v1/users/{userId}/lifecycle/suspend
- unsuspend user POST: /api/v1/users/{userId}/lifecycle/unsuspend
- unlock user POST: /api/v1/users/{userId}/lifecycle/unlock
- verify answer POST: /api/v1/users/{userId}/factors/{factorId}/verify
- change user name POST: /api/v1/users/{userId} (similar to the create user, but with a different body and without the ?activate=false)
- set password PUT: /api/v1/users/{userId}
- reset password PUT: /api/v1/users/{userId}/lifecycle/reset_password?sendEmail=false
- expire password POST: /api/v1/users/{userId}/lifecycle/expire_password?tempPassword=true
- get security Qs GET: /api/v1/users/{userId}/factors/questions
- get factors GET: /api/v1/users/{userId}/factors
- get factors to enroll GET: /api/v1/users/{userId}/factors/catalog
- enroll security question POST: /api/v1/users/{userId}/factors
- set security question PUT: /api/v1/users/{userId}/factors/{factorId}
- set recovery question POST: /api/v1/users/{userId} (similar to create user but with different body)
- reset factors POST: /api/v1/users/{userId}/lifecycle/reset_factors
- reset factor DELETE: /api/v1/users/{userId}/factors/{factorId}
- update profile POST: /api/v1/users/{userId} (similar to create user but with different body)
- change password POST: /api/v1/users/credentials/change_password
- get user by loginId GET: /api/v1/users/{loginId}

- add user to group PUT: /api/v1/groups/{groupId}/users/{userId}

- create internal recovery token POST: /api/v1/authn/recovery/password
- check password POST: /api/v1/authn
- resend recovery code POST: /api/v1/authn/recovery/factors/{factorType}/resend
- get current status POST: /api/v1/authn/ (passes state token)
- check password POST: /api/v1/authn/ (AuthnRq object)
- check answer POST: /api/v1/authn/factors/{factorId}/verify (passes answer)
- send pass code POST: /api/v1/authn/factors/{factorId}/verify
- resend pass code POST: /api/v1/authn/factors/{factorId}/verify/resend
- check pass code POST: /api/v1/authn/factors/{factorId}/verify (passes pass code)
- change pass code POST: /api/v1/authn/credentials/change_password
- reset password POST: /api/v1/authn/credentials/reset_password
- enroll security Q POST: /api/v1/authn/factors
- enroll Oob POST: /api/v1/authn/factors?updatePhone=true
- resend activation code: POST: /api/v1/authn/factors/{factorId}/lifecycle/resend
- enroll Otp POST: /api/v1/authn/factors
- activate Otp POST: /api/v1/authn/factors/{factorId}/lifecycle/activate
- create recovery token POST: /api/v1/authn/recovery/password
- check recovery token POST: /api/v1/authn/recovery/token
- send recovery token POST: /api/v1/authn/recovery/password
- resend recovery code POST: /api/v1/authn/recovery/factors/{factorType}/resend
- check recovery code POST: /api/v1/authn/recovery/factors/{factorType}/verify
- check recovery answer POST: /api/v1/authn/recovery/answer
- skip POST: /api/v1/authn/skip
- previous POST: /api/v1/authn/previous
- cancel POST: /api/v1/authn/cancel

@Lijia can you please let me know what entitlement an API token creator has to have in order to interact with the /api/v1/authn API? That would help tremendously.

@eric.prickett To better understand and help you, please open a support ticket through an email to One of our engineers will setup a meeting discuss your issue.

1 Like