I'm implementing client side OAuth and I'm worried about the following scenario.

There is application A registered with service B that is offering access to its user resources - authorized by OAuth (Confidential, Authorization code flow).

Now there is malicious user X that will register to application A and capture initial OAuth redirect - which is trivial to do as it uses Xs browser.

If he manage to get some Bs user (lets call it C) to open the link then B will show that A is asking for access. If A is well known name then there is a chance than the user will approve the access.

Now Bs authorization server is redirecting user back to A and A will fetch access token and may use it to access of Cs resources.

Here is the thing that worry me - if A is using state to identify the authorization process it will know that the request was initiated by X. If it does not separately authenticate the user C then it will connect C resources to X account.

Is this a valid concern? Or is there something in OAuth that prevents such attack?

Is it right to say - 'if OAuth client have its own users it MUST authenticate them when executing authorization response callback - and it can not rely on state parameter for that purpose'?

Is there some additional mitigation that should be applied? For example throttling the rate in which X can initiate OAuth process - in case he is attempting to feed multiple links to multiple targets in hope somebody falls for it? Limiting time for which given state is valid? Other?

  • I wouldn't say that you can't rely on state. I'd say you need both a local authenticated user and a state string, and you must make sure they match. – Wumpus Q. Wumbley Aug 1 '18 at 12:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.