I am trying to understand how exactly state benefits Oauth flow by preventing CSRF. I just don’t understand what the client server is comparing the state in the URL to. I have seen such an example:
Alice, good.com – good. Mallory, bad.com – bad. google.com – auth server. Alice is already authorized in good.com via google.com
- Mallory begins an auth session.
- good.com generates state=xyz, stores it in it’s db and redirects Mallory to goodle.com/auth
- Mallory completes a flow and ‘traps’ return URL with an
auth code
andstate
- Mallory gives this URL to Alice and she follows it. good.com is called like
good.com/complete-auth?code=abc&state=xyz
So how exactly good.com
can validate that the state=xyz
is not belonging to Alice’s browser? As I understand, to make it work, backend must, somehow, securely give the Alice’s browser any sort of ID before the whole process begins. So when complete-auth
is called that ID is also transferred. But it looks like it’s only possible via cookies. This is the only way server can tell the browser during redirect to save something. I can’t believe in it. How does mobile apps deal with that than?
You need to sign in to view this answers
Leave feedback about this