clarifications arount Token Request #57
Conversation
| @@ -297,6 +297,13 @@ The following rules must be enforced by the AS when receiving a token request. | |||
| - Ensure that the client authentication method is the same as the one used during PAR (if `client_assertion` was used during PAR, the same authentication method **must** be used, with a JWT containing a distinct `jti` claim, but signed by the same key) | |||
| - DPoP proof and client assertion **must** be signed using a different keypair. | |||
| - The Token Response from the AS **must** contain a `sub` claim, which must be the end-user's ATPROTO identifier (`did:plc:123`) | |||
| - The validity of the access token **must** be limited to a short period of time (typically 1-5 minutes). The access token validity **must not** exceed 1 hour. | |||
There was a problem hiding this comment.
I'd be a bit more generous and say "5 to 15 minutes".
@devinivy what are the current access token limits in prod with the legacy auth system?
There was a problem hiding this comment.
It seems to be either 15s (for "short" session) or 2min.
There was a problem hiding this comment.
I believe it's 2hr, not 2min. Some of these defaults are informed by common defaults that are actually used, e.g. by services such as Auth0.
| - Any issued token (both access and refresh) **must** be bound to the `client_id` _and_ the public key used to authenticate the client during the token request. | ||
| - If, during a refresh, a confidential client no longer advertises (through its metadata document's jwks) the key bound to the refresh token being used, the Authorization Server **must** reject the request and invalidate any existing tokens bound to that key. | ||
| - Refresh tokens issued to _public_ clients **must** expire after a short period of time (e.g. 24 hours) or expire if they are not used in some amount of time (e.g. 2 hours). The validity of the refresh token issued to _public_ clients **must not** exceed 1 week. | ||
| - Refresh tokens issued to _confidential_ clients **should** be valid for a longer period (e.g. 6 month). They **must not** be allowed to remain indefinitely valid. The lifetime for refresh tokens **must not** exceed 5 year. The Authorization Server **can** use information it has about the client (e.g. First party, pre-approved, etc.) to determine the lifetime of the refresh token. |
There was a problem hiding this comment.
From a UX perspective, i'm tempted to say "longer than a year should mean forever" or something like that. Having to re-login for something periodically with a period of more than a year is kind of a painful experience? I feel like it often just breaks things. And it would be kind of nice if there was a natural rotation cycle for tokens of a year; eg if we wanted to deprecate how refresh tokens are structured or something like that.
Not sure I have really good specific numbers to counter-propose though, will need to think about it some more.
There was a problem hiding this comment.
Authenticated clients should rotate their keys on a regular basis (e.g. on every new app release, or every month, whichever comes first).
If the general guidance is that client keys are rotated once a month, then it seems reasonable to limit any other token or code to a 30 day expiration as well.
No description provided.