For an app that uses an Org Authorization Server instead of a Custom Authorization Server, I understand that it is only possible to return a ‘groups’ claim in the ID Token, and not the Access Token, as stated in this guide. That resource notes that if you need a groups claim in your Access Token, the recommendation is to use a Custom Authorization Server instead.
I also understand that the ID Token is intended to be used by the client, to show the user is authenticated and get user data, while the access token is intended for authorization on the resource server.
However, our resource server needs to get the user’s AD Groups.
Initially in dev (using developer okta account), I was handling this by using a Custom Authorization Server, and assigning the groups claim with the user’s AD Groups to be returned with the access token. But now that we’re ready to test with our production Okta account, I was informed by the IT team that since we have the Okta Workforce Identity Cloud, we have an Org Auth Server and not a Custom Auth Server. So even though they have the groups claim set for Groups Claim Expression on the Application, that claim is not coming through with the access token.
To get around this, I was hoping I could just use the access token to get the user’s groups via Okta’s /userinfo endpoint. However sadly, the groups don’t come through in the userinfo response. I’m not sure if it will be possible to get the user’s AD groups to be included in that response or not, but the other idea my colleague and I have been discussing, is including both the access token, and the Id Token, in the api gateway request to the resource server. First, we’d authorize the request by validating the access token with okta’s introspect endpoint (as was already the case in the current flow). If it’s active, the groups would be retrieved from the ID Token (perhaps with another introspect request, this time using the ID Token, though technically it would be possible to simply decode the jwt to get them).
Is there any good reason not to do this, if we get push back from IT about creating a Custom Authorization Server (which I am anticipating, since I think that would require additional licensing)? This is an internal tool for our company, so the user is not prompted to allow specific scopes or anything.
Incase it’s relevant, here are some additional details about the project / application.
Single Page Application, PKCE as additional verification, Authorization Code & Refresh token Grant Type, refresh token is rotated after every use.
On the client side, a user is prompted to log in, which redirects them to the okta sso login. Upon successful login, the client makes a request to the resource server’s api gateway permissions endpoint with the access token (now considering also including id token). The access token is validated with okta’s introspect endpoint. If the access token is invalid, expired / revoked, etc, a 403 forbidden is returned to client. Otherwise, the request continues, and the user’s AD Groups are used to retrieve some permissions info on what dashboards the user is allowed access to & their access level for them, which is returned to the client. Then when a user attempts to interact with these dashboards (get some data, make updates, etc) a request is made to the api gateway’s dashboard endpoint, and the same auth steps happen (access token validated via introspect endpoint, groups used to assess user’s permissions. After confirming that they have permission & required access level for the dashboard and action they’re attempting to take on it, a request is made to the api that they’re trying to interact with, and the response is returned to the client.