Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Token Lifetime Recommendations #36

Open
marcvs opened this issue Oct 15, 2024 · 8 comments
Open

Token Lifetime Recommendations #36

marcvs opened this issue Oct 15, 2024 · 8 comments
Labels
AARC-G081 Guidelines for token lifetimes

Comments

@marcvs
Copy link

marcvs commented Oct 15, 2024

This issue was created with the document version "v1"

The current recommendation has:

Token Default Min Max
Opaque AT 24h
JWT AT (offline) 6h
JWT AT (online) 6h
OIDC RT (rotated) n times 90d
OIDC RT (not rot) 90d

Maybe this discussion needs to be taken in sub issues.

@marcvs
Copy link
Author

marcvs commented Oct 15, 2024

I think that "JWT AT (online)" should live longer than offline JWT, since they can be revoked. I suggest 24, so it's consistent with "Opaque AT"

@marcvs marcvs added the AARC-G081 Guidelines for token lifetimes label Oct 15, 2024
@msalle
Copy link

msalle commented Oct 15, 2024

I think that "JWT AT (online)" should live longer than offline JWT, since they can be revoked. I suggest 24, so it's consistent with "Opaque AT"

except that offline JWT might leak more information than online JWT, since the latter can be opaque.

@marcvs
Copy link
Author

marcvs commented Oct 15, 2024

I think that "JWT AT (online)" should live longer than offline JWT, since they can be revoked. I suggest 24, so it's consistent with "Opaque AT"

except that offline JWT might leak more information than online JWT, since the latter can be opaque.

Yes, but leakage is independent of life time, isn't it?

@msalle
Copy link

msalle commented Oct 15, 2024

I think that "JWT AT (online)" should live longer than offline JWT, since they can be revoked. I suggest 24, so it's consistent with "Opaque AT"

except that offline JWT might leak more information than online JWT, since the latter can be opaque.

Yes, but leakage is independent of life time, isn't it?

I'd say it's an increased risk (more chance of exposure), and therefore could be mitigated with shorter lifetimes?

@zachmann
Copy link
Member

I think that "JWT AT (online)" should live longer than offline JWT, since they can be revoked. I suggest 24, so it's consistent with "Opaque AT"

except that offline JWT might leak more information than online JWT, since the latter can be opaque.

offline JWT is still a JWT and therefore, by definition not opaque.
There is another entry for opaque (which are by definition online)

@msalle
Copy link

msalle commented Oct 15, 2024

I think that "JWT AT (online)" should live longer than offline JWT, since they can be revoked. I suggest 24, so it's consistent with "Opaque AT"

except that offline JWT might leak more information than online JWT, since the latter can be opaque.

offline JWT is still a JWT and therefore, by definition not opaque. There is another entry for opaque (which are by definition online)

ah good point, I messed up what I wanted to write: the comparison was with the opaque AT: online opaque AT has lower risk than online JWT, while online JWT is revocable and offline not. So online JWT as such should probably be between those two, i.e. between 6 and 24 hours.

@skanct
Copy link
Contributor

skanct commented Oct 17, 2024

Hello everyone, I have a few concerns regarding the way the table is split:

  • I am not sure I agree that the main differentiator between an opaque token and a JWT is that the latter contains user information, thus exposing more data if it leaks, and that this has any connection to the token’s lifetime. A token can still be leaked even if it has expired. The key difference, however, is that a JWT can be validated offline by a Resource Provider (RP), meaning that from the moment it is issued, the issuer has limited (or no) practical ability to revoke it. On the other hand, an opaque token cannot be validated offline, so the RP must always rely on the Authorization Server (AS) that issued the token for up-to-date authorization information.

  • I think the distinction between JWTs with online validation and JWTs with offline validation does not make sense. How can the AS that issued the token determine how the JWT will be used? It is up to the RP to decide whether it will perform online or offline validation. What I see as a more meaningful differentiator is whether the JWT includes authorization information. If it contains authorization data, it may support both offline and online validation. However, if it does not include any authorization information, the RP must perform online validation to authorize the request. In that case, I am unsure why anyone would use a JWT over an opaque token, but that is a separate discussion.

  • Regarding the rotated Refresh Token (RT), it is unclear from the table whether it means “n” rotations within 90 days, or “n” rotations, each with a 90-day lifetime.

@marcvs
Copy link
Author

marcvs commented Oct 17, 2024

I fully agree with your points on opaque vs jwt. Essentially jwts can not be revoced, because their signature allows verifying them offline.

Leaking personal data adds a different angle to things:

  • Valid jwts will leak more data than valid opaques
  • Valid jwts will leak access to about the same data as valid opaques
  • Expired jwts will leak less data than any valid token

How does this influence our guidance on lifetimes in practice?

I'm tempted to say it does not. Since the lifetime says nothing about when
a jwt may be leaked and data might be exposed.

In addition I would claim that since all parties are bound to Sirtfi, plus
since we're not dealing with sensitive data (dob, religion, address) we
are not at all on risky grounds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
AARC-G081 Guidelines for token lifetimes
Projects
None yet
Development

No branches or pull requests

4 participants