Access Token generation from OKTA API

Hi,

This question is regarding the OKTA access token generation where I am getting an access token but when parsed with JWT, the token doesn’t include any user details. Our organization has MFA authentication.

Steps:

  1. I first hit api/v1/authn and I get a response that includes “stateToken” , “id”, “profile” and other necessary response.
  2. With the output from above response, I hit “api/v1/authn/factors/<>/verify” and get a response.
  3. Then I hit “oauth2/default/v1/authorize” with the following params
    client_id: clientid,
    state: stateToken,
    redirect_uri: redirect,
    scope: [“openid”, “profile”, “email”],
    code_challenge_method: ‘S256’,
    nonce: 12345,
    sessionToken: sessionToken,
    response_type: ‘id_token token’

When hitting the above api, I get a response with id_token and access_token where when using this, doesn’t authenticate the application.

On further investigation, I tried to parse the token where I found my API token doesn’t have the name and email

But the access token from the actual UI login gives me all these details…

Please help me out with this.

can you please clarify few things:

  1. what does that mean?
  1. when you referring to token later, are you talking about access_token or id_token?
  2. what is

@phi1ipp with the payload details hitting the service, I get the following response:

https://applicationURL/#id_token=eyJraWQiOiI4TzAxS0I4akZaMDhhTTVSN21UY01RZTZyV3N2QXlseGRscGUtQjhzR3I4IiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiIwMHUxaGc1cTdkZGM2WlMyQjBoOCIsI
nZlciI6MSwiaXNzIjoiaHR0cHM6Ly9pZmYub2t0YS5jb20iLCJhdWQiOiIwb2ExaDFjMHZuZXN1aGxwcjBoOCIsImlhdCI6MTU5NzAzODU3MiwiZXhwIjoxNTk3MDQyMTcyLCJqdGkiOiJ
JRC5kWmJzNDhIeGJRMzMxU3F0R3AtRWZTWS03eDF6ajBUakhiX2ZOZ29BbkFzIiwiYW1yIjpbInB3ZCIsImtiYSIsIm1mYSJdLCJpZHAiOiIwb2F4d2N0dWxlRlpQV1RCWllJViIsIm5vb
mNlIjoiZW9FQUhRR25HNldwTjNPNlAzZlNYQjV0Q3FoWjhGN3AiLCJhdXRoX3RpbWUiOjE1OTcwMzg1NjgsImF0X2hhc2giOiJ5WXNPUmtEekJ3Qm1HYW9XOVJhdDVnIn0.DCWP06jbCQ9
1xfVDgKtG9uq3H3NV4vxHVL6b5B2LJ_JXtVakYDFhsQEghIm6A9GZAfwxIgeZoUsOpGuluItzk0UhEWp04Rg9PL0GuayPizx4PwI08RbSHkih9i-y_UBG0THvX-HlDHmZbG6nkhA7QO20z
Sl-t7gJbE66noD6_77iWAt28fyfV6KzEw2Qr_ktQ9rJGhIkru_MDyWv5Tw-zeNbjQK8-n1ExCRP_5Ug8azixNOhkIvaQHppRLaOj6T4dRsAW07f2sGYC2XZGy5I_2_nLUBuZ39B0AhQoR1
fKh_LYZZvGpDRoRdXXmUq_KKDpWazQfZoX4MD9p1rRhq8LQ&access_token=eyJraWQiOiJHbEQ0dkhRNjdiNnUzMkRzMEJLc201cEZJVVNRZ2J0eEFZelFIdTlBWkcwIiwiYWxnIjoiUlMyNTYifQ.eyJ2ZXIiOjEsImp0aSI6IkFULjdReTVnRHE
zMjB5OFNiN0syZDh4b0ZhbjJ2SEY2OXJRNUxGWkVWNHlTQ0UiLCJpc3MiOiJodHRwczovL2lmZi5va3RhLmNvbSIsImF1ZCI6Imh0dHBzOi8vaWZmLm9rdGEuY29tIiwic3ViIjoia3h
yMzcwM0BnbG9iYWwuaWZmLmNvbSIsImlhdCI6MTU5NzAzODU3MiwiZXhwIjoxNTk3MDQyMTcyLCJjaWQiOiIwb2ExaDFjMHZuZXN1aGxwcjBoOCIsInVpZCI6IjAwdTFoZzVxN2RkYzZ
aUzJCMGg4Iiwic2NwIjpbIm9wZW5pZCJdfQ.UVSPz_YCGcCutjqITdpN3NqYPSq68cq65QybNY_5e_iPErpwmAcc7EDLdtLwQUElV4bHl-4EjkQPhhlLOgCaYSy1_fyKct6VIjmyEivy
G2lrIxKsE9NgNcdA3XCO10OhZix9o01ZM6B3qWii094N_RySJaqNN4vEOsK6TtZNrfUqDxij2MRC_RfPQemye3WEBtdypj_fbLR0_piACwgXyrjGz1uF1f_knmEFfB3LNJgy-3ZvFnVp
C3h-ceoPeRkajchPlF4XeDX1TjaCeL_rXECuOZ_mGJSKbmZRnkb1YZ-VX2WgqxftSKMC1n9YQAjJW5ox6vuAG18hpjtY1ywY9g&token_type=Bearer&expires_in=3600&scope=openid+profile+email&state=006kzTt4Q6y_uICu08HTw14xkgv1Mt_FPERjxbM_kc


with the token generated from above response, I tried using id_token first to authenticate the application from postman which in turn didnot authenticate. I used access_token as well and that too didnot work out. On further investigating through JWT, I found that the token from above response didnot hold the email, name and preferred_name details as defined in the screenshots of my query.

The token from actual UI means that I logged in to the application from the browser OKTA screen were I entered the User name, password and auth text and post authentication, fetched the “x-access-token” key from the header by inspecting the network tab. The token that I fetched from the network tab holds the details of email, username and preferred_name fields which I assume are the important parameters/details in the token that are required for authenticating the application.

Correct me if I am wrong.

Please let me know for any questions/clarifications.

So, few things:

  • are you trying to get a token to send it to your backend API/application?
  • you can’t use id_token to get access to your application, so it’s not supposed to work
  • can you make sure that your UI does not request any additional scope besides what you request when doing manually?



Then the application is authenticated and navigates to redirect uri

The steps I follow, to get the token is as follows-
Through my automation script, I hit api/v1/authn with the user name, password and
“options”: {“warnBeforePasswordExpired”: true,“multiOptionalFactorEnroll”: true}

This gives me stateToken. with that state token and my mfa “answer” I post a request to api/v1/authn/factors/id/verify where I get the session token.

With the state and session token, I do a get request to oauth2/v1/authorize with the following details-
{
client_id: ‘0oa1h1c0vnesuhlpr0h8’,
state: stateToken,
redirect_uri: ‘URL’,
scope: [“openid”, “profile”, “email”],
nonce: res3.body.nonce,
sessionToken: sessionToken,
response_type: ‘id_token token’
}

The response I get here is the following
https:///#id_token=eyJraWQiOiI4TzAxS0I4akZaMDhhTTVSN21UY01RZTZyV3N2QXlseGRscGUtQjhzR3I4IiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiIwMHUxaGc1cTdkZGM2WlMyQjBoOCIsI
nZlciI6MSwiaXNzIjoiaHR0cHM6Ly9pZmYub2t0YS5jb20iLCJhdWQiOiIwb2ExaDFjMHZuZXN1aGxwcjBoOCIsImlhdCI6MTU5NzAzODU3MiwiZXhwIjoxNTk3MDQyMTcyLCJqdGkiOiJ
JRC5kWmJzNDhIeGJRMzMxU3F0R3AtRWZTWS03eDF6ajBUakhiX2ZOZ29BbkFzIiwiYW1yIjpbInB3ZCIsImtiYSIsIm1mYSJdLCJpZHAiOiIwb2F4d2N0dWxlRlpQV1RCWllJViIsIm5vb
mNlIjoiZW9FQUhRR25HNldwTjNPNlAzZlNYQjV0Q3FoWjhGN3AiLCJhdXRoX3RpbWUiOjE1OTcwMzg1NjgsImF0X2hhc2giOiJ5WXNPUmtEekJ3Qm1HYW9XOVJhdDVnIn0.DCWP06jbCQ9
1xfVDgKtG9uq3H3NV4vxHVL6b5B2LJ_JXtVakYDFhsQEghIm6A9GZAfwxIgeZoUsOpGuluItzk0UhEWp04Rg9PL0GuayPizx4PwI08RbSHkih9i-y_UBG0THvX-HlDHmZbG6nkhA7QO20z
Sl-t7gJbE66noD6_77iWAt28fyfV6KzEw2Qr_ktQ9rJGhIkru_MDyWv5Tw-zeNbjQK8-n1ExCRP_5Ug8azixNOhkIvaQHppRLaOj6T4dRsAW07f2sGYC2XZGy5I_2_nLUBuZ39B0AhQoR1
fKh_LYZZvGpDRoRdXXmUq_KKDpWazQfZoX4MD9p1rRhq8LQ&access_token=eyJraWQiOiJHbEQ0dkhRNjdiNnUzMkRzMEJLc201cEZJVVNRZ2J0eEFZelFIdTlBWkcwIiwiYWxnIjoiUlMyNTYifQ.eyJ2ZXIiOjEsImp0aSI6IkFULjdReTVnRHE
zMjB5OFNiN0syZDh4b0ZhbjJ2SEY2OXJRNUxGWkVWNHlTQ0UiLCJpc3MiOiJodHRwczovL2lmZi5va3RhLmNvbSIsImF1ZCI6Imh0dHBzOi8vaWZmLm9rdGEuY29tIiwic3ViIjoia3h
yMzcwM0BnbG9iYWwuaWZmLmNvbSIsImlhdCI6MTU5NzAzODU3MiwiZXhwIjoxNTk3MDQyMTcyLCJjaWQiOiIwb2ExaDFjMHZuZXN1aGxwcjBoOCIsInVpZCI6IjAwdTFoZzVxN2RkYzZ
aUzJCMGg4Iiwic2NwIjpbIm9wZW5pZCJdfQ.UVSPz_YCGcCutjqITdpN3NqYPSq68cq65QybNY_5e_iPErpwmAcc7EDLdtLwQUElV4bHl-4EjkQPhhlLOgCaYSy1_fyKct6VIjmyEivy
G2lrIxKsE9NgNcdA3XCO10OhZix9o01ZM6B3qWii094N_RySJaqNN4vEOsK6TtZNrfUqDxij2MRC_RfPQemye3WEBtdypj_fbLR0_piACwgXyrjGz1uF1f_knmEFfB3LNJgy-3ZvFnVp
C3h-ceoPeRkajchPlF4XeDX1TjaCeL_rXECuOZ_mGJSKbmZRnkb1YZ-VX2WgqxftSKMC1n9YQAjJW5ox6vuAG18hpjtY1ywY9g&token_type=Bearer&expires_in=3600&scope=openid+profile+email&state=006kzTt4Q6y_uICu08HTw14xkgv1Mt_FPERjxbM_kc

The same requests are being made in UI and the response I get in the browser URL has the same id_token and access_token which when parsed in jwt shows me name, email and preferred_name parameters… but when the requests are made through the script, I don’t get these details in my response.

Please correct me if I am wrong at any of the steps.

My requirement is to authenticate my application by getting access token via these requests and without going to OKTA page…

Thanks

@phi1ipp, in addition to the details above, the following are the get requests that are triggered automatically.

Is there anything that I need to do here?

Please help

It seems like what you are doing is correct to obtain the access_token. Is there any chance you can reach your developers and ask them, what the problem is on the application side? Do they require that access_token includes email and names?

Thanks @phi1ipp… I reached out to my developer where they insist the inclusion of email and names. Is there any way we can append these details in the token?

Well, I’m afraid it requires then a thorough investigation of differences between how you request the token, and how they do. As it should not be any different, who requests the token, as long as it’s the same authentication server, flow and client.

I can only recommend to make one more approach to investigating their application flow