Search code examples
oauth-2.0

How does OAuth 2 protect against things like replay attacks using the Security Token?

As I understand it, the following chain of events occurs in OAuth 2 in order for Site-A to access User's information from Site-B.

  1. Site-A registers on Site-B, and obtains a Secret and an ID.
  2. When User tells Site-A to access Site-B, User is sent to Site-B where they tell Site-B that they would indeed like to give Site-A permissions to specific information.
  3. Site-B redirects User back to Site-A, along with an Authorization Code.
  4. Site-A then passes that Authorization Code along with its Secret back to Site-B in return for a Security Token.
  5. Site-A then makes requests to Site-B on behalf of User by bundling the Security Token along with requests.

How does all of this work in terms of security and encryption, on a high level? How does OAuth 2 protect against things like replay attacks using the Security Token?

Solution

  • Based on what I've read, this is how it all works:

    The general flow outlined in the question is correct. In step 2, User X is authenticated, and is also authorizing Site A's access to User X's information on Site B. In step 4, the site passes its Secret back to Site B, authenticating itself, as well as the Authorization Code, indicating what it's asking for (User X's access token).

    Overall, OAuth 2 actually is a very simple security model, and encryption never comes directly into play. Instead, both the Secret and the Security Token are essentially passwords, and the whole thing is secured only by the security of the https connection.

    OAuth 2 has no protection against replay attacks of the Security Token or the Secret. Instead, it relies entirely on Site B being responsible with these items and not letting them get out, and on them being sent over https while in transit (https will protect URL parameters).

    The purpose of the Authorization Code step is simply convenience, and the Authorization Code is not especially sensitive on its own. It provides a common identifier for User X's access token for Site A when asking Site B for User X's access token. Just User X's user id on Site B would not have worked, because there could be many outstanding access tokens waiting to be handed out to different sites at the same time.