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.
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).
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?
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
const handleSubmit = (e: React.SyntheticEvent<EventTarget>) => {
console.log("Login HandleSubmit")
e.preventDefault();
oktaAuth.signInWithCredentials({ username, password })
.then((res: any) => {
const sessionToken = res.sessionToken;
setSessionToken(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));
};
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:
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
(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
if user is not logged in, prompt them to sign in and use the code above to make the signInWithCredentials and signInWithRedirect calls
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?
You are conflating two completely different types of tokens
the session token is returned from a successful primary authentication into Okta via the /api/v1/authn endpoint
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.
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
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.
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.