signInWithRedirect - how to choose where to redirect to?

Hi Friends,

I have successfully added login with both IDP and signInWithCredentials through signInWithRedirect.

Right now, it seems to redirect to ‘/’ no matter where the original window location is, as well as not even render the ‘/’. I’d love if anyone can show me how to point where it should redirect to.

Any help would be greatly appreciated!

What do you have set as the redirectUri in your config?

You’ll need to set this option in the config (and add the matching Sign in redirect URI to the app in the Okta admin console) to change where the redirect goes to (which is where the authorization code/tokens will be returned).

Hi andrea,

I have it set to:

redirectUri: window.location.origin + ‘/callback’

I have the baseURL/callback added in the admin console, as well as the baseURL itself… not sure if that’s correct honestly haha

Hmmm… so when the authorize call is made, what redirect_uri do you see being passed in as a parameter for that request (check the network tab)? Are you getting any sort of error, or is the authorize call successful?

Completely missed this reply, sorry about delay - Not exactly sure what I should be looking for.

I see this on the network tab when I login. I don’t see any error responses on the tab, the login is successful.

It sure looks like Okta is redirecting back to the right redirect _uri (ending in /callback). Is your application doing anything when this occurs?

The next step is to exchange the code returned for tokens at the /token endpoint, which our SDKs can help with, for example, see the handleLoginRedirect method for the Auth SDK. Do you have any logic on your callback route to do so?

Hm… Where would I see what happens once my app hits /callback?

Here is my code for manual login… the IDP login option is just the URL. Super side note, is there any suggestion for a type for the response of signInWithCredentials? I have an “any” there but typescript is not happy with that :frowning:

const handleSubmit = (e: React.SyntheticEvent<EventTarget>) => {
    console.log("Login HandleSubmit")

    oktaAuth.signInWithCredentials({ username, password })
    .then((res: any) => {
      const sessionToken = res.sessionToken;
      // sessionToken is a one-use token, so make sure this is only called once
      oktaAuth.signInWithRedirect({ sessionToken });
    .catch((err: Error) => console.log('Found a Login error', err));

for the callback route, i just have

<Route path='/callback'>
      <LoginCallback errorComponent ={LoginError}/>

loginerror component just has a button to go back to home page after a failed login

that’s probably why you’re getting stuck after the redirect, the route you redirect to needs to make the missing /token call to complete the PKCE flow.

Either you can add this missing logic to your callback route or move it all to your login page and set that as your redirect_uri. Either way, you will want to handle the following states:

  1. if its in the middle of a login callback, detected using isLoginCallback
    a. handle the callback to get tokens,
    b. redirect them wherever they need to go in the application
  2. (optional, depends on third party cookie access) if user is logged into Okta, checked with session.exists(), but doesn’t have tokens in storage, aka not isAuthenticated(), call signInWithRedirect to kick off the OAuth flow
  3. if user is not logged in, prompt them to sign in and use the code above to make the signInWithCredentials and signInWithRedirect calls

I have no idea where I am actually even redirecting to after I call signInWithRedirect…

Ok i found i can add an original URI prop to signinwithredirect.

i am unsure as to how i am supposed to add the missing logic to the callback route because my callback route is just the LoginCallback component provided by Okta. should i go into that and directly add code there?

What all Okta SDKs are you using right now?


im not sure what the token call is referring to because my login does get a token and then use it to sign in (?)

The big issue is that after the login callback goes off, it doesn’t render whatever route it gets sent to, and my user will have to refresh the page.

You are conflating two completely different types of tokens

  1. the session token is returned from a successful primary authentication into Okta via the /api/v1/authn endpoint
  2. OIDC applications ALSO use ID tokens and Access Tokens to grant users access to an application. This is the part that your application is not handling fully. While you are able to log users into Okta successfully, your application does not have the ID and Access Tokens it will use to grant the user access.

You may want to check out one of our guides about how to use the Auth JS SDK to handle the OIDC flow: Okta Auth SDK Guide | Okta Developer

What you are doing right now is taking the session token returned from /authn and sending it to the /authorize endpoint to kick off an OIDC flow, as described in our docs here, but you have not completed this flow until a request to the /token endpoint is made. More details about PKCE flow (the OIDC flow being used) here: Implement authorization by grant type | Okta Developer

Okay, that makes more sense. I will attempt to add the missing pieces and report back, thank you

I’m looking through the docs - I’m using React specifically, I see in the docs for Javascript they do parse for an id_token, but the React docs I am not seeing any documentation on doing so.

Any advice would be appreciated - should I just add the

if (authClient.isLoginRedirect()) {
  // Parse token from redirect url
    .then(data => {
      const { idToken } = data.tokens;
      console.log(`Hi ${}!`);
      // Store parsed token in Token Manager
      authClient.tokenManager.add('idToken', idToken);
} else { 
   // send user to login page?

to the app.tsx file i have my authclient set up?

does LoginCallback not do the token parsing for me?

If you’re using React, maybe check out our sample app instead, and, yes, the callback component should be handling all of this for you by design.

Hi Andrea,

Yes I have looked at the sample apps before - i think one of the biggest differences is that they use the sign-in widget, whereas i have my own custom log-in form.

Hey Andrea,

I solved the problem. I had my ‘/’ route, Login, and LoginCallback all under a Switch statement. Not entirely sure why taking those routes out fixes it, but yeah it’s good now.