Open j3parker opened 2 years ago
We don't error on this but it might be worth doing something similar to https://github.com/Brightspace/oauth2/issues/2487 i.e. rejecting keys where the exp value is "clearly" in milliseconds. This could help e2e with LTI integrations where the integration is first being built against D2L. An exp value in milliseconds will mistakenly be treated as expiring in thousands of years but it would be reasonable to set an upper bound and reject the key, with that hint if it looks like milliseconds.
We have a single error message for failures to look up a remote key. Something like: "remote key xyz at URL abc could not be found". This covers the following problems if I remember correctly:
That last one burned us recently: a customer's key expired/wasn't rotated in time, and this lead to an outage for them. We worked from the bottom-up to diagnose this because we didn't notice that the
exp
timestamp on their key was old, and this delayed resolving the issue. If we had a more informative error message we could have resolved this much quicker.