Problem with Fetching List of Users via API

I was wondering if I can get some guidance in terms of fetching a list of users from Okta’s API within my React application. I am currently using the @okta/okta-auth-js library in order to let the customer end user access their Okta account to then get an access token to be used to call the list of users API from Okta. However, I feel like I am missing a step here. I appreciate the help in advance.

Hi @Rog!

Getting the access token is a big part of it, but you have a couple of other things to take care of before it can be used:

  1. In your app configuration go to the Okta API Scopes page and grant the “okta.users.read” scope so the application can make the request.
  2. The authenticated user needs the “view users” administration privilege. Regular users cannot see the other identities in the organization. That’s for security. See Administrator roles and permissions | Okta.
  3. Request the okta.users.read scope when you are getting the access token.

Good luck,
Joel

1 Like

Hi, @jmussman!

Thank you for the response! I made sure “okta.users.read” scope is granted within my app configuration and included “okta.users.read” as one of the requested scopes. However, I am getting the following error when trying to get the access token by using oktaAuth.token.getWithPopup({ scopes }) from the @okta/okta-auth-js library:

“OAuthError: One or more scopes are not configured for the authorization server resource.”

Am I missing a step in terms of making sure the okta.users.read scope is included? Thanks!

OK, the documentation for okta-auth-js uses as an example path /oauth2/default for the issuer in the config object. If you are using that, it won’t work because only the org authorization server can issue a token for the org API. The default authorization server and any other custom authorization server can only issue tokens for your APIs. Can you check that please? The org issuer is your okta domain without any path.

BTW, you can check the details for the org authorization server at https://[your Okta domain]/.well-known/openid-configuration, and the default custom server at https://[your Okta domain]/oauth2/default/.well-known/openid-configuration. The default is the same as any custom server except it has the name “default” instead of a UID.

1 Like

Thank you so much @jmussman for taking the time to go through the documentation in order to answer my question. I am now able to fetch a list of users! I was wondering if my application will be able to be used by other users who are outside of my company, like different customers. If so, am I supposed to use their Okta domain for fetching data or still use my Okta domain?

If I understand correctly you want to integrate the application with another organization. That is easily done, it’s a matter of the URL and client ID in the config for the SDK. The SDK can only talk to one Okta organization at a time because it uses shared variables in the browser memory. Identity information is not shared by organizations (unless you connect to organizations), so you can only read user information from the organization the application is integrated with.

This Github project does not use the SDK, everything is done in raw code. The README.md file may help you understand OAuth and OIDC better: GitHub - jmussman/pirates.

1 Like

Gotcha, so the application I am working on is used for other customers that are in their own organization. Are you saying there is no way for another organization to use my application and fetch a list of users from their organization using the API scopes?

I think I’m missing what you’re driving at. Is your application a traditional web application or a SPA? You are trying to avoid re-deploying another copy of it?

1 Like

Sorry about that. My application is a React application and I am not trying to deploy another copy of it. I just want another end user to sign into their Okta account and get a list of users from their company even if their company is a different company from my company.

Hmm. It really isn’t intended to work that way, where a user logs into their own organization. Applications are bound to an organization, the application needs the URL and the client ID for the organization it is going to authenticate users with.

I suppose that you could provide URL and client ID data behind the scenes and allow the user to sign on to the organization of their choice. Maybe pick from a list, or have a value in the application URL, or change the application URL for the different organizations to tell the application what to connect to.

1 Like

That’s interesting. I am trying to have user provisioning within our application so our customers have a much easier time to onboard their employees by getting a list of users from Okta’s API similar to what Google has with their Workspace platform. Is that possible with this way you provided?