Using sessionToken how can get access_token and id_token

Hi i’m new to okta and i’m trying to integrate it with my webportal to okta using the custom login.

I have login page will get username and password to send to okta using primary authentication api( {{url}}/api/v1/authn). the api got response user details with sessionToken.

so using this sessionToken how can get other access_token and id_token?
can you provide the api list ?

You want to use the OAuth 2.0 authorize route, specifying the sessionToken parameter:
https://developer.okta.com/docs/api/resources/oidc#authorize

Let me know if you have any questions about this!

Hi Tom

Thank you for your replay.

  1. making api call for {{url}}/api/v1/authn – post method with user details
    res: got sessionToken
  2. Api call – https://dev-255595.oktapreview.com/oauth2/v1/authorize?client_id=0oadeindnmS6oN5rN0h7&response_type=id_token token&scope=openid&prompt=none&response_mode=form_post&
    redirect_uri=https%3A%2F%2Fpulse.conviva.com&state=Af0ifjslDkj&nonce=n-0S6_WzA2Mj&sessionToken=20111sGo7p0ZI_pB-lfhCKlb3zCkDF9EV_dHGdlSE85xGow_3Qr7utM

is it will return the callback url to response or how to handle it

Take a look at this thread to know how to get the access_token from session token.
It also has sample code in javascript & .net -

i am using the OKTA widget for authentication.
When signin callback url will get code and state and internally setting the cookies value and python callback url is getting the cookies value, working fine my linux ubuntiu machine.

When i will same code will executing to mac machine not working, the cookies values setting the callback URL okta response but not able to get in same value in python code.
what is the issue?
any browser setting need to change?

@bala Can you post the code that is doing the login and setting the cookie? I’m not sure why Python would see a cookie on Linux but not on Mac.

Safari has some restrictions on third-party cookies, but it sounds to me like you are setting a first-party cookie. If you post your code we can take a look.

Hi nate.barbettini,

Thank you for your quick response.

i have used this github code,

https://github.com/jmelberg-okta/okta-oidc-django-samples.

OktaAuth.min.js and okta-sign-in.min.js these file only setting the cookies in client browser.

  1. When my application is deployed in linux machine then client application on linux or MAC working fine.
  2. The issue is observer while application deployed in MAC platform.

Hmm, that is not an issue I’ve seen before. Do you mean that the server is running on a Mac, or you are accessing the application on a Mac? If the latter, which browser are you using?

In order to debug this, can you provide a set of steps that always reproduce the issue?

Hi nate.barbettini,

Before going to solve this issue one more question i have.

Regarding the logout api

  1. https://dev-255595.oktapreview.com/api/v1/authn to get the session_id

  2. https://dev-255595.oktapreview.com/oauth2/v1/authorize?client_id=0oadeindnmS6oN5rN0h7&redirect_uri=http%3A%2F%2F127.0.0.1%3A8000%2Fauthorization-code%2Fcallback&response_type=code&response_mode=query&state=FkSgPf7a6gRQcXt9IBFy0fy5foXIFUS6pYPB6aQhvHpSACdFxh1QJzgBTGHvhzv7&nonce=yG4cCBUwuRBob89woR8YuXeZdXelgk2jlMkZDthZyEdU27tfGHBsuZxrL98ybRW5&display=page&sessionToken=20111f6upKTDrSIBDI17c_C-f-s0Ck28SDBYG6eKEc8fn4nZihxkysH&scope=openid%20profile%20email

query parameter: client_id=0oadeindnmS6oN5rN0h7&redirect_uri=http%3A%2F%2F127.0.0.1%3A8000%2Fauthorization-code%2Fcallback&response_type=code&response_mode=query&state=FkSgPf7a6gRQcXt9IBFy0fy5foXIFUS6pYPB6aQhvHpSACdFxh1QJzgBTGHvhzv7&nonce=yG4cCBUwuRBob89woR8YuXeZdXelgk2jlMkZDthZyEdU27tfGHBsuZxrL98ybRW5&display=page&sessionToken=20111f6upKTDrSIBDI17c_C-f-s0Ck28SDBYG6eKEc8fn4nZihxkysH&scope=openid%20profile%20email

  1. http://127.0.0.1:8000/authorization-code/callback?code=th40dAqyHSzO8moJxgu1&state=FkSgPf7a6gRQcXt9IBFy0fy5foXIFUS6pYPB6aQhvHpSACdFxh1QJzgBTGHvhzv7

  2. Using the code generated the access_token and id_token

{‘access_token’: u’eyJraWQiOiJFdHZUWU0tajZRREp3OW5qUTFPMFpGV1hWNGtUbHlVSV9fdm5mSTNpOUU4IiwiYWxnIjoiUlMyNTYifQ.eyJ2ZXIiOjEsImp0aSI6IkFULk9tcUM2UXNOVW1lTHlHSWJkSE5WZXNCeWZYLXkzTjlaemh6U21UejlicHMiLCJpc3MiOiJodHRwczovL2Rldi0yNTU1OTUub2t0YXByZXZpZXcuY29tIiwiYXVkIjoiaHR0cHM6Ly9kZXYtMjU1NTk1Lm9rdGFwcmV2aWV3LmNvbSIsInN1YiI6ImJwYXR0dXNhbXlAY29udml2YS5jb20iLCJpYXQiOjE1MjIzMDMwMzksImV4cCI6MTUyMjMwNjYzOSwiY2lkIjoiMG9hZGVpbmRubVM2b041ck4waDciLCJ1aWQiOiIwMHVkY2VxMHh3MEFvb2pINjBoNyIsInNjcCI6WyJvcGVuaWQiLCJlbWFpbCIsInByb2ZpbGUiXX0.GQRsegWIXx5ieOneqQrP52lSlqX4LyDs17zC9bViCpuI8Y1Y-dJ5-5sILavEy-G9mVuQoKyOrQjulOg9x6VbpCeuzquvSKACaCllHZ9wmezBeDWb8WdDVwbboN-BzBVjr3potoUCTg-AK_-Jw66LuqsLbsxpvxC9urjfkPATDBHkK5wc0-8kid9GUZo5J9zU9jzy7PXasq2q0JJEbYif08W9_ofncTMm40BcR-rhWufMmv6CNx2jE_f-XFgTwdVDE-HWjuj5OPfmmhV2jP6jWWoEnFuFxpjx5Lkuk2QBui-6PNUXk4XjOezj1gRI7tgmFLogE-wKLvzPuiq8amuLgg’, ‘id_token’: u’eyJraWQiOiJFRHA0TzBNa2xJM2xKc2ZWd01ILXRkczhPZnFyclJJeDBTNnk0cHBib1U4IiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiIwMHVkY2VxMHh3MEFvb2pINjBoNyIsIm5hbWUiOiJCQUxBIiwiZW1haWwiOiJicGF0dHVzYW15QGNvbnZpdmEuY29tIiwidmVyIjoxLCJpc3MiOiJodHRwczovL2Rldi0yNTU1OTUub2t0YXByZXZpZXcuY29tIiwiYXVkIjoiMG9hZGVpbmRubVM2b041ck4waDciLCJpYXQiOjE1MjIzMDMwMzksImV4cCI6MTUyMjMwNjYzOSwianRpIjoiSUQuMElIeDRldXlHVXFjX1VHUjJhZVV3M2FvaDNYMkFpTW93eUhRcmJLYWxQYyIsImFtciI6WyJwd2QiXSwiaWRwIjoiMDBvZGNlcTB2ZDl1eGJVUjMwaDciLCJub25jZSI6InlHNGNDQlV3dVJCb2I4OXdvUjhZdVhlWmRYZWxnazJqbE1rWkR0aFp5RWRVMjd0ZkdIQnN1WnhyTDk4eWJSVzUiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJicGF0dHVzYW15QGNvbnZpdmEuY29tIiwiYXV0aF90aW1lIjoxNTIyMzAzMDM2LCJhdF9oYXNoIjoiM3FoRWdHVFdZTzgwcGU4R2ZXVGxGdyJ9.Xrhjf5GhPfrg_NpZUXLs0L-mQFCmmwbAsju2guHOvItwcRayOBSKvc4Y0sq_UyxdVziTfo-d_AfbBU1yxAYFWenyChU3OseXQQziHuyYX08NCveBShs7WjxJKp5Cg-wtrrqTrZ3p3NU2qZqrSRhkWPUrt5dnEfqthH-widN_KiZWy108hZjTWCR5ZcRPHnraYixApsMpwkoYiOUX_IxUofUQBc1UVFqTE4atmNbtgVZXyg18m_kY365EmIUwGWWnzTY0BpL0-_AI4dk1CnTUB4Ak6ldfdvQnfJQYDxls8jx1dJWaWSJXvTh-hkVyTtkJOw9uNSL84cajFyhRpLC8pw’}

  1. using the id_token have to call logout api.

https://dev-255595.oktapreview.com/oauth2/v1/logout?post_logout_redirect_uri=http%3A%2F%2F127.0.0.1%3A8000%2Flogin&
id_token_hint=eyJraWQiOiJFRHA0TzBNa2xJM2xKc2ZWd01ILXRkczhPZnFyclJJeDBTNnk0cHBib1U4IiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiIwMHVkY2VxMHh3MEFvb2pINjBoNyIsIm5hbWUiOiJCQUxBIiwiZW1haWwiOiJicGF0dHVzYW15QGNvbnZpdmEuY29tIiwidmVyIjoxLCJpc3MiOiJodHRwczovL2Rldi0yNTU1OTUub2t0YXByZXZpZXcuY29tIiwiYXVkIjoiMG9hZGVpbmRubVM2b041ck4waDciLCJpYXQiOjE1MjIzMDMwMzksImV4cCI6MTUyMjMwNjYzOSwianRpIjoiSUQuMElIeDRldXlHVXFjX1VHUjJhZVV3M2FvaDNYMkFpTW93eUhRcmJLYWxQYyIsImFtciI6WyJwd2QiXSwiaWRwIjoiMDBvZGNlcTB2ZDl1eGJVUjMwaDciLCJub25jZSI6InlHNGNDQlV3dVJCb2I4OXdvUjhZdVhlWmRYZWxnazJqbE1rWkR0aFp5RWRVMjd0ZkdIQnN1WnhyTDk4eWJSVzUiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJicGF0dHVzYW15QGNvbnZpdmEuY29tIiwiYXV0aF90aW1lIjoxNTIyMzAzMDM2LCJhdF9oYXNoIjoiM3FoRWdHVFdZTzgwcGU4R2ZXVGxGdyJ9.Xrhjf5GhPfrg_NpZUXLs0L-mQFCmmwbAsju2guHOvItwcRayOBSKvc4Y0sq_UyxdVziTfo-d_AfbBU1yxAYFWenyChU3OseXQQziHuyYX08NCveBShs7WjxJKp5Cg-wtrrqTrZ3p3NU2qZqrSRhkWPUrt5dnEfqthH-widN_KiZWy108hZjTWCR5ZcRPHnraYixApsMpwkoYiOUX_IxUofUQBc1UVFqTE4atmNbtgVZXyg18m_kY365EmIUwGWWnzTY0BpL0-_AI4dk1CnTUB4Ak6ldfdvQnfJQYDxls8jx1dJWaWSJXvTh-hkVyTtkJOw9uNSL84cajFyhRpLC8pw&
state=FkSgPf7a6gRQcXt9IBFy0fy5foXIFUS6pYPB6aQhvHpSACdFxh1QJzgBTGHvhzv7

Here the logout api is not working 403 forbidden error getting

Thank you for the detailed steps. I am going to try to reproduce this myself.

@bala What type of application are you building? Can you help me understand how it relates to your existing portal and to Okta?

I am using python django framework based web application.

My scenario may be different?

Relatively new to okta. I have been using the sign in widget and api’s so am familiar with several. However, this client wants to use the signin widget and then redirect to a custom dashboard. I only have the sessiontoken provided by the signin widget response.

How do I get the user_id as simply as possible without changing everything to some other scheme? I have to pull over the specific user’s information and apps, using those APIs, but right now, I only have a sessiontoken from the signin widget.

Thanks!

Hello,

We have scopes defined in our authorization server that requires user’s consent. When I try exchanging a sessionToken I just got for authz code, with /authorize (prompt=none), I see

error=consent_required&error_description=The+following+scopes+require+user+consent

if I set prompt=consent. my exchanging call at /authorize endpoint got the consent page.
request is as:
curl -i ‘https://myserver/oauth2/my_authz_server/v1/authorize?client_id=${cid}&response_type=token&scope=${my_consent_required_scope}&prompt=consent&redirect_uri=https://localhost:9999&state=1239&nonce=foo&sessionToken=${sessionToken}

is it ever possible to exchange sessionToken for an authz code/access token that has consent-required scope included? We want to use this in our automated tests

please help. Thank you

Perhaps login once with your test account to grant consent? Consent is remembered and the user shouldn’t be prompted again (default behaviour).

If no prompt parameter is specified, the standard behavior occurs:

  • If an Okta session already exists, the user is silently authenticated. Otherwise, the user is prompted to authenticate.
  • If scopes are requested that require consent and consent isn’t yet given by the authenticated user, the user is prompted to give consent.

This wouldn’t help if you’re trying to test the consent page itself.

Also prompting for consent every single login for a real user may cause them not to like you very much - pretty annoying :wink:

1 Like

Hi, Abole,

Thank you for the reply. Our integration tests create a new user/account every run. Hence it is not an option to manually consent. Also, the consent page is a bunch of javascript, I have to load the page in a browser for it to be interpreted (looks to me as I am not a JS expert). I cannot just do a POST to an URL with some payloads url encoded to consent in a REST way, can I?

please help

The /users API early access grant operations doesn’t seem to have a way to programmatically set consent via api (just read and delete).

I couldn’t find any other possibly related APIs, so looks like there’s no way to do that.

Maybe you can work out the names for all the generated fields for the consent page and try to do a POST? If you inspect the page using chrome devtools you can find the name of each field. However if names are randomly generated (I haven’t checked), this could be a challenge.

Or just have a static user account (assuming user creation isn’t actually something you’re testing). If you’re creating / using / deleting a user frequently in prod, this could drive up your licensing (depending on your agreements, etc with Okta).

Hi, abole,

Thank you for all the information. Really appreciate it. I get around by create a first party application, i.e, “consent” : “TRUSTED”. It suppresses the consent required scopes. When I exchange session token for an access token with ‘prompt=none’, I got access token back at the redirect.

1 Like

We are looking for a solution to a similar issue we are seeing in our custom Angular App.

Here are the specifics :

  1. We have a Web Application portal into which users login(not using okta’s login page, just an SPA application login page).
  2. We have created an App Integration in Okta which is having Application Type as ‘PKCE’ flow (Client id : 0oa11vj7xc5CwbRVz0h8).
  3. We capture the user email and password from the front end and pass it to server side and are making an Okta API call to the Authentication API and receiving a SessionToken back.
  4. We need to Get a user specific access token in the server side code and pass it as a JWT token to another API/ Redirect user to another SAML App without getting prompted to login.

What we tried doing(using Postman):
Make a call to the /authorize endpoint, passing the session token(and other relevant parameters) We received both
AccessToken : Checked validity using POST /oauth2/v1/introspect?client_id=<>. With parameters token= {Access Token} & token_type_hint=access_token. GOOD
ID Token : Checked validity using POST /oauth2/v1/introspect?client_id=<>. With parameters token= {ID Token} & token_type_hint=id_token. GOOD

Once we got valid Access Token & ID token we redirected to the application protected URL(Custom app protected URL,SAML app endpoint),
using /login/sessionCookieRedirect with token={ID Token} & access_token={ Access Token} it redirects to the URL but again prompts for Login.

Since the user was already authenticated in the previous step using authentication API, we don’t want them to have to put in credentials again. We are doing anything wrong here or missed any step?

Hi @potnuru the model these days is usually to direct the user to put their credentials directly in Okta (straight to the IdP) and either

    • get an authorisation code back to pass to your backend to swap for a token
    • get a token back you use with your backend (depending on your flow)

In your example above, when your back end gets the sessionToken back from the Okta /authn endpoint it can then be used in a call to the /authorize endpoint. The backend will then get a code it can use to exchange for an Access Token against /token.

I’m guessing here, but some of your complexity may be because you have your own user store for your web portal and then you’re also trying to use Okta (a second user store). You may want to consider migrating everyone into Okta.

Some other variations / options to work around your problem (which may or may not be useful):

  • If the APIs your backend will call don’t need to be user context specific, consider the client credentials flow to get a token issued just to your backend. This keeps your authentication boundaries a little clearer.
  • Consider a federation between your app and Okta. Your app could be the IdP and initiate a sign-in redirection to Okta and get a token back form okta that way. You’d have to build some OpenID/SAML IdP logic into your app. This may be an option if you don’t want to consolidate users into Okta.
1 Like