We’re using the Okta sign-in widget to front a web app. We’ve implemented this with the interaction code flow with PKCE. When a user successfully authenticates, the interaction code is sent (via Okta) to a configured callback URI in our webapp. The implementation behind that URI will exchange the code for a token and, if everything goes ok, will redirect the user to their originally requested location.
This is the happy path.
Suppose that something goes wrong in the execution of our callback (e.g. the authorization code can’t be exchanged for a token, the state parameter being passed doesn’t match (CSRF), etc.). We’d like to be able to redirect the user back to our login page where the widget is rendered and show some sort of initial state error - e.g. “We were unable to log you in at this time”.
I’ve been looking at the widget docs and it’s not clear at all if this is possible (you can definitely show errors pre/post submit but we’re hoping to do it on render/load).
If this isn’t possible, what’s the recommended approach to handling exceptions during the token exchange - specifically around how we can message this to users? I suppose we could “surround” the widget with some custom markup that renders the message that we prefer but we’d rather show this message in the context of the widget to make it consistent with how actual widget error messages are displayed (e.g. invalid credentials, user does not exist, etc.).
Thanks.
I’ve done a little more digging on this and am seeing some really unexpected behavior with the widget.
I decided to experiment a bit with the scenario I described above. In our callback, I’m intentionally breaking the flow and then redirecting the user back to our /login page where we render the widget.
Instead of rendering the widget and allowing the user to try again, we get stuck in a loop - the “showSignInAndRedirect” believes the user has already authenticated (which is correct) and that again sends a request to my callback which will (again) send back to the /login page where the cycle will continue.
I understand why this is happening but I definitely don’t understand what we’re supposed to be doing here. Yes, the user is authenticated in Okta and has a session, which is why the widget wants to just forward the request on but in our scenario we really do want to show the login screen so they can try again.
I’m certain I could probably do something like force the user’s session to be closed with Okta before rendering the widget (if there’s an error from our callback) but this seems pretty hackish.
@terence.mcdevitt, do you see any different behavior if you use “showSignInToGetTokens”?
Well, we’re using the interaction code flow here with a web app. So, I don’t really want/need the tokens being returned back to the widget/browser. In that scenario, I don’t think showSignInToGetTokens gets us what we need (but please tell me if I’m wrong).