Story #17718

Standalone JWT token support for OIDC

Added by Peter Amstutz 4 months ago. Updated 3 months ago.

Status:
New
Priority:
Normal
Assigned To:
-
Category:
Login
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Story points:
-

Description

When we receive a JWT token, we should verify the signature and check the expiration time. This should make it possible in at least some cases to accept JWT tokens without going to the upstream provider.

History

#1 Updated by Peter Amstutz 4 months ago

  • Description updated (diff)

#3 Updated by Peter Amstutz 4 months ago

  • Target version changed from 2021-07-07 sprint to 2021-06-23 sprint

#4 Updated by Tom Clegg 4 months ago

The introspection endpoint is an OAuth 2.0 extension. OAuth 2.0 likes to leave lots of possibilities open. https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-endpoint-auth-method lists 6 different auth methods (plus "none") that the provider might accept at the token introspection endpoint. We might want to choose a subset to support (e.g., whatever would make this work on pingfederate). The provider metadata has a standard place to advertise the introspection endpoint though, so at least we should be able to determine reliably whether introspection is supported.

Access tokens are opaque according to spec, so for example there seems to be nowhere for the provider to advertise which signing algorithms should be accepted. (This is one reason I didn't try to validate tokens independently in #17704.) For serverless validation we'll need to be careful about offering enough flexibility to make it useful, without making it too easy to unwittingly create gaping security holes. Although validating without a callback seems desirable, I'm not especially keen on this feature unless there's a standard for it somewhere. Using the introspection endpoint, and propagating the expiry time it returns, seems like a more standards-compliant way to reduce provider callbacks.

Using "sub" to identify users would certainly be more OIDC-appropriate than using "email". AFAIK the only reason we haven't done this yet is that we have needed to handle a migration between Google and non-Google providers (same email, different sub) but we haven't yet needed to handle the case where the OIDC provider changes users' email addresses underneath us. Unlike the other 2 points, this also affects the normal login process.

#5 Updated by Peter Amstutz 3 months ago

  • Description updated (diff)

#6 Updated by Peter Amstutz 3 months ago

  • Subject changed from Standalone JWT token support for OIDC, support token introspection, support "sub" claim to Standalone JWT token support for OIDC, support token introspection

#7 Updated by Peter Amstutz 3 months ago

  • Description updated (diff)

#8 Updated by Peter Amstutz 3 months ago

  • Subject changed from Standalone JWT token support for OIDC, support token introspection to Standalone JWT token support for OIDC

#9 Updated by Peter Amstutz 3 months ago

  • Target version deleted (2021-06-23 sprint)

Also available in: Atom PDF