why not obtain a new access token by resending the authorization grant/code instead of sending refresh token?

Question

I understand that Access Tokens are short-lived because they are verified without hitting the database, whereas Refresh Tokens are long-lived and are verified against the database.

What I don't understand is why there's a difference between getting an Access Token initially by sending an Authorization Grant, and later by sending a Refresh Token.

Looking at this diagram from RFC 6749, why doesn't the client simply resend the Authorization Grant in step (G)? Why is a refresh token ever necessary?

  +--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+

tools.ietf.org/html/rfc6749#section-4.1.2 says that the authorization code cannot be used more than once. — Spomky-Labs
@FlorentMorselli so after a refresh token expires, a client has to obtain a new authorization grant? — Andy
Yes. If the refresh token is not valid anymore (expired, revoked...) then you have to follow the whole flow. — Spomky-Labs

Ján Halaša Ján Halaša · Accepted Answer · 2017-10-24T07:46:05

I think there are reasons why a refresh token is safer than the initial code.

The code is transported from the authentication server to the resource owner's browser and then to the client. The refresh token doesn't go through the browser. So the code is easier to get compromised and should be short-lived of just for one use.
The OAuth 2 specification does not require (just recommends) a secured transport layer for the client's redirection endpoint:

This specification does not mandate the use of TLS because at the time of this writing, requiring clients to deploy TLS is a significant hurdle for many client developers.

but requires TLS for the token endpoint, which is used for getting a refresh token:

Since requests to the token endpoint result in the transmission of clear-text credentials (in the HTTP request and response), the authorization server MUST require the use of TLS

Which makes the initial code insecure and it should be invalidated as soon as possible or when multiple usage is detected. To get the tokens, you still need the client secret, but a refresh token is safer and can be used repeatedly.

why not obtain a new access token by resending the authorization grant/code instead of sending refresh token?

1 Answers