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 +---------------+
I think there are reasons why a refresh token is safer than the initial code.
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.