Below is a great link in the event you are wanting to do Okta only groups:

Customize tokens returned from Okta with a groups claim

although considering that is not the request, I would refer you to the link you shared above.

simply put, navigate to the app and input the proper expression then continue with adding your groups claim to the custom auth server.

the part to identify is what to replace “active_directory” with in the line they provide. I am frankly unsure of what it might be for Google apps, have you tested with AD groups to see if you had that working first?

Thanks for your response!

Yeah, okta-only groups don't really work because most of our groups are not created in okta 😅

Yeah, I'm also fairly certain that it's the query that needs to be written better... The problem is that the documentation around it is rather poor:

startsWith(app_type/app_instance_id, pattern, limit)

I'm not sure if app_type/app_instance_id means both app_type and instance_id or it's one or the other... Using the groups API of okta to curl info about the google-synced groups also did not illuminate me. In any case, I did a bit of further digging on various forums, and got the query to:

Arrays.isEmpty(Arrays.toCsvString(Groups.startsWith("google_40fdu6e","",100))) ? Groups.startsWith("OKTA","",100) : Arrays.flatten(Groups.startsWith("OKTA","",100),Groups.startsWith("google_40fdu6e","",100))

However, this still doesn't work and returns only the native okta groups 😞

The reason I'm hesitant to test with AD groups is because our whole reason for moving to okta was to move away from AD.

Update:

I managed to solve the issue. The documentation of Groups.startsWith() is actually a lot clearer in this guide/article: Limitations of Group functions - Dynamic Whitelists

Now that I knew it needs the ID of the app only, I could use the groups API (GET

/api/v1/groups/${groupId}) to query the ID of the source of the group, and update my query accordingly. And now it works like a charm 🙂