|
|
|
|
|
by ndriscoll
673 days ago
|
|
It's been a while since I've thought about this stuff, but can you put the state param into a cookie (possibly encrypted, but I don't think that's necessary)? Assuming you don't use something like auth0, you can clear the nonce cookie at the same time that you set the login cookie. If they come into your callback without a nonce cookie (or with a non-matching one), you can kick them back to your landing page (or last saved redirect page) without processing the login attempt. If they were already logged in because you already processed it, they stay logged in. The attack the nonce is meant to prevent is tricking someone into logging into the wrong account, right? The attacker can't access or guess the user's cookie to put the right nonce into the URL, so I think that should be safe? If auth0 were going to implement this in the middle for you, then there might be some subtleties to think about with the redirect on failure unless you always send the user to a landing page. More layers of redirects make this kind of thing hard to think through. What's the purpose of auth0 for what you're doing? This might also not work if the authorization code is not re-usable (they're not supposed to be according to the spec) and your backend already used it. If it doesn't work, you could again kick the user back to a landing page, tell them the IdP had an error, and ask them to try again. Or I suppose if you're saving the login to a backend session, then it should just work and you can ignore the error. |
|