Closed kerkmann closed 7 months ago
Right now the library is decoding the StandardClaims, which includes an given_name. An access token from a service account have no such field. This makes is unusable for Service 2 Service communication. :(
given_name
An example how a service token look like:
{ "exp": 1706114620, "iat": 1706078620, "jti": "20cda5b8-8b46-4046-976d-0a477d66e919", "iss": "xxxxxxxxxxxxxxxxxxxxxxxxx", "aud": "account", "sub": "1f4db6ad-5e75-479c-b289-b8096ec1f4f4", "typ": "Bearer", "azp": "crawler", "acr": "1", "realm_access": { "roles": [ "offline_access", "default-roles-staging", "uma_authorization" ] }, "resource_access": { "account": { "roles": [ "manage-account", "manage-account-links", "view-profile" ] } }, "scope": "email profile", "email_verified": false, "clientId": "crawler", "clientHost": "xxx.xxx.xxx.xxx", "preferred_username": "service-account-xxxxxx", "clientAddress": "xxx.xxx.xxx.xxx" }
Indeed I came across the same problems. Especially when using oauth2 as identity source.
@kerkmann Do the recent changes work for you as well? Let us know if you still have problems with your use-case.
Right now the library is decoding the StandardClaims, which includes an
given_name
. An access token from a service account have no such field. This makes is unusable for Service 2 Service communication. :(An example how a service token look like: