I’m just trying to get my head around the login user experiences.
In the case of using a server-side configuration of the okta-signin-widget, they are all configured with the signIn.showSignInAndRedirect function.
samples-aspnetcore/samples-aspnetcore-7x/self-hosted-login/okta-aspnetcore-razorpages-example/okta-aspnetcore-razorpages-example/Pages/Account/SignIn.cshtml at master · okta/samples-aspnetcore · GitHub
Documentation notes: " Server-side web applications will receive [OAuth] tokens server-side, so they must handle a redirect callback . These apps should use [showSignInAndRedirect]"
This leads to a user experience:
- User access somedomain/login and see’s self-hosted okta widget
- User enters credentials; clicks submit
- User redirected to customoktadomain/oauth2/default/v1/authorize
- User is then prompted to trigger an SMS send to fulfil the MFA policy.
- User submits MFA code; clicks continue
- User redirected back to somedomain/authorization-code/callback and is authenticated.
Based on the documentation I gather there is no way to have the policy execution steps (Steps 4 & 5) triggered on the somedomain/login widget instead?
I have noted this approach is possible using SPA, however the tokens are then visible on the client,
and I am also aware this is possible with OIE & Interaction code flow with the Okta IDX libraries.