-
-
Notifications
You must be signed in to change notification settings - Fork 764
Press browser back button after successful authentication. #423
Comments
I tried to repo this on both Chrome and IE. Fortunately they both behaved the same. Here's what I see (via fiddler): RP -> Consent -> Login -> Consent -> RP Once we're done with this flow and back in the RP if the user quickly hits the back button, I see the browser go back to the consent page and the consent page does see the user is already logged in and immediately re-issues tokens (because I previously checked the "remember" option) . If, on the other hand, I wait a second or two after we get back to the RP, then the browser goes back to the login page (with the signin query string) and I see "Unexpected error" because there signin ID doesn't find the corresponding cookie. I'm still investigating. Just wanted to report back this and see if you could confirm. |
Ok, so thinking about this some more... for the quick back button -- I'm not worried about because it goes to the authorization page. But for the slow back button, the browser is returning to the login page with a signin ID. The browser is not going thru the authorization page so we don't even know the client the request is coming from. It's going directly to the login page and the prior signin cookie is long gone, and so we have no context for where the user is coming from. I do not see how we could do anything on the login page to return to the client. Do you have any ideas? I think the real approach would be once the user is sent back to the RP from the OP, perhaps it makes more sense for the RP to then redirect the user once to a landing page. This pushes the "back button" issue to the RP which I think you have more control over how you want it to behave. Thoughts? |
I've fixed the exception that happens due to the absence of the cookie. But I can't see what else to do other than show an error -- thoughts? |
What is the difference between the consent and the login page in terms of the authorization page for example? I am trying to understand how this works internally instead of throwing suggestions blindly. I tried with google and youtube and they somehow did that so I think it is doable :) |
The consent page is the authorization page -- the one where the user is asked to give the client permissions. The login page is where the user enters credentials to authenticate. |
Do you think that storing in memory of all the successful signing IDs for the last 5-10 minutes is a solution? |
That's more "stuff" for people to setup in a web farm environment. |
What about not clearing the signin cookie (or keeping a similar cookie instead) so we would know what client the request originally came from? |
I am not sure if this is a bug or it is actually an enhancement.
Current: The user is redirected back to the login page
Expected: The identity server should detect that the user is authenticated and should redirect back to resource A page
The text was updated successfully, but these errors were encountered: