Can't work with Google Oauth2 using qaurkus-oidc

[pmlopes]

Describe the bug

I'm trying to help a user secure a simple API with Google/Azure as they did with Vert.x, however we cannot start the application on our development environments as quarkus-oidc assumes that oidc is using Keycloak for some unknown reason.

2023-01-12 13:33:37,383 INFO  [io.qua.oid.dep.dev.OidcDevConsoleProcessor] (build-4) OIDC Dev Console: discovering the provider metadata at https://accounts.google.com/.well-known/openid-configuration
2023-01-12 13:33:38,257 ERROR [io.qua.run.Application] (Quarkus Main Thread) Failed to start application (with profile dev): java.lang.StringIndexOutOfBoundsException: Range [0, -1) out of bounds for length 27
	at java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:55)
	at java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:52)
	at java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:213)
	at java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:210)
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:98)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckFromToIndex(Preconditions.java:112)
	at java.base/jdk.internal.util.Preconditions.checkFromToIndex(Preconditions.java:349)
	at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4611)
	at java.base/java.lang.String.substring(String.java:2723)
	at io.quarkus.keycloak.pep.runtime.KeycloakPolicyEnforcerRecorder.createPolicyEnforcer(KeycloakPolicyEnforcerRecorder.java:70)

The setup:

# Configuration file
%prod.quarkus.oidc.auth-server-url=https://accounts.google.com
quarkus.oidc.auth-server-url=https://accounts.google.com
quarkus.oidc.client-id=my-own-client-id-long-code.apps.googleusercontent.com
quarkus.oidc.credentials.secret=my-own-client-secret-long-code

Expected behavior

It is expected that users will use other providers than Keycloak. It doesn't seem trivial to find this information on the documentation.

Actual behavior

No response

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[quarkus-bot]

/cc @pedroigor (oidc), @sberyozkin (oidc)

[geoand]

I don't have any insight into this issue, but I just wanted to mention that users can do something like:

quarkus.oidc.provider=google
quarkus.oidc.client-id=<Client ID>
quarkus.oidc.credentials.secret=<Secret>

as mentioned here.

[geoand]

It would be useful for debugging purposes to either have a sample project that exhibits the problematic behavior, or at the very least, the pom.xml file of the project (I am assuming that quarkus-keycloak-authorization is being used when it probably should not be).

[pmlopes]

quarkus-google-oauth2-test.zip

@geoand I've updated the test app which is a copy and paste of the OIDC guide. I've replaced the server urls with the provider=google like you mention and the document you shared, still it doesn't seem to work:

2023-01-13 10:03:36,243 ERROR [io.qua.run.Application] (Quarkus Main Thread) Failed to start application (with profile dev): java.util.NoSuchElementException: No value present
	at java.base/java.util.Optional.get(Optional.java:143)
	at io.quarkus.keycloak.pep.runtime.KeycloakPolicyEnforcerRecorder.createPolicyEnforcer(KeycloakPolicyEnforcerRecorder.java:66)
	at io.quarkus.keycloak.pep.runtime.KeycloakPolicyEnforcerRecorder.setup(KeycloakPolicyEnforcerRecorder.java:38)
	at io.quarkus.deployment.steps.KeycloakPolicyEnforcerBuildStep$setup1036344509.deploy_0(Unknown Source)
	at io.quarkus.deployment.steps.KeycloakPolicyEnforcerBuildStep$setup1036344509.deploy(Unknown Source)
	at io.quarkus.runner.ApplicationImpl.doStart(Unknown Source)
	at io.quarkus.runtime.Application.start(Application.java:101)
	at io.quarkus.runtime.ApplicationLifecycleManager.run(ApplicationLifecycleManager.java:109)
	at io.quarkus.runtime.Quarkus.run(Quarkus.java:71)
	at io.quarkus.runtime.Quarkus.run(Quarkus.java:44)
	at io.quarkus.runtime.Quarkus.run(Quarkus.java:124)
	at io.quarkus.runner.GeneratedMain.main(Unknown Source)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at io.quarkus.runner.bootstrap.StartupActionImpl$1.run(StartupActionImpl.java:104)
	at java.base/java.lang.Thread.run(Thread.java:1588)

2023-01-13 10:03:36,243 ERROR [io.qua.run.Application] (Quarkus Main Thread) Failed to start application (with profile dev): java.util.NoSuchElementException: No value present
	at java.base/java.util.Optional.get(Optional.java:143)
	at io.quarkus.keycloak.pep.runtime.KeycloakPolicyEnforcerRecorder.createPolicyEnforcer(KeycloakPolicyEnforcerRecorder.java:66)
	at io.quarkus.keycloak.pep.runtime.KeycloakPolicyEnforcerRecorder.setup(KeycloakPolicyEnforcerRecorder.java:38)
	at io.quarkus.deployment.steps.KeycloakPolicyEnforcerBuildStep$setup1036344509.deploy_0(Unknown Source)
	at io.quarkus.deployment.steps.KeycloakPolicyEnforcerBuildStep$setup1036344509.deploy(Unknown Source)
	at io.quarkus.runner.ApplicationImpl.doStart(Unknown Source)
	at io.quarkus.runtime.Application.start(Application.java:101)
	at io.quarkus.runtime.ApplicationLifecycleManager.run(ApplicationLifecycleManager.java:109)
	at io.quarkus.runtime.Quarkus.run(Quarkus.java:71)
	at io.quarkus.runtime.Quarkus.run(Quarkus.java:44)
	at io.quarkus.runtime.Quarkus.run(Quarkus.java:124)
	at io.quarkus.runner.GeneratedMain.main(Unknown Source)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at io.quarkus.runner.bootstrap.StartupActionImpl$1.run(StartupActionImpl.java:104)
	at java.base/java.lang.Thread.run(Thread.java:1588)

2023-01-13 10:03:36,245 INFO  [io.qua.dep.dev.IsolatedDevModeMain] (main) Attempting to start live reload endpoint to recover from previous Quarkus startup failure

[geoand]

Thanks @pmlopes.

What happens if you remove

        <dependency>
            <groupId>io.quarkus</groupId>
            <artifactId>quarkus-keycloak-authorization</artifactId>
        </dependency>

?

Do things work as expected?

[pmlopes]

@geoand yes and no. I'll take it offline for a moment.

[sberyozkin]

Hi @pmlopes @geoand sorry for a delay, I was totally disconnected all last week.

I agree this issue shows that the OIDC documentation will need to clarify a few details.
Let me summarize why it does not work:

• by default, provider=google means it is a quarkus.oidc.application-type=web-app meaning that it only deals with the authorization code flow, therefore the bearer access token verification can not be done. This can be customized as quarkus.oidc.application-type=service (or hybrid), but like you said Paulo, Google does not have a token introspection endpoint. Note, starting from 2.16, users can choose to verify such binary access tokens (from Google, Github, etc which have no introspection) indirectly by requesting a user info access - since it involves Google/etc verifying such tokens themselves when returning UserInfo
• Next, AdminResource is public - it has no @Authenticated or @RolesAllowed.
• Having keycloak-authorization does not make sense with non-Keycloak providers, that said, why does an apparently public AdminResource is protected with keycloak-authorization in the keycloak-authorization quickstart but not here ? The reason is that in the keycloak-authorization quickstart, you have a real bearer access token verification ( quarkus.oidc.application-type=service is a default, and with proactive authentication is on by default, the bearer token is verified even if AdminResource is public, with quarkus-oidc creating SecurityIdentity and KeycloakAuthorization policy check reacting to it by sending the token further to Keycloak) - while with provider=google, Quarkus Security thinks it is an anonymous identity because quarkus-oidc CodeAuthenicationMechanism has nothing to verify and does not get an opportunity to challenge because AdminResource is public and KeycloakAuthorization does not need to check anonymous identities.
• To have a bearer token verification failing with this setup, simply add @Authenticated (=> you will get 302 reaction from quarkus-oidc code flow support), or, alternatively, just add quarkus.oidc.application-type=service (=> you will get 401)

I'll assign to myself to review what can be improved in the docs.

[ghost]

I'm trying to setup bearer access token verification for my Quarkus Rest API with Auth0.
I also got 401, because Auth0 does not have introspection endpoint. @sberyozkin, if I understand, I'll have to wait for 2.16 to make it work?

[pmlopes]

Just my 2cts:

Indeed, Google has no token introspection, but it is a OIDC-compliant service. I can discover the configuration here:

https://accounts.google.com/.well-known/openid-configuration

From that json we can extract the well-known claim jwks_uri: https://www.googleapis.com/oauth2/v3/certs

And with this information, any JWT issued by Google can be validated at the application side (like it happens for Keycloak).

The use of the userinfo_endpoint claim works for opaque tokens, with the extra penalty of an HTTP request to Google for each interaction at the Quarkus application side, but I'm uncertain if it will for service accounts https://cloud.google.com/iam/docs/service-accounts

Service accounts are used mostly for machine to machine identity, like in a microservice environment and this isn't a Google-specific thing, for example Azure has a similar concept: https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/service-accounts-introduction-azure

Looking at the following question by @jderuere, Auth0 also does OIDC, and we can get the configuration from:

https://${tenant}.okta.com/oauth2/default/.well-known/openid-configuration

My take here is that the documentation should clarify the meaning of OIDC as users like me may be doing wrong assumptions, while it seems that OIDC here means Keycloak OIDC support.

[sberyozkin]

@pmlopes Paulo, sorry, not sure what you meant.

As far as OIDC code flow is concerned, the access token, be it binary or JWT token, is meant for the confidential OIDC client like Quarkus endpoint to request something from Google on behalf of this endpoint, specifically requesting UserInfo is a typical operation.
Verifying the binary token is not possible with the public keys available from the JWK endpoint. May be we can have a call or chat on Zulip/Google chat.
What Quarkus now can do with 2.16, verifying binary bearer access tokens indirectly with the UserInfo acquisition is the only realistic option for accepting such binary tokens as bearer tokens.
If it is a code flow, these binary access tokens are not even verified in Quarkus because they are not used by Quarkus itself in this flow, IdToken is the primary token which is used in the code flow to create a SecurityIdentity.

[sberyozkin]

@jderuere Hi, right, it is not possible to verify an opaque binary token locally, one would need to have a provider secret key available, but if it is just a DB pointer in the provider's database then it won't work either. So if verifying the binary token is necessary with the provider having no introspection endpoint then the only option is to verify it indirectly by requesting a UserInfo from the provider, it will be possible with 2.16, actually you can try CR1, see
https://quarkus.io/version/main/guides/security-openid-connect-web-authentication#quarkus-oidc_quarkus.oidc.token.verify-access-token-with-user-info, use it alongside quarkus.oidc.authentication.user-info-required=true

[sberyozkin]

@pmlopes Thanks for some extra explanations, just having

quarkus.oidc.provider=google
quarkus.oidc.application-type=service

for the endpoint receiving a bearer token in JWT format will do.

The confusion has been for me that when someone says opaque token then it means to me binary (non-JWT) token :-).
So all of my typing above was about trying to explain how Quarkus can help with verifying such binary tokens which can't be introspected.
Also, in case you'll try to exchange the access tokens with the jwt bearer grant, then see https://github.com/quarkusio/quarkus/pull/29130/files (oidc-token-propagation-reactive/deployment/test), for Azure you'd need to have something like

#oidc client config is enough if you need to use the injected OidcClient directly
quarkus.oidc-client.auth-server-url=${azure.url}
quarkus.oidc-client.client-id=client_id
quarkus.oidc-client.credentials.client-secret.value=client_secret
quarkus.oidc-client.credentials.client-secret.method=post
quarkus.oidc-client.grant.type=jwt
quarkus.oidc-client.scopes=https://graph.microsoft.com/user.read,offline_access
quarkus.oidc-client.grant-options.jwt.requested_token_use=on_behalf_of

# this enables OIDC token propagation client filter to use OidcClient to exchange the access token using a jwt-bearer grant and propagate the new token as Authorization: Bearer new_token
quarkus.oidc-token-propagation-reactive.exchange-token=true

[sberyozkin]

TODO: also highlight in the docs the importance of the aud validation