0

Read through a few similar posts in regards to the purpose of Refresh tokens in Oauth 2 flows, and they make sense for user attended authentication such as username and password, but for the Oauth2 client credentials flow, why risk utilizing a refresh token at all?

Is there less system strain or is it faster to use a refresh token to get a new access token after it has expired as opposed to getting an access token through client id and client secret authentication?

Posts Referenced:

S.B.
  • 437
  • 2
  • 6
  • 19

1 Answers1

1

The short and skinny is -- the client can act on its own behalf without involving a resource owner; just request a new access token as before.


...but for the Oauth2 client credentials flow, why risk utilizing a refresh token at all?

Nice observation; the client credentials flow does not issue refresh tokens. Absent a resource owner, it's reasonable to assume the client can request a new access token as needed.

Is there less system strain or is it faster to use a refresh token to get a new access token after it has expired as opposed to getting an access token through client id and client secret authentication?

While it's certainly implementation specific on how "fast" a refresh token is processed, it's likely marginally slower to process a refresh token over a request for a new access token. This is due to the client being able to directly request an access token which does not require validation of a refresh token against the calling client.

ChiefTwoPencils
  • 13,548
  • 8
  • 49
  • 75