Role-based access control with Google authentication

Question

I have an application which allows OpenID Connect login. I need to be able to give the users admin/read-only access based on their roles or group membership. With Keycloak, I can configure the Client settings to include roles and groups in the JSON Web Key my application receives, and I can set up mappings within the application to assign the correct permissions to various roles or groups of users (depending on the mapping).

I'm surprised that I have not been able to find any clear answers to this mundane problem. Is nobody using Google in such a setup within their organization or am I missing something obvious?

I tried requesting various scopes related to groups or roles based on this document, but even though the consent page has changed to reflect this, the JWK did not contain any useful information.

How do I configure Google's authentication to return group membership or assigned roles in the token?

Marcasite

Answer 1

I don't think you can add more information to the ID Token that you get from Google. According to Google's OIDC discovery document, these are the claims that can be present in the ID token:

"claims_supported": [
  "aud",
  "email",
  "email_verified",
  "exp",
  "family_name",
  "given_name",
  "iat",
  "iss",
  "locale",
  "name",
  "picture",
  "sub"
 ]

Apparently, an organization administrator can limit which claims do end up in the ID token, so you might get a subset of these.

You should be able to get information about the user's group from one of the myriad APIs that Google exposes. Not sure if Cloud Identity is the one you're after, but there is an endpoint that returns information about groups: https://cloud.google.com/identity/docs/reference/rest/v1/groups.memberships/get If that's not the one, I think you could search the scopes page that you linked, and you should find the relevant scope there. The scope will be tied to a concrete API and this will be the API that you have to call to get the user's groups, roles, etc.

Tanya

Thank you, so what you're writing means that there is no way to make an application with universal support for various OAuth 2.0/OIDC providers and I would have to customize the handling for each of the major ones? – Marcasite

@Marcasite That's how I've always understood it. However, there are tools that allow you to support multiple OAuth providers and get essentially the same(ish) format. Depending on what tool you're using for the FE, something like next-auth, magic (magic labs), or Supabase auth are great for using multiple auth providers and generating a "universal" JWT. I think passport has similar functionality as well, if you're using node.js for your server. – Beach

If by "customizing handling" you mean adding your own information that is needed to authenticate/authorize a user, then yes. What people usually do is to set up their own Authorization Server (as Adam pointed out), which is able to authenticate users through external OIDC providers but can also issue its own tokens with claims that you need. – Tanya