Hello Dev Forum,
I am looking to use Access Token (JWT) as Bearer Token to call /users/me OKTA endpoint. I have enabled the scope (‘okta.users.read.self’) in the PKCE app. However, the Access Token is still not minted with scope ‘okta.users.read.self’.
Issuer → https://{my_company}.oktapreview.com/oauth2/default
When I use the token to make /users/me , I am getting 400 Error. Can someone please assist on this?
When requesting tokens with okta.* scopes (with the exception of okta.myAccount.* scopes), you must make the request to the Org Authorization Server (issuer == https://oktaDomain, NOT https://oktaDomain/oauth2/default)
If you switch your application to use the org authorizatino server instead, are you able to get a token back with that scope?
Hello Andrea,
Thank you for your response!
When I switch the authorization server to org authorization server I am getting the response as expected.
However, the design of our infrastructure is such that only the oauth2/default server is used across. Hence, I may not be able to change that with org authorization server only for this requirement.
To highlight the requirement, let me restate the question and what exactly are we looking for -
We have an implementation where these three endpoints of OKTA are being invoked from the front end application.
GET /api/v1/sessions/me
DELETE /api/v1/sessions/me (to revoke and delete OKTA session)
GET /api/v1/users/me
It makes use of OKTA SID cookie set on .okta.com domain to invoke these calls.
Now, we have seen that browsers are blocking third party cookies and hence these network calls are failing. Hence, we are looking at alternatives to invoke above three end points without changing much of the infrastructure.
We already researched and explored the option of vanity domain however due to some limitation on existing infrastructure we cannot proceed with the vanity domain solution.
Can you please suggest alternative methods to invoke above API calls of okta without depending on the third party cookie sid?
The endpoints mentioned only support being authorized by the session cookie set on the okta domain.
If you are seeing issues with browsers blocking access to third party cookies when your application is trying to make such calls from the front end, one option would be to set up a custom domain for your Okta org and ensure that your application is also hosted on the same domain. That way the cookies would be first party and would be accessible from your application.
Is it possible that the use of /users/me could be replaced by a call to userinfo and/or reading attributes from the user’s ID token? That way you don’t even need to make a call dependent on the Okta session
Similarly, can your application not rely on the /oauth2/*v1/logout endpoint to end the user’s Okta session?
Hello Andrea,
We can think of using other endpoint and get the details for the user; however do you recommend using any other implementation to identify if the OKTA session exists?
PS: Our front end code makes use of okta-auth-js library.
Regarding logout,
The intend to use the OKTA DELETE sessions/me endpoint is to clear the SID cookie to completely log off the user from any login on that browser.
With oauth2/v1/logout endpoint can we clear the OKTA session?
We need to do this step since our login/logout interface is supporting OIDC and SAML apps. Additionally, there is federation setup with different IdPs.
The only endpoint that we support for checking the presence of an active Okta session is the /api/v1/sessions/me endpoint, which requires an Okta session cookie as authentication.
Yes, a redirect to /oauth2/v1/logout will clear the Okta session cookie, so that should be a good option for sign out from your OIDC applications
