Difference Between OIDC and Keycloak Authorization Services, Role Management, and Token Propagation

[Michele971]

I’m using Keycloak for user authentication and role management in a microservices architecture with Quarkus. Here’s what I aim to achieve:

1. Manage roles embedded in the token issued by Keycloak
2. Propagate the same token between microservices
3. Understand whether Keycloak Authorization Services are required or if OIDC alone is sufficient for my use case :/

Questions:

Keycloak Auth dependency

Do I also need Keycloak Authorization Services dependency?
Concerning "role-management", based on my understanding, OIDC alone should suffice for this.
Are Keycloak Authorization Services necessary if I don’t need resource-based policies or granular permissions but only want to manage user roles? I believe no

Token propagation between microservices:

My goal is to propagate the token from one microservice to another, ensuring the token remains intact and valid (they interact using rest client).
Do I need the keycloak-authorization dependency, or is using the OidcClientFilter strategy sufficient?

My Configuration (.properties)

OIDC

For OIDC in Quarkus, I’ve configured the following:

quarkus.oidc.auth-server-url=http://keycloak-host/realms/my-realm
quarkus.oidc.client-id=my-client-id
quarkus.oidc.credentials.secret=my-client-secret
quarkus.oidc.roles.source=accesstoken

Token propagation

For token propagation in a REST client, I use the OidcClientFilter strategy with the following settings:

# REST client configuration
quarkus.rest-client."org.acme.client.mycli".url=http://my-other-microservice

# OIDC client settings
quarkus.oidc-client.client-id=my-client-id
quarkus.oidc-client.credentials.secret=my-client-secret
quarkus.oidc-client.client-enabled=true

---

Is the quarkus.oidc.roles.source=accesstoken configuration sufficient for managing roles, or is there a better approach?
Are Keycloak Authorization Services overkill for my use case if I’m only relying on roles included in the token?
Does the OidcClientFilter approach correctly propagate the token, or do I need additional configuration to secure inter-service communication?

[quarkus-bot[bot]]

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

[sberyozkin]

@Michele971 Here are some answers,

Are Keycloak Authorization Services necessary if I don’t need resource-based policies or granular permissions but only want to manage user roles?

No, one should use them only if the authorization decisions are made by Keycloak Authorization Services, as opposed to by the role-based access control RolesAllowed checks.

My goal is to propagate the token from one microservice to another, ensuring the token remains intact and valid (they interact using rest client). Do I need the keycloak-authorization dependency, or is using the OidcClientFilter strategy sufficient?

keycloak-authorization is not required.

As far as token propagation is concerned.
OidcClient is acquiring new tokens first, even if quarkus-oidc is used to secure the access to the current endpoint, and only then propagating these newly acquired tokens. Is it what you need ?

To propagate the already existing tokens, you need to use the token propagation feature.

Is the quarkus.oidc.roles.source=accesstoken configuration sufficient for managing roles, or is there a better approach?

It is an application level decision how roles are associated with the identity, you can rely on roles being in the token or in the DB if you'd like (that would require an addition security augmentation), or indeed, in Keycloak authorization services.
Makes sense to have them in the token and then revisit as necessary.

FYI, if you work with bearer access tokens then the access token is the only source of roles, so you can drop that config property.

HTH

[Michele971]

Thanks for the clarification! @sberyozkin

To propagate the already existing tokens, you need to use the token propagation feature.

In the documentation for token propagation, it references AccessTokenRequestReactiveFilter, but it's not clear in what specific situations it should be used. For propagating the token, it should be equivalent to annotate the REST client interface with:

@RegisterRestClient
@OidcClientFilter

Right?

---

OidcClient is acquiring new tokens first, even if quarkus-oidc is used to secure the access to the current endpoint, and only then propagating these newly acquired tokens. Is it what you need ?

Here's the scenario: Postman sends a Bearer token to Microservice 1, which validates the token, uses it for @RolesAllowed, and then propagates the same token to Microservice 2 via a REST client. Both Microservice 1 and Microservice 2 need to use the same Bearer token originally sent by Postman.

My question: In this flow, at what point and for what reason would a new token be acquired instead of using the existing token sent from Postman?

---

off-topic:
There seems to be some configuration issue on my end: everything works when I run the services with quarkus dev, but when I run the services with Docker and use the same Bearer token, I get a 401 response. Could you clarify what might be causing this discrepancy?

Best,

[sberyozkin]

@Michele971 For your scenario, you need to use @AccessToken to get the existing token propagated.

There seems to be some configuration issue on my end: everything works when I run the services with quarkus dev, but when I run the services with Docker and use the same Bearer token, I get a 401 response. Could you clarify what might be causing this discrepancy?

I don't know, probably when you run it directly with docker some other users/properties are used in Keycloak realms

[Michele971]

For your scenario, you need to use @accesstoken to get the existing token propagated. @sberyozkin

I followed this tutorial:RestClientWithOidcClientFilter, which uses an OIDC client filter provided by the quarkus-rest-client-oidc-filter extension to get and propagate an access token
What is complex to understand is for what reason would, and when, a new token be acquired instead of using the existing token sent from Postman?

thanks again!

[sberyozkin]

@Michele971
Sure, it depends on application requirements. In your case, the requirement is to propagate the existing incoming token, so you just do it by attaching @AccessToken.
Sometimes the token which must be used to access some downstream services is not related to how Quarkus is secured, it can be quarkus-oidc, or Basic authentication, or it can be a cron-like application without any incoming credentials. This application may need to acquite a service token, for example, using the client credentials grant and propagate this token downstream - this is when you use quarkus-oidc-client.
If you need to propagate an existing token, be an incoming bearer access token (from Podman etc) or the access token acquired during the authorization code flow, use @AccessToken.
For example, let's assume you login into Quarkus with Google and you need this Quarlus endpoint to access a Google Calendar service on behalf of the logged in user. In this case you just add @AccessToken to the rest client and the already available access token will flow to Google calendar

HTH

[Michele971]

Got it! Very clear!

[sberyozkin]

Np at all, please experiment with these features