Skip to content
This repository has been archived by the owner on Sep 18, 2021. It is now read-only.

Press browser back button after successful authentication. #423

Closed
mynkow opened this issue Oct 8, 2014 · 8 comments
Closed

Press browser back button after successful authentication. #423

mynkow opened this issue Oct 8, 2014 · 8 comments
Assignees
Labels

Comments

@mynkow
Copy link

mynkow commented Oct 8, 2014

I am not sure if this is a bug or it is actually an enhancement.

  1. User tries to access a protected resource A
  2. User is redirected to the login page and authenticates
  3. The user is redirected back to the resource A page
  4. User clicks the browser's back button

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

@brockallen brockallen self-assigned this Oct 8, 2014
@brockallen
Copy link
Member

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.

@brockallen
Copy link
Member

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?

@brockallen
Copy link
Member

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?

@mynkow
Copy link
Author

mynkow commented Oct 13, 2014

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 :)

@brockallen
Copy link
Member

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.

@mynkow
Copy link
Author

mynkow commented Oct 13, 2014

Do you think that storing in memory of all the successful signing IDs for the last 5-10 minutes is a solution?

@brockallen
Copy link
Member

That's more "stuff" for people to setup in a web farm environment.

@rklachko
Copy link
Contributor

What about not clearing the signin cookie (or keeping a similar cookie instead) so we would know what client the request originally came from?
Or maybe even saving in a cookie all previous successful logins... this may even allow some kind of federated signout like existed in wsfed based IDP.v2 (if that makes any sense for oauth).
Any thoughts?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants