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.
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.
@eric.prickett Here is our API token definition. https://help.okta.com/en/prod/Content/Topics/Security/API.htm
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
/api/v1/users/
- 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}
/api/v1/groups/
- add user to group PUT: /api/v1/groups/{groupId}/users/{userId}
@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 support@okta.com. One of our engineers will setup a meeting discuss your issue.
@eric.prickett Did you have any answer?
I think i am looking for the same thing as you…
Depending on who call the API, i want the right to be adjusted… But i can’t figure out how to do that.
after that i am using “UserApi” to use the function : ListUsers.
When i am doing bearertoken in authorization mode, i get nothing.
And when i do privatekey it seams that it dont take in account my accestoken but i am getting my users.
I believe this is an either/or. The client can be configured to use AuthorizationMode.PrivateKey (in which case, the SDK will fetch the access token for you) OR AuthorizationMode.BearerToken (where you provide the raw Access Token JWT yourself).
If when you use BearerToken mode, nothing is returned, you likely want to check if that token was issued with the appropriate scopes AND ensure that it was issued to a Service app with appropriate permissions OR an admin user with appropriate permissions to read users.
when i an doing authorization mode with “private key” it’s working but i contact the service without passing the credential of my user and so the right that he have (ou don’t have)
I am also trying with bearer token that i generated myselft. The Service App has the right bebause with private key mode i get some result with the function “ListUsers”.
But i think i am missing somehting whe i create the TOKEN jtw with private key
In general though, all you should need to do is setup the ApplicationApi and then call the desired function
If you do want to manually generate the JWT yourself, make sure you’re following the instructions here about the payload for the JWT you need to create.
But nothing is telling me how to act as the user who connect to my app.
I can pass command ( and i did it work fine) as my API app that I created in okta.
But for exemple :
I have a user who connect who is in a group who have right on “SubGroup”.
When he request the API throuth the app avec log in, i want him to see only the user in “SubGroup” cause that’s the only right that he have with the fonction “ListUsers” of UserApi.
Whereas if for exemple a admin connect trought the app when i do “ListUsers” of UserApi, i will get all the users…
Ah, in that case, you wouldn’t want the token you use to authorize the request to have higher permissions.
You could look into requesting an access token for that specific user to authorize the request (the SDK is not designed to handle this use case though). Only issue with that is that this user would need to still be an admin to be able to request the other users in that group (say, a Group admin), as regular end users would not normally have permission to make requests to Users (outside of requesting information about their own user).
You might want to check if this would be a fit for your use case by manually fetching a token for the user in question (using auth code flow, for example) and then manually sending it as the Bearer auth to the /Groups endpoint.