Does authorization code should be somehow linked with Resource owner? I have faced with one specific case.

Testing case: 2 users(Resource Owners: Bob & John). Bob click "login with EXAMPLE" and input the credentials for EXAMPLE social network. The responce from the server contains code equal qwerty123. John does the same as Bob and use Bobs` code(qwerty123) and as the result John obtains Access token intended for Bob.

I remember in RFC6749 it is specified that the auth code to be bound with any client_id, not a user. Is it a security weakness?

CodePudding user response：

Stealing authorization codes is a potential security weakness. In the case of a public client, the code can be exchanged directly for an access token. The use of PKCE (as defined in RFC7637) is recommended to protect against this. This will be a requirement for all clients in OAuth 2.1.

If the client isn't a "public" client, then it still needs to authenticate to the token endpoint in order to exchange the code for an access token, so an attacker would not be able to obtain an access token with just the stolen authorization code.

CodePudding user response：

In addition to the other answer: even when the client is not a public client, the attacker could replay a stolen authorization code against the legitimate client in a so-called "confused deputy" attack. The legitimate client would exchange the stolen code at the token endpoint with the legitimate client credentials, allowing attacker John to obtain an access token for user Bob.

To mitigate this, there's the (recommended) state parameter, see: https://www.rfc-editor.org/rfc/rfc6749#section-4.1.1 and: https://www.rfc-editor.org/rfc/rfc6749#section-10.12. It is supposed to be cryptographically bound to the browser - e.g. via a cookie - preventing cut-and-paste to the attacker's browser. It is therefore bound to the end user operating that browser - and authenticating to the Provider - as well which is what the OP was suggesting.