OAuth authorization code Life Span

[kd88]

Following the OAuth Authorization Code Flow (Getting Tokens: OAuth | Twitch Developers), how long does the returned code last? If it never expires, can it be reused multiple times to get new access and refresh tokens for that user?

[Dist]

I’m not sure on the expiration of codes, but they are one time use so no they can’t be used to get new tokens and there’s no reason to store the code after use.

Also, once you’ve got a refresh token you can just use that to get a new pair of tokens whenever you need to.

[BehEh]

Short answer: No. This is what the refresh token is for. The authorization code is only valid for a short time and a single use, but with the refresh token you can get new access tokens whenever you need.

---

Long answer: While there is no guarantee that Twitch is doing it exactly this way, you can look at the OAuth 2 spec for what should be happening:

4.1.2.  Authorization Response
   [...]
   code
         REQUIRED.  The authorization code generated by the
         authorization server.  The authorization code MUST expire
         shortly after it is issued to mitigate the risk of leaks.  A
         maximum authorization code lifetime of 10 minutes is
         RECOMMENDED.  The client MUST NOT use the authorization code
         more than once.  If an authorization code is used more than
         once, the authorization server MUST deny the request and SHOULD
         revoke (when possible) all tokens previously issued based on
         that authorization code.  The authorization code is bound to
         the client identifier and redirection URI.

So, in a compliant implementation you can expect:

1. The code is no longer valid after a short time, such as 10 minutes
2. The code can only be used once, and using it a second time may lock down all tokens issued from that code

Thus, the authorization code can not be used to get more than one refresh token/access token pair. To refresh the access token you need to store and use the refresh token.

[Dist]

@BehEh

So, In a compliant implementation you should expect:

1. The code is no longer valid after 10 minutes
2. The code can only be used, and in fact using it a second time should lock down of all tokens issued from that code because it looks like it was compromised

For clarification, neither of the points you listed are required to be compliant. 10 min is just a recommendation, the requirement is it just has to be shortly after issuance. And the 2nd point about it locking down all tokens is also just a recommendation, and in Twitch’s case they do not follow this recommendation so is not relevant to this thread.

[BehEh]

@Dist

For clarification, neither of the points you listed are required to be compliant. 10 min is just a recommendation, the requirement is it just has to be shortly after issuance. And the 2nd point about it locking down all tokens is also just a recommendation, and in Twitch’s case they do not follow this recommendation so is not relevant to this thread.

We’re splitting hairs here. I merely was trying to give OP some background on how to gather these details for themselves whilst trying to give a simplified explanation. As I mentioned, there is no guarantee that Twitch does it exactly the way outlined in the spec.

Nonetheless I’ve updated my language in the previous post to be more accurate. If Twitch doesn’t do the second thing today they could still introduce it at a moment’s notice and your implementation should not depend on that behavior.

[Dist]

I just wanted to make sure no one stumbling across this topic misunderstood. As the OP had already been answered and your response was about OAuth spec and not explicitly Twitch’s implementation of it so could have left readers with the wrong info.

There are areas of the API where Twitch doesn’t follow the spec, so simply referencing it is not always helpful to the matter at hand.