-
Bug
-
Resolution: Done-Errata
-
Major
-
None
-
False
-
-
False
-
---
-
-
This is a minor update to make it possible to get the user name using the same code with both authorization code and bearer token flows, when dealing with social provider tokens. I noticed it had to be tuned when working on the latest demo.
For example, given a GitHub token, if it is an authorization code flow login, then the user name can only be acquired from `quarkus.oidc.UserInfo`, as shown [here](https://github.com/quarkiverse/quarkus-langchain4j/blob/main/samples/secure-mcp-sse-client-server/secure-mcp-client/src/main/java/io/quarkiverse/langchain4j/sample/LoginResource.java), getting it from `SecurityIdentity` does not work.
But if it is a bearer access token, then using either `UserInfo` or `SecurityIdentity` (as shown [here](https://github.com/quarkiverse/quarkus-langchain4j/blob/main/samples/secure-mcp-sse-client-server/secure-mcp-server/src/main/java/io/quarkiverse/langchain4j/sample/UserNameProvider.java)) works.
Ideally, the `securityIdentity.getPrincipal().getName()` option should also work for tokens acquired from OAuth2 social providers during the authorization code flow too.
The reason it currently does not is that in case of the code flow, an internal ID token is generated which is then used as a source for a principal name, while it is only available for OAuth2 providers in the `UserInfo` json.
So I did a minor update to fix it.
The updated test confirms it - note, that before, the augmentor was manually updating the principal to pick up the UserInfo property, for a test GitHub provider. It is no longer necessary if `UserInfo` contains the configured principal claim
- links to
-
RHSA-2025:153096
Red Hat build of Quarkus 3.20.2 release and security update