I’m partway through testing a list integration with Okta. I can currently retrieve a Bearer token reliably from the /oauth2/default/v1/token endpoint, and am trying to use it to invoke the User List API using this token.
The request, fashioned after on the docs, looks like so:
GET /api/v1/users?limit=200&after=0 HTTP/1.1
Accept: application/json
Content-Type: application/json; okta-response="omitCredentials,omitCredentialsLinks, omitTransitioningToStatus"
Authorization: Bearer <TOKEN>
Host: trial-0000000.okta.com
Connection: close
Can you help me understand your setup? Did you create a developer account with Okta? (like through developer.okta.com)? If so, you’ll have a custom authorization server requiring the JWKS. Or did you create your Okta org through different means?
Pleasure to explain what I’ve done so far - appreciate your willingness to help! We have clients that use Okta, and they’ve asked if we could build a system to synchronize their Okta directory with their tenant instance of our application. So far:
I accessed the Directory to add users, so that we have something to list!
I went to Applications > Applications, and clicked on “Create App Integration” and selected the “API Services” method. I noted the Client Secret and Client ID
I visited the API Scopes tab and granted okta.users.read, okta.groups.read
Clicking into the default API, I accessed the Scopes tab and clicked on Add Scope (naming it LLXP). I was led here by a need to push a scope into the API call
Then I fired up RapidAPI and tested an auth call that cobbles the details I collected in admin:
If you want to use OAuth for Okta Management API endpoints you need to use the Org Authorization Server , default is a custom authorization server.
For the client credentials flow you are also required to use a JWT, not client_secret.
The below documentation details the required setup.
If you have multiple clients desiring this, and you want to consider making this a public integration option your clients can use, consider creating an integration on the Okta Integration Network. It will make it easier for your clients to self-service.
But it also allows you a different way to create the API service application where you can use client credentials like you have right now without creating the signed JWT. You can read more about it in the Use API Integrations subheading on this post (I know I sent this to you before, but specifically calling out that subsection)
It’s fairly new, so there are not a lot of docs/tutorials on doing it, but I’ll link in what I have so you can evaluate if this is the right option for your needs.
@alisaduncan Thank you - the OIN seems to make the most sense, so I’ve gone ahead and have registered an account. I now have a dev-xxx account; but it feels like a bit of the same hamster wheel.
I’ve gone to Applications > Applications, have created an app, have granted it user read scope, and this nets me a client ID and a client secret. I’ve base64 encoded these, and am unclear on what endpoint I should use to generate the bearer token. You’ve made clear that I can use client id + secret, thank you - @erik mentions that a different auth endpoint should be used.
Would you be open to pinpointing where I can locate (or where is documented) the proper endpoint on which to call /token to get a bearer token for the app? The last endpoint I self-discovered yielded a bearer token that didn’t work it seems!
I completely understand the confusion. We’re actively working on the documentation to clarify.
Glad to hear you want to create an app for the OIN! That’s awesome! You can create a test API service by initiating the OIN submission process. There, you can add a new API service submission which allows you to create a test API service for the OIN process. You can use this test process to code, verify your work, and so forth, before you finalize submission to the OIN. This test API service uses client credentials.
I know it’s a bit back and forth and not streamlined - so it’s confusing at the moment. We’re working on it. The upside is your app gets to be one of the first in this marketplace! Woohoo!
Let us know how it goes! I’m also definitely interested in your feedback on this process. Feel free to respond back here or start a convo on that “Selecting the best authorization”… blog post since comments on blog posts get directly routed to my team. Happy coding!
Thanks @alisaduncan - what would you do if you were me - is commenting on the blog the best way? Is there an alternate route with paid support that we can opt for? Our time cost in plying an undocumented feature is a concern.
Going forward (beyond today), commenting on the post is the best way, as I don’t check this dev forum regularly. By commenting on the post, I’ll see a notification about the comment and can respond.
As for documentation, there is documentation on the process and it’s an announced generally available feature
IMO, I think we can add clarity to the docs to help bridge confusion stemming from custom authorization server scenarios, which is what you encountered in your testing.
Does that help alleviate concerns? LMK if not and I can see how to assist.