Encrypted JWTs for both id_tokens and client assertions

[vivshankar]

Is your feature request related to a problem? Please describe.

ID tokens and client assertions (both for JWT bearer grant flow and for private_key_jwt authentication) are generally signed and optionally encrypted. In general, an encrypted token requirement comes up in industries like government or finance.

Describe the solution you'd like

The request is to add this capability by default in Fosite with an extension, effectively, to the JWTStrategy.

Describe alternatives you've considered

1. Add a handler in the provider after the id_token is generated that encrypts as configured on the client/provider config.
2. Implement a client_authentication strategy that also caters for encrypted JWTs

Additional context

N/A

[vivshankar]

@aeneasr For the ID token etc., this is relatively easy to accomplish with a custom implementation of JWTStrategy and performing the encryption on the Generate function. Perhaps a couple of client properties should be made available such as the algorithms to be used. I would just match it to the client_metadata properties in the DCR spec.

However, for inbound (client_assertion, request_object etc.), a new Decrypt function would be necessary in the JWTStrategy or a new EncryptedJWTStrategy. Again, the client properties should ideally match the DCR spec.

This should be a relatively simple extension with a simple example. Please let me know if this makes sense.

[aeneasr]

Sorry for the late reply, that sounds like a good approach!

[vivshankar]

@aeneasr This is regarding a change I see in the master branch.

type Signer interface {
	Generate(ctx context.Context, claims MapClaims, header Mapper) (string, string, error)
	Validate(ctx context.Context, token string) (string, error)
	Hash(ctx context.Context, in []byte) ([]byte, error)
	Decode(ctx context.Context, token string) (*Token, error)
	GetSignature(ctx context.Context, token string) (string, error)
	GetSigningMethodLength(ctx context.Context) int
}

It looks like it is just a name change from JWTStrategy to Signer. I am curious about the thought process behind this and changes that might have been proposed/are being made.

[aeneasr]

Primarily because it is only used to sign tokens currently, but we can also name it something else

[github-actions]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas on how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️