Errors in redirect with id_token for OpenID implicit flow

Questions
1

We are using Okta with an OpenID implicit flow to get an id_token. The particular API call we are making to Okta is:
https://dev-264599.okta.com/oauth2/default/v1/authorize?client_id=0oad4b8dfsNpAvHeo356&response_type=id_token&scope=openid+email&redirect_uri=http://localhost:8000/&state=state-296bc9a0-a2a2-4a57-be1a-d0e2fd9bb601&nonce=foo](https://dev-264599.okta.com/oauth2/default/v1/authorize?client_id=0oad4b8dfsNpAvHeo356&response_type=id_token&scope=openid&redirect_uri=http://localhost:8000&state=state-296bc9a0-a2a2-4a57-be1a-d0e2fd9bb601&nonce=foo)

The callback end point is properly authorized. However the returned redirect looks like this:
http://localhost:8000/#id_token=eyJraWQiOiJ3R01TUDd4U2hiOEZiUlJSQnljampRbXdIUlZSaVlIdTBhaXBEb0VZbmw4IiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiIwMHViZGdnenJMRkhkVHN3VTM1NiIsImVtYWlsIjoia2lzaG9yQGNsb3VkcmF4YWsuY29tIiwidmVyIjoxLCJpc3MiOiJodHRwczovL2Rldi0yNjQ1OTkub2t0YS5jb20vb2F1dGgyL2RlZmF1bHQiLCJhdWQiOiIwb2FkNGI4ZGZzTnBBdkhlbzM1NiIsImlhdCI6MTU1MjkyMjI3MiwiZXhwIjoxNTUyOTI1ODcyLCJqdGkiOiJJRC53Z2Q2ZzZnWDhVSF9oMmxnLU1QeXRnQmpQOGVhalFVQ2FxOWVXWmI4WkJNIiwiYW1yIjpbInB3ZCJdLCJpZHAiOiIwMG9iZGdnd3dhcFFjUktrbDM1NiIsIm5vbmNlIjoiZm9vIiwiZW1haWxfdmVyaWZpZWQiOnRydWUsImF1dGhfdGltZSI6MTU1MjkyMTc4OH0.NH4vbCLvLYdt3RDBA7plcaPquAvi3rUImAp-gz39PL0gF51dYLbSYoeaA_JGbzRTY9WUxhTvRsJj1zQSxqTrtO6gxU302WyCbH89HYnMKItVFLNFAA0abOeu_i-s-IuITcpY60RJw0fa4sZ1UsSByiGEGag8tRAGw8AManfSLRq53Z1RtGxy_9wQNV33AowjjYcpKNWyGogAM_NuEgcqQKjD2sRc1uUanuoXYoHmGZNfC__YwqTWpdkycAz29RdwSBMrmGigtUFePRtFt0jEJ_6lilNvhKehXfrP8SCBAxAWnd8K1pPNNn61xm4lS0MP77znEADePT4S0jh83piNtA&state=state-296bc9a0-a2a2-4a57-be1a-d0e2fd9bb601

Notice that there is a # before the id_token. Logically this should have been a ? to indicate the start of the URL parameters. By HTML redirect semantics, the user agent (browser) does not pass anything after the # to the redirect. So we never see the id_token in the back end. The id_token itself is correct – we have manually parsed it. It is just the URI that seems to be malformed.

Any help would be appreciated.

2

Hi @prasanna

When accessing the /authorize endpoint, if you are not specifying the response_mode or if response_mode is set to “fragment”, then the resource requested will be returned as fragment “#” instead of query “?”. As per the article here, unfortunately, JWT tokens can not be returned as query parameters, only as fragment or POST attributes.

3

Thanks. But since POSTs cannot be redirected, and fragments are ignored during redirect, how can you use the callback to get the authenticated user’s id_token? What is the proper flow to do this?

4

You can capture the ID token on the /callback endpoint and, once it’s evaluated and the local session is created, you can redirect to your application’s dashboard with the local session active.

An alternative method would be to do authorization code flow, capture the code from the GET request on /callback endpoint and then send it to /token endpoint in Okta to retrieve the JWT tokens.

5

The issue with the first approach is that since Okta returns with a redirect URL, the user agent never forwards the fragment. The callback endpoint only sees the first part of the URI up to the #
The issue with the second is similar. We can complete the auth flow and get the auth code. But the Okta /token endpoint can only accept a POST. Ideally after getting the auth token, we would want to do a redirect back to the user agent to go back to Okta’s /token endpoint. But you cannot redirect POST parameters.