-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
OIDC ID token introspection #36563
Comments
/cc @pedroigor (oidc), @sberyozkin (oidc) |
Thanks for opening this issue, I'm away from my laptop, but we'll sort it out, we may support jwks uri endpoint authentication like we do for the introspection endpoint , etc Will add more comments tomorrow Cheers |
@calvernaz I've read the description again, IMHO adding Do you agree ? Please provide some more details if yes, what type of authentication it is, does it require the use of client id and secret, Basic authentication or another dedicated pair ? Quarkus OIDC will manage the keys itself, refresh them if needed. |
Here is another option which we use for pure OAuth2 providers which won't have introspection and jwks uri endpoints, we say The endpoint then just works with the injected In your case, ID token will also be returned, but I think it should still work, I'd still prefer to enhance a bit |
Hi @sberyozkin thanks for coming back so quickly! Will comment from the end,
The authentication uses a signed JWT token passed as an authorization header. We would need a way to handle that signing since it's a custom code too.
Totally agree, letting quarkus manage the lifecycle of the set and call that custom code used to get the key set or provide the signed token. |
I can try this, in fact, I might have done it, but failed somewhere (will try again tomorrow) but I'd use this as a fallback option. Thanks again. |
Is it the same one as either the https://quarkus.io/guides/security-oidc-code-flow-authentication#oidc-provider-client-authentication If it were the case then we could enable it for the JWKs uri endpoint with a boolean flag. The extra headers can be already configured for the token endpoint I believe - as long as those headers are static, so the same headers can be sent to all provider endpoints Having a pluggable JWKS set support is an option too - it needs to be investigated |
Thanks, so regarding the headers (static), there is a way already to pass those to all requests, or just the token for now? |
There is a dedicated In general I prefer to let users enable things with the configuration only, though the configuration is getting quite saturated, that said, it looks like a reasonable customization option that can be done the at config level. So, if either Otherwise, I'll need to make sure the JWKS acquisition is customizable - which in itself maybe a good idea anyway Let me know what you prefer please |
Indeed, the authentication for our JWKS endpoint is using Thanks for tackling this 👍 |
@calvernaz Np, thanks for the confirmation, should be an easy enough update |
@calvernaz Can you clarify one thing please - do you use the same authentication mechanism for the token endpoint ? I.e, |
@sberyozkin for the |
@calvernaz OK, thanks. That does complicate things, we'd need to introduces a dedicated configuration group for the JWKS endpoint authentication alone which would cover everything that the current group covering the token endpoint authentication does. (Just a note to myself: the same should've happened for the introspection endpoint instead of offering a basic authentication alternative only - but it can be deprecated) OK, I'll see how it goes. I may have to re-prioritize on the idea of a pluggable JWKS provider - which I'd like to avoid - if users will have to write their own private_key_jwt code, etc, then it would not help supporting the message that we'd like Quarkus security be as accessible as possible. I'll keep you up to date, thanks for the interesting enhancement request. By the way, I'll update this issue to be just that, an enhancement request, so that we can mark it as a release noteworthy feature once it is implemented, and tweak the issue name a bit for users to see clearer what we are trying to do here, hope you won't mind Cheers |
Done, this is exactly what I believe the task is about: support retrieving keys from the JWK set endpoint, which is typically public, hence it can qualify as an enhancement request Any concerns - please tweak the issue as you prefer, cheers |
@calvernaz I'm also assuming that it is the Thanks |
@sberyozkin unfortunately it's not in our case we use a So client_name is what you are looking for in our case. The reason being we have generated the certs to this client name (edit) |
@calvernaz OK, so let me make sure this can be covered with the existing configuration. As far as so you'd configure |
@calvernaz I've been prototyping some code today and then I've realized that I should've asked for more details. Is it an HTTP POST request in your case ? How else would you pass the JWT assertion to the JWKS endpoint, as a query parameter ? I'm starting to think that letting users customize JWKS acquisition and also make the utility code for creating a signed assertion may be the right solution after all, but please provide more details first. Thanks |
This is an interesting case all right, for Apple we did a custom JWT assertion scheme support, so as long it does not become a highly custom code path for this case, we can do something like that, but I'm now at the decision junction point, so I'd appreciate more details:
We might be able to generalize it, but if JWT set acquisition interface will be introduced, at least I'll try to make some token signing code reusable, I'm assuming you have your own code in place, but may be Quarkus can be of some help there, lets see how it goes Lets continue next week, |
It's a GET request and we values are passed as headers.
Headers:
The token is signed with private key and adds custom claims to it besides
The extra headers are custom identifier required for the request to be valid. GET /certs
I wonder if a alternative until we get this all scoped out, is to provide a configuration to turn off introspection local and remote and leave to the service to handle the JWKS and the validation process. This would let custom implementation that are a bit more involved to work until we get that JWT acquisition interface. |
Thanks for the explanation.
But it would require introducing its own interface for Quarkus delegate the token verification to a 3rd party including managing the signature verification, various properties like issuer, time to live, this is the core of the quarkus-oidc functionality. Let me investigate more next week what can be done |
@calvernaz I've thought more about it and decided to restore the original issue description and qualification, sorry for messing it up. I've opened a PR, #36609, showing how your suggestion to I've also opened smallrye/smallrye-jwt#733 to make it straightforward to set the cert chain claim, even though you may have the working code, you might want to give https://quarkus.io/guides/security-jwt-build a try in the future once the smallrye-jwt issue is fixed Finally I've opened a dedicated enhancement request, instead of hijacking this issue, #36610, to support customizing the JWK set acquisition process only, example, one would get Vert.x WebClient already initialized with proxy, tls properties, etc. I'd like to resolve this issue as not a bug once #36609 is merged then we can discuss some additional identity provider customization details in Discussions/Zulip, and in meantime I'll be looking at the #36610 enhancement. Does it sound good to you ? If you'd like we can keep this issue open until you confirm yourself the custom identity provider works for you |
@calvernaz FYI, #36634, that should simplify things significantly for your case, you'd only need to set an Authorization header with the generated token and add other headers as required, and before 3.6.0 is released, using a custom |
Hi @sberyozkin sorry for the radio silence, there was a lot to catch up since :) So, to uptake your changes what do I have to update on my side (version-wise) or if I understand correctly it's already supported and you have a test to prove it. Yes, I'll give it a try and if it works (or not) I'd like to understand a bit better the enhancements you are proposing. Thanks a lot 👍 |
Hi @calvernaz, np at all, so 2 options are proposed. One is the workaround around the current limitation, you just register a custom #36634 has now been merged too, so once 3.6.0.CR1/3.6.0 is out, the only thing you'd need to do is to register something like:
Quarkus itself will deal with JWK keys, parsing them, refreshing them, dealing with the OIDC client. May be we'll need to tweak a bit which algorithms can be supported but it is already quite comprehensive. You'd only have the token generated. May be the next version of Quarkus JWT build API can be of help with the token creation - it would do right now except that no typed support for setting the cert chain is available yet, so you'd need to create a base64 rep of the chain manually, which won't be needed later. Hope it clarifies things. Can you please give a custom You can also try to build the source, https://github.com/quarkusio/quarkus/blob/main/CONTRIBUTING.md#build, and check how the filter approach works - we can tune that if needed in separate issues. |
Hi @sberyozkin, I tested your proposal and correct me if I'm wrong. The I was expecting a similar handling but specifically to the
Yes this second approach seems to be close to what we want but I'm still unclear if the filter is enough because once I get past the request (custom auth), I need to have the token access validate it and provide a signal that the session can be created. |
Hi @calvernaz Thanks for checking it, Re the workaround:
I propose to fetch JWT keys in the
May be I'm missing something but the token targeting the certs endpoint will be generated when the JWK keys will be requested and it will be your OIDC server which will verify it, or did you mean something else ?
I can have a look if you will share some code related to specifically how you work with this Identity Provider (please replace the internal details with some dummy code). The redirect loop is usually happening if the state cookie is available but the OIDC provider is not returning a Re the proposed solution in 3.6.0
Quarkus will handle it all, will fetch the keys, then when the ID token has to be verified, it will find the matching JWK key, using either kid or the cert thumbprint, and verify the signature. If the key can not be found, it will refresh the keys but restricting it to a specific interval. Is there something specific to the ID token verification process that you may be concerned can't handle ? You can always complement the default signature, expiry, issuer, audience verification done by Quarkus with more checks in custom |
Yep this makes sense!
First part is correct, we fetch the certificates (jwks_uri a.k.a /certs) with custom auth, but we don't validate the token on the OIDC provider we use the public key in the cert (the one we downloaded) to validate the token locally.
Is it possible that we arrange a call or something? Not only showing the code will be hard because it's internal libraries the flow and ability to customize the authentication seems to be at odds here.
|
Well, I was referring to the token you had to generate for the JWKS endpoint authentication to work, indeed, the downloaded JWK would be used to verify the actual code flow tokens, so no ambiguities there
Sure, 12.00 or 16.00 tomorrow Dublin time ? Please reach out to me at |
right, that's it then.
12.00 sounds good! Will ping you then! |
@calvernaz Thanks, let me have a look at making the fetched JWKs visible to the custom code, As far as #36634 is concerned, please give that a try too and see how far Quarkus can go with the verification. FYI, as far as Access tokens can be propagated with attaching |
Hi @sberyozkin good news here :) I've tested with this approach #36609 but using our internal library and could validate the token and the session was created. Regarding all the suggestions:
So, having something working give me enough confidence to start tweaking on the edges. |
Hi @calvernaz, I missed your ping here as I got a bit all over the place in the last couple of days, glad to hear you had some good progress, appreciate it may have been a bit tricky to get started given the requirements like retaining the current verification strategy etc.
Sure. I'm also keeping contemplating how to provide access to the public key, I've had an immediate idea to let uses check JsonWebTokenSet somehow, but then started thinking about providing some kind of Verifier interface which will replace the core verification logic - but having a doubt now as that will kind of duplicate what
Hoping it should not be a problem, https://quarkus.io/guides/rest-client-reactive#proxy-support
+1, thanks |
@calvernaz Here is the code which shows how the core verification works: Here is what happens:
Next, if the above does not cover all the verification requirements, you can have a dedicated |
@calvernaz Hi, I've been thinking more about these options, and #36634 in particular. So right now you have a custom identity provider, which itself fetches JWK keys, and itself verifies the token. The idea behind #36634 is that, in your case, you only register a filter which ensures JWKS endpoint authentication works, Quarkus fetches JWKS, parses, caches and renews them if needed, and verifies the token using the steps described above. In this case, if needed, you can complement the provided I'm thinking that if you will get convinced that it is the way to go, then intermediate steps like letting your custom identity provider access the verification key may prove to be of transient use - and the challenges will still remain - for example, you'd need to continue enhancing this custom identity provider to handle JWK refresh, correctly report expiration errors for Quarkus to refresh the tokens. So, can you please give #36634 a try - I'm positive it will help simplifying your current integration quite a bit and it can be verified with integration tests (we can discuss the integration test options). If #36634 works then the custom identity provider can be dropped. If however you will find that the custom identity provider option will need to be around for a while, then it will indeed confirm further support for such providers like an access to the matching verification key is required. 3.6 release is due in 2 weeks, https://github.com/quarkusio/quarkus/wiki/Release-Planning. But you can use snapshots to verify: https://github.com/quarkusio/quarkus/blob/main/CONTRIBUTING.md#using-snapshots How does this plan sound ? Thanks |
Describe the bug
Before starting the issue I'm facing, I must say I've looked around and tried everything possible before creating this issue, I feel like i'm facing a very particular issue given the environment I'm in.
We are evaluating quarkus-oidc and we have a in-house OIDC provider.
OIDC Provider:
Flow:
Problems:
Again, this seems very specific, but would be possible to have no need for remote introspection and avoid trying to fetch the metadata from jwks_uri on boot or even during step 3 of the flow.
Thanks
Expected behavior
No response
Actual behavior
No response
How to Reproduce?
No response
Output of
uname -a
orver
No response
Output of
java -version
No response
Quarkus version or git rev
No response
Build tool (ie. output of
mvnw --version
orgradlew --version
)No response
Additional information
No response
The text was updated successfully, but these errors were encountered: