Even though login hint is passed different, okta does not ask user2 for credentials, it returns user1 session instead.
Is there a way to force okta to ask credentials in case different login_hint is provided?
As currently, to handle case, when different user wants to login without logging out first we need to call okta /api/v1/sessions/me to get current session and if it exists and username of current session does not match the one in login_hint terminate current session. Problem is, that we need to do this extra check for each authorization request, which basically means that we’re cutting our okta allowed traffic in half.
You may want to create an application sign-on policy to re-authenticate the user and see if it helps you.
My question to you though is: I don’t believe a user is asked to enter URL manually why can’t your application check if a new username matches username from id_token? If not -> it’s a new user trying to sign in.
application does not always know, as application’s session’s lifetime might be different from okta’s (or application needs to ask okta with method I’ve mentioned in original description - api/v1/sessions/me, but that is eating okta’s request limit). Another case is switching from one application to another - something like I was on mail.acme.com, then opened calendar.acme.com in new tab - calendar tab does not know yet about okta’s session, hence some companies - like google, microsoft solve this problem with pick user session intermediate screen.
users don’t enter url’s, we have own IDP discovery (okta is one of possible providers at the moment, so user start on our hosted login page with username field and then is redirected to specific IDP)
I’ve looked at application sign on policy settings, but it is not flexible enough to achieve what I need, as if I would enable prompt for relogin every x minutes, I would be punishing users, that have single login only without solving 100% problem for users that have multiple logins.
I see you point… Unfortunately Okta does not have this capability at the moment, it’s worth maybe opening an idea for that switching of users. But still I think my point is valid for the application to determine the necessity of logging out a current user first, if you really think about it for the examples you gave to me:
you tell application that you want to sign-in a user A, all it needs to do is to check if it has an token with this user in its storage (based on its own session lifetime policy). If it does, it lets user in, if it does not, it goes to login screen, if it has a token for user B instead, it needs to sign it out and then goes to login screen
I’ll let you go through the flow for switching apps by yourself…
I might be wrong, please point me to the flaws in my thought process.
When your app knows which user it is trying to authenticate, it can provide this parameter as a hint to the authentication server. Passing this hint suppresses the account chooser and either pre-fills the email box on the sign-in form, or selects the proper session (if the user is using multiple sign-in), which can help you avoid problems that occur if your app logs in the wrong user account. The value can be either an email address or the sub string, which is equivalent to the user’s Google ID.
why can’t your application check if a new username matches username from id_token? If not -> it’s a new user trying to sign in.