API Security - machine-to-machine Application groups

Questions
1

We are trying to protect a ASP.Net Core web api using Okta. The front end will only be our customers api’s, no user UI front-end.

Using the machine-to-machine account work for me but I am unable to get the groups that the Application is in? As there can be 100’s of them, we don’t want to hard code all allowed client id’s or use a customer DB. Is there a supported way to get the Application groups?

2

сan you clarify what you call “application groups” and what is “groups application is in”?

3

In the Okta UI you can add a User to a group or an Application?

4

So do you want to receive list of groups which user belongs to? or the list of users assigned to the application?

5

Neather, using the machine-to-machine(Client Credentials flow), the user == Application (not a user) & Applications can be added to groups?

I was able to code a C# unit test using Unit Testing and Implicit Flow to logon a normal user and pass the accessToken to the api. But still not sure on the api side how to tell what groups the user is in? I was able to add an access claim to the dev auth server, group1 = isMemberOfGroupName(“group1”), but this seems dump to have to add a access claim per group?

6

Oh, I see now, what you are saying. I don’t think you can get this information unfortunately, as Okta’s claim evaluation doesn’t have this functionality in the Expression Language. It’s available through Okta APIs though.

7

Thanks. I see NuGet has a Okta.SDK but that doesn’t support .Net core or are you talking something else?

I have tried to call to https://dev-534507.okta.com/api/v1/users/me/groups using the users access_token & id_token as a Bearer but the request fail with a 403 Forbidden - https://developer.okta.com/docs/reference/api/users/. If I call https://dev-534507.okta.com/api/v1/users/{id}/groups as SSWS I get a responce. Is this the correct way?

8

I think that last one URL you mentioned is a standard one to obtain user groups, I never tried to apply it to oidc_client honestly. You can check what is in the response, but I think it’s something different from what you expect, as your id represents an application in your m-2-m communication, not a user.

The other ones you mentioned in the beginning are just not valid url’s

9

I found this link - No 'groups' scope in the console for the default Authorisation Server.

This does work for a User but not the Machine-To-Machine id.