I have a program that integrates with the YouTube Live Streaming API. It runs on timers, so its been relatively easy for me to program in to fetch a new Access Token every 50 minutes with a Refresh Token. My question is, why?
When I authenticated with YouTube, it gave me a Refresh Token. I then use this refresh token to get a new Access Token about once an hour. If I have the Refresh Token, I can ALWAYS use this to get a new Access Token, since it never expires. So I don't see how this is any more secure than just giving me an Access Token from the start and not bothering with the whole Refresh Token system.
Basically, refresh tokens are used to get new access token.
To clearly differentiate these two tokens and avoid getting mixed up, here are their functions given in The OAuth 2.0 Authorization Framework:
- Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.
- Refresh Tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope.
Now, to answer your question on why you were still being issued a refresh token instead of just securing an access token, the main reason provided by Internet Engineering Task Force in Refresh tokens is:
There is a security reason, the
refresh_tokenis only ever exchanged with authorization server whereas theaccess_tokenis exchanged with resource servers. This mitigates the risk of a long-lived access_token leaking in the "an access token good for an hour, with a refresh token good for a year or good-till-revoked" vs "an access token good-till-revoked without a refresh token."
For a more detailed and complete information of OAuth 2.0 Flow, please try going through the following references: