just want to understand more on /api/v1/users/me/groups okta endpoint.
here me is the current authenticated user I believe and has the access token and the app has okta.groups.read scope grant given. but when the above mentioned api is called I get 403 error response with empty body.
should any other grant be given in the authorization server?
The overall effort is to get the list of all the groups that the user belongs to. Any help would be appreciated.
There isn’t an endpoint that will report out the groups for a user using only end user authentication (e.g. an access token issued to that end user). Users can only read their own session information at /api/v1/sessions/me, their own profile information at /api/v1/users/me or /idp/myaccount/profile, or access other MyAccount endpoints
What about using a groups claim to receive the group information OR having your application make a request to the /users/{userId}/groups endpoint (server-side) to get the full list of groups for the user (either using an API token OR an OAuth token issued to a service app that has appropriate admin roles)?
I’m trying to better understand the behavior of the /api/v1/users/me/groups endpoint.
In my testing, I’m consistently getting 403 when calling it with an OAuth access token (from the default /oauth2/default authorization server), even though the user is authenticated.
Could you clarify:
In what scenarios does /api/v1/users/me/groups actually work?
Does it require:
A token issued by the Org Authorization Server (issuer = https://{org}.okta.com)?
Specific scopes like okta.groups.read?
Or is this endpoint primarily intended for session-based (cookie) requests rather than OAuth access tokens?
I’m specifically trying to understand whether this endpoint is usable in a pure OIDC/OAuth flow with user access tokens, or if it’s expected to return 403 in such setups.
Also on using groups claim, there might be a scenario of a user being in large number of groups and I read somewhere okta might limit the number of groups if they are too many, so we are trying different approaches to get all the groups of the user, users/{userid}/groups is also one approach that we will be trying.
/api/v1/users/me/groups is not a documented API endpoint. We only have a version of that endpoint that takes a User ID, api/v1/users/{userId}/groups, that can be called by an administrator. Far as I can tell, there is no version of this endpoint that can be called with only the authorization of an end user.
The only documented /users/me endpoint is /api/v1/users/me, which can be authorized with either a user’s Okta session in the browser, OR an Access Token issued to the end-user that was granted the okta.users.read.self scope and `/api/v1/sessions/me. This endpoint will only return user profile and system information, not group memberships.
So yes, it is expected to receive a 403 response if you try to authorize a call to that endpoint withb a user access token. If you need to get the list of all groups assigned to a user and are worried about the token becoming bloated if you use group claims, then I definitely think having your application’s backend make the API calls to the /api/v1/users/{userId}/groups endpoint with an appropriately permissioned (based on Admin Roles) and scoped token