parseFromUrl returning empty tokens upon callback and no Network call to /token

[rudeshko-traderev]

I was using implicit flow for the initial stages of our application, and it was working fine, but once I switched from responseType: "token" to responseType: "code", the library doesn't seem to be returning the tokens when it's exchanging the authorization code for the tokens.

I can see that in the browser it has the authorization code, and my custom state parameter, and in Angular 1 I am calling parseFromUrl which returns {tokens: {}, state: "okta-custom-state", code: undefined}.

I am using another Okta instance as the idp, so in the initial call to getWithRedirect, I pass the idp parameter. It might be related.

I also don't see the call to the /token endpoint in the Network tab, only the first call to:

https://ourdomain.oktapreview.com/oauth2/<issuer_id>/v1/authorize?client_id=<client_id>&code_challenge=<code_challenge>&code_challenge_method=S256&idp=<custom_idp>&nonce=<nonce>&redirect_uri=http%3A%2F%2Flocalhost%3A8000&response_mode=fragment&response_type=code&state=okta-custom-state&scope=openid%20profile

And it responds with 302 and no response body.

Does anyone have any ideas on why this might be happening? I noticed in the library itself, if the following fails, it doesn't make the call, but I am not sure if that's the reason.

@okta/okta-auth-js/token.js:241:

    if (res.code && pkce) {
      responseType = ['token', 'id_token']; // what we expect the code to provide us
      return exchangeCodeForToken(sdk, oauthParams, res.code, urls);
    }

[aarongranick-okta]

@rudeshko-traderev

It is expected that the 302 has no response body. The code will be in the URL returned in the response headers from the 302 response. In this case, it looks like it will be something like http://localhost:8000#code=XXX

A few things may be going wrong here: 1) Try adding a trailing slash after your redirectURI. Certain browsers will drop the hash fragment if the URL path does not end with a path 2) Try using responseMode: 'query' in your authJS config. This will pass the code in the URL query instead of the hash fragment 3) We typically recommend using a dedicated route/path for handling the callback. The reason is that there may be other logic running on your main route which may interfere with handling the redirect callback. Typically we do a redirect login flow by first saving the current location, then redirecting to Okta. On the redirect callback, call parseFromUrl which reads the tokens from the URL, rewrites the URL so the tokens are no longer present, and then saves the tokens in storage. After this, it reads the "original" location from storage and redirects to the path that began the login flow.

It is OK to handle the callback from the root path, but you must be careful to understand whether you are loading the app in an authenticated state, an unauthenticated state, or in the callback handler. I would recommend testing for the existence of the param "code" in the URL (either in hash fragment or query, depending on how responseMode is configured). If the code exists in the URL, this is the signal that your app should handle the callback and not perform ANY other logic to determine if the user is authenticated (such as tokenManager.get). After the callback has been handled and tokens are stored, it will be safe to call tokenManager.get. If it is called before/during a callback there may be a race condition.

[swiftone]

@rudeshko-traderev - Did any of the above suggestions help with your experience?

[aarongranick-okta]

@rudeshko-traderev - It will also be helpful to know whether your client is a SPA or WEB type. Both types can use the implicit flow, but PKCE is only for SPA applications. WEB clients will use the "authorization_code" flow. We will be happy to continue assisting you with your issue, if it still exists. Thanks!

[anandadvisory]

@aakashyadav-okta I am facing the same issue with authorization_code

[aakashyadav-okta]

@anandadvisory probably you got the wrong Aakash

[aarongranick-okta]

@anandadvisory Were you able to find a resolution for this issue?