-
Notifications
You must be signed in to change notification settings - Fork 16
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
Adding 'iat' (issued at) claim to tokens #342
Conversation
Just need to get the CI setup on this repo updated. Will get that done before lunch. |
Hm, I thought we had iat but we have nbf and exp. I wonder if we could just get by with those? (probably just nbf?) |
We could get by with nbf (it would have made my life a bit easier) but nbf doesn't strictly need to match iat, we're just making it "now" by convention, so at this point we figured we'd keep going and add it. 🤷♀️ My core work on Lms is already testing well against nbf. |
Given the semantic difference, I preferred adding the proper claim. @joshhoey could you rebase to get the CI changes. |
Co-authored-by: Owen Smith <[email protected]>
Co-authored-by: Owen Smith <[email protected]>
6bda85a
to
255c94b
Compare
We can also just use one if it exists and if not the other. iat isn't a required claim. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need more claims
I don't think it being required or not is a particularly compelling reason not to use it. nbf and exp are also optional claims, but we of course use them due to the semantics of what they imply (and require of client libraries). We do not currently have any usage of nbf being set to a future date, and I don't think it's terribly likely that we would end up wanting to either. However I'm not sure how to assert that we never do so such that the general-we would catch the change down the line. I was definitely iffy about adding extra bytes to the tokens, but the semantic of iat is exactly what we're looking for, so suggested it as being more appropriate despite that. Can you think of a way to future-proof ourselves against future mistakes re nbf being adjusted away from time-of-issue, and thus failing to revoke those tokens? |
var threshold = token.IssuedAt ?? token.NotBefore; is what I meant by "we can also just use one if it exists and if not the other". |
I would also not be opposed to |
Adding
iat
(Issued At) as a claim (same asnbf
for now, but it means something different)