I followed this blog tutorial on how to configure Oauth with Keycloak and manage to configure it correctly, managing the oauth mapping groups to ACL profiles in Solace.
So, first question is: Is this type of Oauth flow still recommended?
Then I also tried to use client credentials flow, but didn’t manage to map the oauth groups with solace authorization groups the same way.
Using client credentials flow, can I use a single clientId/solace oauth profile and having the groups mapping functionality? Or do I need to configure 1 solace oauth profile per each clientId that connects to Solace?
Hi there, I’m Solly AI, I generate responses to your questions using the power of the Solace Agent Mesh:
Please remember that AI technology can make mistakes so ensure that you read our Disclaimer.
AI Generated responses are a work in progress, your help in evaluating my response would be awesome! If my response makes sense, please mark it as a solution or give a . If my response doesn’t make sense for your topic, please react to it with a .
Looking at the documentation, I can provide information about configuring OAuth with Keycloak for a software broker. Here’s the key information:
For OAuth configuration with Keycloak, you need to:
Create and configure an OAuth profile at the Message VPN level:
- Configure the OAuth role (client or resource-server)
- Set up endpoints (discovery or individual endpoints)
- Configure client ID and client secret
- Set up authorization groups claim name for group mapping
For group mapping specifically:
- Use the `authorization-groups-claim-name` setting to specify which claim contains the groups
- The claim must be at the top level of the JWT
- The claim value must be either a string or array of strings
- Can configure string format as either single value or space-delimited
For client credentials flow:
- Set OAuth role to "resource-server"
- Configure introspection endpoint if using opaque tokens
- Enable parse-access-token if using JWTs
- Configure required scopes and claims as needed
The documentation doesn’t specifically address password grant deprecation, but provides the framework for implementing client credentials flow as an alternative.
For specific Keycloak configuration steps and commands, please refer to the Solace documentation as the exact details will depend on your Keycloak setup and requirements.
The reason that I used the password grant in the blog was for simplicity. Typically, for a user account, you would use an authorization code grant. The authorization code grant requires two calls, one to get the authorization code and then another to exchange it for the token. I was just trying to simplify my blog; I didn’t intend to recommend a particular grant type. The type of grant you select should be based on details of your use-case. Certain grant types are not appropriate for some situations.
You should be able to setup a single OAuth Profile in the broker and use the groups mapping to authorize different users with different client and ACL profiles. I’m not sure exactly how to configure it in Keycloak; there are usually differences in how service accounts are configured vs. user accounts in most IDPs. A service account would typically be for a machine to machine use-cases and you would normally use a client credentials grant for this type of use. It sounds to me like you are on the right track.
I’m assuming here many client Ids/oauth profiles in Solace, because is the only secured way I see to have different clients mapped with corresponding authorization groups. If we use one single clientId/oauth profile, we can have different scopes, but the client credentials are shared, meaning if one application knows what scope is used by another, it can access their Solace objects… or am I seeing it completely wrong?
In another hand, when using password Oauth grant type flow, since each user on Oauth Server belongs to a group, we can map 1-1 Oauth server group<->Authorization group and allows to have a more fine-grained and secured control.
Since the client_credentials is the recommended way to setup this, can you please advise how we should approach this?
We switched to client_credentials flow, and tried both oauthRole = Client and oauthRole = Resource Server, successfully.
But we have 2 questions here:
oauthRole = Client is the Solace’s default configuration and it uses the ID token from OIDC. Seems this is not the recommended way to this use-case (invocation of an API): ID Token and Access Token: What Is the Difference? | Auth0
"One of the most common mistakes developers make with an ID token is using it to call an API.
As said above, an ID token proves that a user has been authenticated. In a first-party scenario, i.e. in a scenario where the client and the API are both controlled by you, you may decide that your ID token is good to make authorization decisions: maybe all you need to know is the user identity."
For oauthRole = Resource Server, each solace client can have a different clientId/secret and it’s the way we used to configure oauth.
We have a doubt here: is Solace using introspection endpoint in every API invocation??
Means the total requests to API using oauth, or means the total “discoveries” using the discovering endpoint, in the frequency of “Discovery Endpoint Refresh Interval”?
. If my response doesn’t make sense for your topic, please react to it with a 
.
