-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
feat: add jwks access type to external token handler #24681
feat: add jwks access type to external token handler #24681
Conversation
Signed-off-by: Ryan Hanchett <ryan.hanchett@invitae.com>
Signed-off-by: Ryan Hanchett <ryan.hanchett@invitae.com>
Signed-off-by: Ryan Hanchett <ryan.hanchett@invitae.com>
Signed-off-by: Ryan Hanchett <ryan.hanchett@invitae.com>
Signed-off-by: Ryan Hanchett <ryan.hanchett@invitae.com>
Changed Packages
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! 🎉
Couple of early thoughts
packages/backend-app-api/src/services/implementations/auth/external/jwks.ts
Outdated
Show resolved
Hide resolved
packages/backend-app-api/src/services/implementations/auth/external/jwks.ts
Outdated
Show resolved
Hide resolved
packages/backend-app-api/src/services/implementations/auth/external/jwks.ts
Outdated
Show resolved
Hide resolved
packages/backend-app-api/src/services/implementations/auth/external/jwks.ts
Outdated
Show resolved
Hide resolved
packages/backend-app-api/src/services/implementations/auth/external/jwks.ts
Outdated
Show resolved
Hide resolved
packages/backend-app-api/src/services/implementations/auth/external/jwks.ts
Outdated
Show resolved
Hide resolved
@Rugvip a thought about naming/targeting - should it be
That's sort of the actual use case being targeted right? Feels like an end user would appreciate the framing of that, and knowing how to ask for and insert the common auth server url rather than the more technical implementation dependant JWKS? |
@freben hmm, JWKS endpoints are used for more than just OIDC. I'm thinking that we consider that as an addition, but as a base feature set I think the existing structure makes sense? |
Signed-off-by: Ryan Hanchett <ryan.hanchett@invitae.com>
…config Signed-off-by: Ryan Hanchett <ryan.hanchett@invitae.com>
Signed-off-by: Ryan Hanchett <ryan.hanchett@invitae.com>
Signed-off-by: Ryan Hanchett <ryan.hanchett@invitae.com>
@freben I like the idea of calculating the jwks endpoint based on the openid-configuration. Perhaps we could add an additional config where users could provide the base server or the direct JWKS url, or we could add an additional token handler so we have both Happy to do that as a follow-up PR or to make the changes here, whatever makes the most sense. |
Yep so if the given url doesn't contain ".well-known", do A, otherwise do B. There's possibilities for future smarts as additions to the basic feature as followups |
Prolly need to be a bit more explicit though, JWKS endpoints don't always contain |
Alright, makes sense then to keep this one explicit, thanks! |
Any other changes/improvements ya'll want me to make on this existing PR? |
Was the |
It was, yes, we've just been busy. |
Understood, no worries! Thanks for getting back to me so quickly! |
const issuers = options.getOptionalStringArray('issuers'); | ||
const audiences = options.getOptionalStringArray('audiences'); | ||
const subjectPrefix = options.getOptionalString('subjectPrefix'); | ||
const url = new URL(options.getString('url')); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add all of this to the config.d.ts file in this package? It's important to keep the config schema in check :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I always forget about the config.d.ts 🤦
Yes I can update it with the new fields
async verifyToken(token: string) { | ||
for (const entry of this.#entries) { | ||
try { | ||
const jwks = createRemoteJWKSet(entry.url); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh you don't want to create one of these for every single token verification. You'll lose all TTL based caching benefits and it'll hammer the remote key set relentlessly if this is in a high volume application :) You can create it in add
above and keep it as part of the entry.
return { subject: `external:${sub}` }; | ||
} | ||
} catch { | ||
continue; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm. As a future enhancement (no action now), we may want to look at what the actual error thrown was, so that we can discern between hard faults (the token was ok but we refused the aud), soft errors (there was a problem speaking to the jwks endpoint, log and continue), expected situations (some other jwks signed this token so let's move on silently) etc.
The legacy handler for example, checks if (e.code !== 'ERR_JWS_SIGNATURE_VERIFICATION_FAILED')
and rethrows if that's the case, because that means that the token had actual hard errors like TTL expired etc and the caller wants that error thrown to them so they can log it or show it to the user.
But for now, feel free to leave as-is.
Signed-off-by: Fredrik Adelöw <freben@gmail.com>
… step Signed-off-by: Ryan Hanchett <ryan.hanchett@invitae.com>
Signed-off-by: Ryan Hanchett <ryan.hanchett@invitae.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
Thank you for contributing to Backstage! The changes in this pull request will be part of the |
Uffizzi Cluster |
kept working on this one a bit since we have a hackweek and i am poking around in the vicinity of that code right now :) |
Hey, I just made a Pull Request!
Re-opening from #24679 after I got into some trouble with git.
This pull request builds on BEP-07 to expand the ExternalTokenHandler to support a configured JWKS auth strategy. This allows external callers to use 3rd party authentication via JWKS, enabling greater flexibility in providing ways to auth with Backstage via signed tokens.
A potential area of improvement for future PRs would be to move the TokenFactory used in the tests into the backend-test-utils plugin, since it is used with near-identical patterns in the jwks.test.ts file, as well as plugins/auth-node/src/identity/DefaultIdentityClient.test.ts, and plugins/auth-node/src/identity/IdentityClient.test.ts.
✔️ Checklist
Signed-off-by
line in the message. (more info)