I have used json webtokens to handle authentication for some hobby websites in the past. For my next site I would like to use OAuth2, to allow my site to be used with other services.

It seems that the OAuth2 authorization_code protocol adds some extra steps (state and the authorization code) in order to prevent a kind of replay attack where one client is tricked into using an access token issued to another client.

Is that the only purpose of issuing an authorisation code prior to token exchange? If I add information such as client_id and expiry time into a signed JWT and return this as the 'authorization_code', skipping the token exchange step, will I have lost any security? I am assuming that all communication is happening over https.

1 Answer 1


The point of the code is to prevent collection of the access token by a man-in-the-middle between the user and the authorization server.

Once the client has the code it needs to use that code in addition to its own client ID and secret and send it off to the authorization server for an access token. This has the benefit that both you and the client are authenticated/authorized against the authorization server, meaning the protected resource has some assurance every party is who they say they are. Once the client has the token, it's supposed to store the token internally and never release it to you.

The interaction between you and the client is authenticated by its own mechanism (say a session cookie), and the client then uses the access token it has internally to reach out to the protected resource.

The key here is that the client is sufficiently protected from someone grabbing the token because it's (for example) on a remote web server instead of the just running locally on your computer.

Conversely, if the client eventually reveals the token to the user, either by using it for it's own session management, or is running locally on your own computer, then the code doesn't provide any value because you can easily extract the client Id, secret, code, or token.

Adding the client Id to the token doesn't necessarily prevent stealing of the token. It just means the token was intended to be used through a given client.

  • Ok, that pretty much answers the first part. But is there really a compelling reason to care about the case where the authorisation code is stolen but the token remains safe on the client server? I am assuming https, so this means the user is compromised anyway. For the second part, my plan is to return the token where the authorisation code is expected, so that token exchange can be (optionally) skipped. Non-local clients would still authenticate with a secret. The idea is just to save a request but still work with tools/libraries that expect normal flow Feb 24, 2017 at 14:30
  • The code is useless to an attacker unless they have access to a client Id and secret that can be exchanged for a token. They can't do anything unless they have those (and the authz server verifies them).
    – Steve
    Feb 24, 2017 at 14:33
  • Yes I understood that in your answer. But my question is also about if that code was useful (i.e it was the actual token). Assuming the code cannot be MITM'd (https), who cares? If the client is running locally, it can't authenticate with a secret anway, and if it is running remotely, it could still use a secret (why? maybe so the user can't impersonate the authorised client). Again, my motivation is to skip the token exchange where possible (local clients) without losing security (and keep the statelessness I had with JWT) Feb 24, 2017 at 14:45
  • Ah I see. You could do it that way, but it's bending the intention of the code flow quite a bit. Why not just use an implicit flow instead where instead of getting a code you're just given a token outright?
    – Steve
    Feb 24, 2017 at 14:48
  • Oh - I thought that OAuth2 was discouraging this (vs original OAuth) and had only looked at 'password' and 'authorisation_code'. Yes I am trying to bend them to work together because some tools/libraries work with authorisation_code only. I guess I can answer my question now just by reading about implicit flow vulnerabilites. Thanks Feb 24, 2017 at 14:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .