Open florin05 opened 3 years ago
@florin05 Thank you for using Okta. Those two parameters you are seeing, "prompt" and "response_mode" are are used by the widget when silently receiving tokens. I am assuming since you are using Angular, this is a SPA application. (Please confirm). In many cases it is not necessary for SPA applications to redirect and the tokens are returned directly by the widget.
For example:
oktaSignIn.showSignIn().then(res => {
oktaSignIn.authClient.handleLoginRedirect(res.tokens);
});
This will retrieve tokens, set them in storage, and then navigate to the app origin or protected route (if that is what triggered the login)
(Note that while this sample uses showSignInToGetTokens
, we recommend using showSignIn
as it can also handle cases where your app WILL need to handle a callback on redirectURI, such as when using a 3rd party IDP)
@aarongranick-okta , thank you for your answer. Indeed our app, like all Angular ones I believe, is a SPA application.
We have our own wrapper around the @okta/okta-signin-widget and have been using is successfully with versions 4* of that widget. We have the PKCE workflow and was redirecting to the call back url after authentication.
But seems like after we upgraded to version 5*, the redirect step is not happening, from what I read here https://github.com/okta/okta-signin-widget#authclient
SPA Application
Although a redirectUri is required in the configuration, no redirection will occur using this flow. The Sign-in Widget will > communicate with Okta and receive tokens directly.
I thought that was part of the PKCE flow, a callback is always needed to exchange/validate the code and get the tokens. Does this mean that now PKCE, the default flow, works without that callback redirect? Or do I need to invoke that step explicitly?
Hello
We have an Angular app using "@okta/okta-signin-widget": "version": "5.12.0", with this configuration
After upgrade from Angular 9 to 11 (and the widget from 5.4 to 5.12) the redirect to call back client url is not happening anymore I see two new parameters (10 and 11 below) in this request https:///oauth2/default/v1/authorize
Not sure why they are there now, but I am guessing they are responsible for the fact that now we don't see the 302 redirect as the outcome of the "/authorize" call.