Add Support For JWT-Secured Authorization Requests in OIDC Connector by rhammonds-teleport · Pull Request #56990 · gravitational/teleport

rhammonds-teleport · 2025-07-21T16:28:08Z

Add new configuration parameter to OIDC Connector request_object_mode which forces the connector to use JWT-Secured Authorization Requests (RFC 9101) when invoking the IdP's authorization endpoint.

Changelog: Add support for JWT-Secured Authorization Requests to OIDC Connector

zmb3 · 2025-07-21T17:14:53Z

 	// match for identifier-first login.
 	GetUserMatchers() []string
+	// GetEnableRequestObjects returns true if the connector should use JWT-Secured Authorization Requests when making auth requests
+	GetEnableRequestObjects() bool


Instead of a bool, should we have a "mode" like we did for PKCEMode? This might make it easier for us to change defaults or support more than 2 options in the future. (For example, maybe the options are never, always, and auto-detect)

Not a bad idea. Maybe we should also account for the possibility that we'll want to support "pass by reference" (request_uri) later on as well.

+1, In the future I could imagine supporting at least the following:

signed

signed_pushed (request_uri)

encrypted (also signed by definition)

encrypted_pushed

I've replaced EnableRequestObjects with RequestObjectMode and added associated constants. For now, we support none and signed, but could certainly add more (auto, encrypted, etc) as needed.

The default behavior is that of none (do not use request objects).

@zmb3 you recommended following string PKCEMode as an example, but should we use a proto enum here, with the same custom marshaling logic used for RequireMFAType, SecondFactorType, etc? Or are we trying to move away from this pattern?

My first thought was to use an enum as well. Though, I noticed that we have a lot of existing enums defined like so:

enum MySetting { OFF = 0; ON = 1; } // Will conflict with: enum OtherSetting { OFF = 0; ON = 1; }

Which causes conflicts in generated C++ code. Buf normally complains about this during linting but maybe we have it disabled. I would've had to get somewhat verbose with my enum values in order to achieve decent namespacing, so I opted to follow suit with PKCEMode.

Still, I'm open to changing it. Maybe there are good arguments for instead using enums that I'm missing.

@zmb3 you recommended following string PKCEMode as an example, but should we use a proto enum here, with the same custom marshaling logic used for RequireMFAType, SecondFactorType, etc? Or are we trying to move away from this pattern?

Sure, if we can get the marshalling correct then a proto enum is probably the most semantically correct.

We often fail to get the marshalling correct though, which results in hard-to-interpret configuration and audit events (they show up as integers instead of strings).

Does the custom marshaling route allow users to specify "signed" instead of 2 if they are managing the connector via the terraform provider? If not, then I would suggest proceeding with a string as that's a major pain point for any terraform users.

Ah you're right Tim, we should move away from the enum+custom marshaling approach for the terraform provider and other external consumers of the protobuf spec.

zmb3 · 2025-07-21T17:15:44Z

 	return k.verify(token, expectedClaims)
 }
+
+// SignArbitrary creates a signed JWT with an arbitrary claims set


Suggested change

// SignArbitrary creates a signed JWT with an arbitrary claims set

// SignAny creates a signed JWT with an arbitrary claims set

zmb3 · 2025-07-21T17:16:31Z

+	var kid string
+	var err error
+	if kid, err = KeyID(k.config.PublicKey); err != nil {


Suggested change

var kid string

var err error

if kid, err = KeyID(k.config.PublicKey); err != nil {

kid, err := KeyID(k.config.PublicKey)

if err != nil {

This is probably personal preference, but I think the suggestion here better fits with the Teleport-style.

nklaassen · 2025-07-21T17:35:20Z

+// SignArbitrary creates a signed JWT with an arbitrary claims set
+func (k *Key) SignAny(claims map[string]any) (string, error) {


comment is SignArbitrary, signature is SignAny

But, is there any minimal set of claims that we can make sure are set before signing a JWT? Does it not need at least an issuer and audience or something like that? If so do you think it would be appropriate to have a SignOAuthRequestObject and VerifyOAuthRequestObject method instead of SignAny/ValidateAny? That seems to be what we've done for other types of JWTs

issuer and audience aren't strictly required per RFC 9101, but you're right that there are a handful of required parameters for authorization requests that should always be included in the JAR object.

I think I can take inspiration from SignParamsJWTSVID which has a PrivateClaims field that can be used to include additional (optional?) claims.

I've removed SignAny/ValidateAny methods and replaced them with more opinionated SignOIDCAuthRequest/VerifyOIDCAuthRequestToken alternatives. Hopefully these are less likely to be abused/misused. Open to discussing this further if I've missed the mark or if you have any other concerns.

I do feel a bit like I've pushed more OIDC/OAuth domain logic into this package than I would have liked, but I suppose it's just a bit of validation around required claims/parameters.

from RFC 9101

If signed, the Authorization Request Object SHOULD contain the Claims iss (issuer) and aud (audience) as members with their semantics being the same as defined in the JWT [RFC7519] specification. The value of aud should be the value of the authorization server (AS) issuer, as defined in RFC 8414 [RFC8414].

I guess it's only a SHOULD but since we are the ones issuing these we should probably go ahead and include those

I do feel a bit like I've pushed more OIDC/OAuth domain logic into this package than I would have liked

I'm aware of this guidance from the RFC, and I was on the fence about whether or not to include these claims. Typically I would say that OIDC client implementation itself is in a better position to make this decision rather than this package. Consider the off chance that we encounter a fussy IdP that dislikes these claims for whatever reason... but that's pretty unlikely. I'll go ahead and add them.

Added more standard claims (including audience and issuer) in the companion PR.

smallinsky

Add new configuration parameter to OIDC Connector enable_request_objects which forces the connector to use JWT-Secured Authorization Requests (RFC 9101) when invoking the IdP's authorization endpoint.

What CA will be used to sign the JWT token on Teleport OIDC Relying Party side ?

smallinsky · 2025-07-21T17:47:46Z

+
+	var alg jose.SignatureAlgorithm
+	if alg, err = AlgorithmForPublicKey(k.config.PublicKey); err != nil {
+		return "", err


Suggested change

return "", err

return "", trace.Wrap(err)

smallinsky · 2025-07-21T17:56:13Z

+	}
+
+	return k.sign(claims, &jose.SignerOptions{
+		ExtraHeaders: map[jose.HeaderKey]interface{}{


Suggested change

ExtraHeaders: map[jose.HeaderKey]interface{}{

ExtraHeaders: map[jose.HeaderKey]any{

smallinsky · 2025-07-21T17:56:38Z

+	var kid string
+	var err error
+	if kid, err = KeyID(k.config.PublicKey); err != nil {
+		return "", err


Suggested change

return "", err

return "", trace.Wrap(err)

smallinsky · 2025-07-21T17:58:08Z

+func (k *Key) validate(rawToken string) (map[string]any, error) {
+	tok, err := jwt.ParseSigned(rawToken)
+	if err != nil {
+		return nil, trace.Errorf("failed to parse jwt")


Suggested change

return nil, trace.Errorf("failed to parse jwt")

return nil, trace.Errorf("failed to parse JWT")

smallinsky · 2025-07-21T18:11:21Z

+
+	return k.sign(claims, &jose.SignerOptions{
+		ExtraHeaders: map[jose.HeaderKey]interface{}{
+			"alg": alg,


Does manual setting "alg" in the header is needed ? I thought that this is done by jose library internals.

rhammonds-teleport · 2025-07-22T17:22:38Z

Add new configuration parameter to OIDC Connector enable_request_objects which forces the connector to use JWT-Secured Authorization Requests (RFC 9101) when invoking the IdP's authorization endpoint.

What CA will be used to sign the JWT token on Teleport OIDC Relying Party side ?

The plan is to use the JWT CA for signing these request objects. We expect that the provider can be configured to retrieve public keys from our well-known JWKS endpoint.

smallinsky · 2025-07-22T19:29:27Z

Add new configuration parameter to OIDC Connector enable_request_objects which forces the connector to use JWT-Secured Authorization Requests (RFC 9101) when invoking the IdP's authorization endpoint.

What CA will be used to sign the JWT token on Teleport OIDC Relying Party side ?

The plan is to use the JWT CA for signing these request objects. We expect that the provider can be configured to retrieve public keys from our well-known JWKS endpoint.

The types.JWTSigner right now is exclusively used only for Teleport Application access. The question is do we want to break OIDC SSO logic if the Application CA is rotated ?
For the public proxy where the OIDC SP auto fetches the JWKs from <proxy>/.well-known/jwks.json that might be a self healing issue. But for private cluster where JWKS export is used after Telepot APP CA rotation users will lost the access to teleport cluster.

rhammonds-teleport · 2025-07-23T14:15:07Z

Add new configuration parameter to OIDC Connector enable_request_objects which forces the connector to use JWT-Secured Authorization Requests (RFC 9101) when invoking the IdP's authorization endpoint.

What CA will be used to sign the JWT token on Teleport OIDC Relying Party side ?

The plan is to use the JWT CA for signing these request objects. We expect that the provider can be configured to retrieve public keys from our well-known JWKS endpoint.

The types.JWTSigner right now is exclusively used only for Teleport Application access. The question is do we want to break OIDC SSO logic if the Application CA is rotated ? For the public proxy where the OIDC SP auto fetches the JWKs from <proxy>/.well-known/jwks.json that might be a self healing issue. But for private cluster where JWKS export is used after Telepot APP CA rotation users will lost the access to teleport cluster.

Would you suggest adding a new CA specifically for this purpose then? It might be a little more apparent to administrators the ramifications of rotating their "OIDC" key.

edit: I just noticed that we have an oidc_idp CA already. Maybe that's more appropriate though it isn't advertised in our JWKS endpoint.

github-actions · 2025-07-24T15:31:08Z

Amplify deployment status

Branch	Commit	Job ID	Status	Preview	Updated (UTC)
rhammonds/signed-oauth	`1c36ad6`	4	✅SUCCEED	rhammonds-signed-oauth	2025-08-08 18:18:09

nklaassen · 2025-07-24T18:00:42Z

 }
+
+// OIDCAuthRequestClaims defines the required parameters for a JWT-Secured Authorization Request object.
+type OIDCAuthRequestClaims struct {


do you think we should embed jwt.Claims like other custom claims types do to include some standard JWT claims? I'm pretty sure we should be including at least an issuer, audience, and expiry

It seems that my use case doesn't really match up with the intended purpose of this package, so I've removed my additions. There's at least one other package, boundkeypair, that handles JWT signing/serialization itself when it dealing with custom claims, so I'll follow this pattern in the OIDC implementation.

nklaassen · 2025-07-24T18:05:01Z

+// VerifyOIDCAuthRequestToken parses and validates a JWT that is to be interpreted as
+// a JWT-Secured Authorization Request (JAR) object.
+func (k *Key) VerifyOIDCAuthRequestToken(rawToken string) (OIDCAuthRequestClaims, error) {
+	claims, err := k.verifyOnly(rawToken)
+	if err != nil {
+		return OIDCAuthRequestClaims{}, trace.Wrap(err, "error verifying authorization request object signature")
+	}
+
+	request, err := oidcAuthRequestFromClaims(claims)
+	if err != nil {
+		return OIDCAuthRequestClaims{}, trace.Wrap(err, "error validating authorization request object parameters")
+	}
+
+	return request, nil
+}


if this is only used in the test maybe we should define it only in the test file rather than exporting it. Otherwise I think it should be checking the standard JWT claims like expiry, issuedAt, subject, audience, etc.

…nnector to enable the use of JWT-Secured Authorization Requests * Include key id and algorithm in JWT header when signing JARs

* Add a simple 'Validate' function to jwt.Key object allowing users to simply validate a signature and retrieve claims (registered and unregistered)

* Remove inconsistent go-jose/jwt/v5 dependency * Use consistent map type for input/output of 'SignAny' and 'ValidateAny' methods

…ionated OIDC SignOIDCAuthRequestToken and VerifyOIDCAuthRequestToken alternatives

…string 'RequestObjectMode' which gives us more flexibility to support additional request object settings in the future.

… OIDC Auth Request related JWT methods.

…ast 'audience' and 'issuer' claims are set, and perform validation of claims during parsing/verification. * Implement json.Marshaler and json.Unmarshaler interfaces on 'OIDCAuthRequestClaims' so that it can passed to go-jose utilities without pre/post transformation steps.`

…56990) * POC make signer usable with jwt signing. * Add SignOAuthRequest method. * Update TODO; Add e ref. * * Add new configuration parameter 'enable_request_objects' to oidc connector to enable the use of JWT-Secured Authorization Requests * Include key id and algorithm in JWT header when signing JARs * * Add setter for enabling/disabling JARs on an oidc connector * Add a simple 'Validate' function to jwt.Key object allowing users to simply validate a signature and retrieve claims (registered and unregistered) * Add comment on OIDCConnectorV3 setter * * Rename 'SignOauthRequest' method to more generic 'SignAny' * Remove inconsistent go-jose/jwt/v5 dependency * Use consistent map type for input/output of 'SignAny' and 'ValidateAny' methods * Remove generic JWT signing/verification methods and replace with opinionated OIDC SignOIDCAuthRequestToken and VerifyOIDCAuthRequestToken alternatives * Replace 'EnableRequestObjects' setting on OIDCConnectorSpecV3 with a string 'RequestObjectMode' which gives us more flexibility to support additional request object settings in the future. * Clean up tests, fix formatting, and pick (hopefully) better names for OIDC Auth Request related JWT methods. * Periods at end of godoc comments * Regenerate configuration docs/examples * * Embed jwt.Claims within 'OIDCAuthRequestClaims', require that at least 'audience' and 'issuer' claims are set, and perform validation of claims during parsing/verification. * Implement json.Marshaler and json.Unmarshaler interfaces on 'OIDCAuthRequestClaims' so that it can passed to go-jose utilities without pre/post transformation steps.` * Remove OIDC Auth Request utilities from 'lib/jwt' package. * Regenerate terraform docs --------- Co-authored-by: joerger <bjoerger@goteleport.com>

…ector (#58063) * Add Support For JWT-Secured Authorization Requests in OIDC Connector (#56990) * POC make signer usable with jwt signing. * Add SignOAuthRequest method. * Update TODO; Add e ref. * * Add new configuration parameter 'enable_request_objects' to oidc connector to enable the use of JWT-Secured Authorization Requests * Include key id and algorithm in JWT header when signing JARs * * Add setter for enabling/disabling JARs on an oidc connector * Add a simple 'Validate' function to jwt.Key object allowing users to simply validate a signature and retrieve claims (registered and unregistered) * Add comment on OIDCConnectorV3 setter * * Rename 'SignOauthRequest' method to more generic 'SignAny' * Remove inconsistent go-jose/jwt/v5 dependency * Use consistent map type for input/output of 'SignAny' and 'ValidateAny' methods * Remove generic JWT signing/verification methods and replace with opinionated OIDC SignOIDCAuthRequestToken and VerifyOIDCAuthRequestToken alternatives * Replace 'EnableRequestObjects' setting on OIDCConnectorSpecV3 with a string 'RequestObjectMode' which gives us more flexibility to support additional request object settings in the future. * Clean up tests, fix formatting, and pick (hopefully) better names for OIDC Auth Request related JWT methods. * Periods at end of godoc comments * Regenerate configuration docs/examples * * Embed jwt.Claims within 'OIDCAuthRequestClaims', require that at least 'audience' and 'issuer' claims are set, and perform validation of claims during parsing/verification. * Implement json.Marshaler and json.Unmarshaler interfaces on 'OIDCAuthRequestClaims' so that it can passed to go-jose utilities without pre/post transformation steps.` * Remove OIDC Auth Request utilities from 'lib/jwt' package. * Regenerate terraform docs --------- Co-authored-by: joerger <bjoerger@goteleport.com> * Allow OIDC Connector to Omit 'max_age' Parameter From Auth Requests (#57950) * Check for 'TELEPORT_OIDC_OMIT_MFA_MAX_AGE' environment variable when adding MFA settings to OIDC connector config. This option allows users to configure teleport to omit the 'max_age' parameter from authorization requests to the IdP in rare cases where this behavior is necessary. * More robust parsing of 'TELEPORT_OIDC_OMIT_MFA_MAX_AGE' value * Need to explicitly set 'MaxAge' to nil when 'TELEPORT_OIDC_OMIT_MFA_MAX_AGE' is enabled, otherwise the base connector's 'MaxAge' setting will persist. --------- Co-authored-by: joerger <bjoerger@goteleport.com>

rhammonds-teleport requested review from Joerger, timothyb89 and zmb3 July 21, 2025 16:28

rhammonds-teleport added the size/sm label Jul 21, 2025

github-actions bot requested review from bl-nero and nklaassen July 21, 2025 16:28

zmb3 reviewed Jul 21, 2025

View reviewed changes

nklaassen reviewed Jul 21, 2025

View reviewed changes

smallinsky reviewed Jul 21, 2025

View reviewed changes

rhammonds-teleport force-pushed the rhammonds/signed-oauth branch 2 times, most recently from 8eda678 to 35c690d Compare July 22, 2025 17:01

rhammonds-teleport temporarily deployed to docs-amplify July 24, 2025 15:30 — with GitHub Actions Inactive

nklaassen reviewed Jul 24, 2025

View reviewed changes

rhammonds-teleport temporarily deployed to docs-amplify July 28, 2025 14:04 — with GitHub Actions Inactive

rhammonds-teleport mentioned this pull request Jul 31, 2025

Docs: Document OIDC Setting Enabling Signed Request Objects #57383

Merged

rhammonds-teleport force-pushed the rhammonds/signed-oauth branch from 1f94f7e to 77b2b18 Compare August 4, 2025 15:21

rhammonds-teleport temporarily deployed to docs-amplify August 4, 2025 15:22 — with GitHub Actions Inactive

Joerger and others added 9 commits August 8, 2025 13:57

POC make signer usable with jwt signing.

2591418

Add SignOAuthRequest method.

d793a65

Update TODO; Add e ref.

cdbc6b0

* Add new configuration parameter 'enable_request_objects' to oidc co…

5b31f3c

…nnector to enable the use of JWT-Secured Authorization Requests * Include key id and algorithm in JWT header when signing JARs

* Add setter for enabling/disabling JARs on an oidc connector

558537d

* Add a simple 'Validate' function to jwt.Key object allowing users to simply validate a signature and retrieve claims (registered and unregistered)

Add comment on OIDCConnectorV3 setter

422cd85

* Rename 'SignOauthRequest' method to more generic 'SignAny'

f7cbdcb

* Remove inconsistent go-jose/jwt/v5 dependency * Use consistent map type for input/output of 'SignAny' and 'ValidateAny' methods

Remove generic JWT signing/verification methods and replace with opin…

172fe2b

…ionated OIDC SignOIDCAuthRequestToken and VerifyOIDCAuthRequestToken alternatives

Replace 'EnableRequestObjects' setting on OIDCConnectorSpecV3 with a …

74f3e3a

…string 'RequestObjectMode' which gives us more flexibility to support additional request object settings in the future.

rhammonds-teleport added 6 commits August 8, 2025 14:04

Clean up tests, fix formatting, and pick (hopefully) better names for…

c8a44e4

… OIDC Auth Request related JWT methods.

Periods at end of godoc comments

43902c7

Regenerate configuration docs/examples

9d25801

Remove OIDC Auth Request utilities from 'lib/jwt' package.

d27a841

Regenerate terraform docs

1c36ad6

rhammonds-teleport force-pushed the rhammonds/signed-oauth branch from 77b2b18 to 1c36ad6 Compare August 8, 2025 18:10

rhammonds-teleport temporarily deployed to docs-amplify August 8, 2025 18:10 — with GitHub Actions Inactive

rhammonds-teleport requested review from nklaassen and zmb3 August 11, 2025 14:08

Joerger approved these changes Aug 13, 2025

View reviewed changes

zmb3 approved these changes Aug 13, 2025

View reviewed changes

public-teleport-github-review-bot bot removed request for bl-nero and timothyb89 August 13, 2025 01:55

rhammonds-teleport added this pull request to the merge queue Aug 13, 2025

Merged via the queue into master with commit 3df242d Aug 13, 2025
44 checks passed

rhammonds-teleport deleted the rhammonds/signed-oauth branch August 13, 2025 02:24

rhammonds-teleport mentioned this pull request Aug 18, 2025

[v17] Add Support For JWT-Secured Authorization Requests in OIDC Connector #58013

Merged

rhammonds-teleport mentioned this pull request Aug 19, 2025

[v18] Add Support For JWT-Secured Authorization Requests in OIDC Connector #58063

Merged

rhammonds-teleport mentioned this pull request Aug 20, 2025

OIDC: Enable Separate 'Request Object Mode' For MFA Flow #58177

Merged

	// SignArbitrary creates a signed JWT with an arbitrary claims set
	// SignAny creates a signed JWT with an arbitrary claims set

		// SignArbitrary creates a signed JWT with an arbitrary claims set
		func (k *Key) SignAny(claims map[string]any) (string, error) {

	ExtraHeaders: map[jose.HeaderKey]interface{}{
	ExtraHeaders: map[jose.HeaderKey]any{

	return nil, trace.Errorf("failed to parse jwt")
	return nil, trace.Errorf("failed to parse JWT")

Conversation

rhammonds-teleport commented Jul 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

smallinsky left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rhammonds-teleport commented Jul 22, 2025

Uh oh!

smallinsky commented Jul 22, 2025

Uh oh!

rhammonds-teleport commented Jul 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Jul 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

rhammonds-teleport commented Jul 21, 2025 •

edited

Loading

smallinsky left a comment •

edited

Loading

rhammonds-teleport commented Jul 23, 2025 •

edited

Loading

github-actions bot commented Jul 24, 2025 •

edited

Loading