Skip to content

Add Sentry JWT and OIDC Proposal #84

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

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

jjcollinge
Copy link

Signed-off-by: Jonathan Collinge [email protected]

Signed-off-by: Jonathan Collinge <[email protected]>
Signed-off-by: Jonathan Collinge <[email protected]>
Copy link
Contributor

@JoshVanL JoshVanL left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please can you add a bit about private key generation, I.e, sentry does it on first boot. If multiple sentry's boot at the same time, how is first write wins managed? Is it possible to have multiple public keys in the file path that are advertised to enable key rotation?

- `--jwks-filename` (string): JWKS (JSON Web Key Set) filename
- `--jwt-issuer` (string): Issuer value for JWT tokens (no issuer if empty)
- `--jwt-signing-algorithm` (string): Algorithm for JWT signing, must be supported by signing key
- `--jwt-key-id` (string): Key ID (kid) for JWT signing
Copy link
Contributor

@JoshVanL JoshVanL May 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What’s a key id/what does this mean/do?
Why isn't this managed/set by Sentry internally, rather than configured.

Copy link
Author

@jjcollinge jjcollinge May 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the kid of the signing key. It's in the token and used by clients to uniquely look up the key in the JWKS during validation. I'll use a base64 encoded SHA 256 thumbprint of the key as the default but a user must be able to set it in case they have generated their key/jwks using a different kid.

- `--jwt-key-id` (string): Key ID (kid) for JWT signing

**OIDC-related flags:**
- `--oidc-http-port` (int): Port for the OIDC HTTP server (disabled if 0)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please allow 0 as a valid port (random port provided by the operating system). Default should be unset (nil), meaning disabled.

**OIDC-related flags:**
- `--oidc-http-port` (int): Port for the OIDC HTTP server (disabled if 0)
- `--oidc-jwks-uri` (string): Custom URI for external JWKS access
- `--oidc-path-prefix` (string): Path prefix for all OIDC HTTP endpoints
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

“All”? Why is there more than one? If I understand this is for serving the oidc discovery endpoint?

Rather than prefix, please can we have explicit url path with sane well known defaults. Prefix style configuration is always confusing/finicky.

Copy link
Author

@jjcollinge jjcollinge May 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We currently serve the discovery and issuer JWKS endpoints. To be compliant we also have to advertise the authorize endpoint via the discovery doc even though it's not implemented. This is for routing - you need the discovery document endpoints to match the route you used to expose it. I'd rather keep this as path prefix as the combination of issuer and this allow for domain/path routing correctly.

- `--oidc-http-port` (int): Port for the OIDC HTTP server (disabled if 0)
- `--oidc-jwks-uri` (string): Custom URI for external JWKS access
- `--oidc-path-prefix` (string): Path prefix for all OIDC HTTP endpoints
- `--oidc-domains` (string slice): Allowed domains for OIDC HTTP endpoint requests
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does this do? Check the SNI headers for incoming well known http requests? 🤔

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TLS is terminated here, but because you're exposing an unauthenticated HTTP server this just allows you to restrict the hostname in the request to ensure the requests are coming via the expected route e.g. oidc.myissuer.net and not via some internal or alternative domain.

- `--jwt-enabled` (bool): Enable JWT token issuance by Sentry
- `--jwt-key-filename` (string): JWT signing key filename
- `--jwks-filename` (string): JWKS (JSON Web Key Set) filename
- `--jwt-issuer` (string): Issuer value for JWT tokens (no issuer if empty)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Surely this is always the Dapr control plane trust domain, and cannot be configured differently?

Copy link
Author

@jjcollinge jjcollinge May 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, this has to match the domain you are exposing your OIDC server on for federation. If third parties are going to oidc.mydomain.net then they expect that to be the issuer in the token. Dapr doesn't use these tokens internally so there's not really a use case where we can assume a value for this as a default but equally it's not necessarily required for all use cases so I've defaulted to omitted.

jjcollinge and others added 3 commits May 25, 2025 07:48
Co-authored-by: Josh van Leeuwen <[email protected]>
Signed-off-by: Joni Collinge <[email protected]>
Signed-off-by: Jonathan Collinge <[email protected]>
Signed-off-by: Jonathan Collinge <[email protected]>
@jjcollinge
Copy link
Author

Please can you add a bit about private key generation, I.e, sentry does it on first boot. If multiple sentry's boot at the same time, how is first write wins managed? Is it possible to have multiple public keys in the file path that are advertised to enable key rotation?

Added a bit on "Propose Key Management". I'm just extending the current Sentry mechanism when generating the keys - I don't see any leadership election etc. so I'm assuming we just accept LWW currently anyway?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants