<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
System Status
Announcements
Announcements
Search
Search
Select Language
Knowledge Base
Knowledge Articles
Support Videos ↗
Documentation
Product Documentation ↗
Developer Documentation ↗
Product Release Notes ↗
Community
Events & Webinars
Okta Ideas ↗
Resources
Product Hub
Customer Success Hub
Product Release Update
Learning
Okta Learning ↗
Get Support
Open a Case
HomeCommunityForum
0D50Z00008G7UrPSAVOkta Classic EngineIntegrationsAnswered2025-12-07T09:00:43.000Z2017-02-09T22:38:36.000Z2019-07-26T22:58:53.000Z

  • AnnaG.59154 (Customer)

    Hello,

     

    Try to add profile to your scope: openid profile groups

  • j5v7c (j5v7c)

    Hi,

     

    Even with all scopes imaginable - scope=openid%20groups%20offline_access%20profile%20email - I'm still not seeing groups. 

     

    I've changed the filter to regexp .* but still see no groups. I'll have another look later today.

     

    Thanks!

     

    Steve
    Expand Post

  • JosephS.91969 (Customer)

    I have the same issue as well.  We have also tried using the Authorization Server and setting up groups as an approved claim.

  • j5v7c (j5v7c)

    1)If you use authorization code flow, return both access_token and id_token, id_token claim will not contains groups, only bearer + access_token using user endpoint will contains groups

    2)if you use implicit flow, request id_token alone it will contains the group, require access_token alone it will also contains groups.

    3)Use your org or authorization server should both work in the same way.

    4)you need OIDC APP->SignOn Tab->Groups claim groups Regex .*
    Expand Post

  • EwanC.59401 (Customer)

    Hi Peggy, can you expand on this?

     

    is it possible to get groups back in the accesstoken using the OpenIDConnect protocol?

     

    I can get variously scoped claims back with the OAuth2 Resource Owner Flow. but not with OpenId Connect
    Expand Post

  • JeffA.31232 (Customer)

    Following these instructions, I can get "Okta" groups, but I cannot get any Active Directory groups that the user belongs to.  I have AD syncing set up with the agent.  I have users in AD groups and can see both in the Okta interface. But the calls to get the access token or id token return "Everyone" as their only group.  How can I get Active Directory groups for a user in the access token or id token.  Or is there some other way to get groups for a user when they login?
    Expand Post

  • RobA.04824 (Customer)

    I see the same problem as Jeff. I can return a group mastered in Okta, but not AD groups synced via the AD agents. Anyone have any thoughts on this ?

  • ChrisR.57070 (PRMG)

    Are there any updates to this post? I am experiencing the same thing as Jeff.

  • JonB.88229 (Customer)

    I am also having this same issue. It seems that this should be easily done if AD groups are allowed to be synced/imported. Not sure why they are treated differently than any other Okta group. I have a meeting with Okta support today...if I get a resolution, I will post here.

  • JonB.88229 (Customer)

    So the results for the meeting, for anyone needing to get AD groups out...

     

    Direct support for AD groups and OpenId is still not available through the API. You have 2 options plus a path that I'm taking:

    1. You have to create a claim using Groups.containst/startsWith/endsWith (ex. Groups.contains("active_directory","SG-",100)
    2. Create a whitelist for each application via API only and leverage getFilteredGroups.

    See documentation here: https://developer.okta.com/reference/okta_expression_language/#group-functions

     

    My solution:

    Create a new Okta group to match your AD group and create a rule that maps the users from the AD group to the new Okta group. Setting up a new Okta group and creating a rule seems to be the path of least resistance here.

     

    For option 1, if you're security groups in AD are not named with any kind of standards in mind, the more groups you work with, the greater the potential for needing to add multiple claims. This means that if you're working with something like .NET, you have to do manual mapping to get the claims mapped to the built in Identity Provider.

     

    Option 2 can just become a maintenance nightmare in the long run. The dev resource I spoke with actually advised against using a whitelist due to the potential maintenance involved. Whitelists are also application specific.

     

    Hope my findings help anyone else in search of a good solution. Creating Okta groups to replace the AD groups might not be ideal, but it seems to be the easiest solution...at least for my needs.

    Expand Post
10 of 11
This question is closed.
Loading
'groups' not available in openid connect claims