User List API doesn't seem to like my Bearer token

Hello Okta community!

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>
Connection: close

Unfortunately the request, which seems aligned with the documentation and this blog post Selecting the Best Authorization for Your API Integrations | Okta Developer yields a 400 BAD REQUEST with this response:

HTTP/1.1 400 Bad Request
Date: Tue, 09 May 2023 21:02:23 GMT
Content-Length: 0
Connection: close
Server: nginx
x-xss-protection: 0
p3p: CP="HONK"
access-control-expose-headers: WWW-Authenticate
www-authenticate: Bearer authorization_uri="", realm="", scope="", error="invalid_request", error_description="The authorization server id is invalid.", resource="/api/v1/users"
content-language: en
Strict-Transport-Security: max-age=315360000; includeSubDomains
set-cookie: sid=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/
set-cookie: autolaunch_triggered=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/

One would think that authorization issues wouldn’t occur past getting a bearer token - any ideas?


Hey there @LLXP!

Can you help me understand your setup? Did you create a developer account with Okta? (like through If so, you’ll have a custom authorization server requiring the JWKS. Or did you create your Okta org through different means?

Does this response from @andrea help?

If that isn’t your setup (or if you run into trouble identifying the authorization server to use or creating the JWKS), please let us know!

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:

  1. I’ve registered for a trial instance at, this has granted me a trial site at
  2. I accessed the Directory to add users, so that we have something to list!
  3. 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
  4. I visited the API Scopes tab and granted,
  5. I then visited Security > API and accessed the default API, whose issuer URI looks like - I noted this URI
  6. 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:

The API documentation is a bit nebulous at parts, but I managed to cobble a call that returns a Bearer token:

POST /oauth2/default/v1/token HTTP/1.1
Accept: application/json
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <base64_encode( client_id : client_secret )>
Connection: close
Content-Length: 40


This returns a bearer token, which I am then trying to consume at api/v1/users yet am met with the request errors noted above.


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.

Thank You,

One more option in addition to Erik’s.

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.

Dev docs

Product announcement with use case

Let us know how it goes!

1 Like

@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!

Thank you.

Hey @LLXP,

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.

Sure, thanks for checking @LLXP !

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.


@alisaduncan Thank you for your guidance, I will continue in the blog’s thread - already got the party started at Selecting the Best Authorization for Your API Integrations - #2 by LLXP. :+1:t3:

Cheers & Thanks.