Hi team,
We have a group claims issue for OIDC app-Implicit Flow, when Okta is not generating token if user’s group claim exceeds 100.
Legacy Group claim we are using:
The Okta solution page ( Okta Support Center (Lightning) ) suggests we split the tokens, but for that we need to use Token claims. We tested that with this expression: user.getGroups({‘group.type’: {‘OKTA_GROUP’}}, {‘group.profile.name’: {‘dcms’}}).![profile.name].
Now it turns out we can’t use the exact regex with the new tokens: Okta Support Center (Lightning)
Is there any way we can still use the regex (which is non-negotaible) and overcome the group number limitation?
Also we don’t have any group claims in auth server if that’s of any help.
Appreciate the support!
The only way to exceed this limit and still use regex is if you use Authorization Code flow (as mentioned in the article) instead of Implicit flow. It’s also a more secure flow and is recommended over implicit
Thanks @andrea , a follow up question. If we continue with the current implicit flow can we create the new tokens instead and just use StarsWith function to filter groups?
Something like:
Can doing this send more than 100groups in claim and allow successful authentication?
@akhilvatsa97
You could consider utilizing an Okta Token Inline Hook as a potential solution for this scenario. The underlying issue is that standard Okta Expression Language functions, such as user.getGroups, are designed to halt token generation entirely if a user’s total group membership exceeds the 100-group threshold. Transitioning this logic to an inline hook allows you to shift the group-filtering process to an external web service instead.
If you choose to explore this approach, the general workflow would involve setting up an external HTTPS API endpoint to receive the authentication context from Okta. Your external service could then query the user’s groups via the Okta API—which does not enforce the same 100-expression limit—filter for the specific dcms groups, and return a JSON patch response to inject those filtered groups back into the token claims.
There are a few architectural dependencies worth keeping in mind with this approach. Token Inline Hooks require the use of a Custom Authorization Server rather than the default Org server to trigger properly within your access policies. Additionally, because the application utilizes the legacy Implicit Flow, the final token is returned via the browser URL fragment. If the filtered list of dcms groups remains quite large, there is still a risk of encountering URL truncation or HTTP 413 errors in the browser. To address that specific limitation long-term, another option to consider would be migrating the application integration to the Authorization Code Flow with PKCE, which handles larger token payloads safely through backend server-to-server requests.
