I did roles in general because they are static, you can assign them to who can call the API, and it gives the 2nd level of defense on features and application functions. The first being AuthN/AuthZ.

I used groups in my app for areas that the USER controls and can put in (for my OpenRMF Professional application) data into an ATO package. Or you could use it to group companies, organizations, agencies, etc. as well for showing specific data. The AuthN/AuthZ says "can you even get here". The role says "can you even ask for this type of data". And the group says, "ok now that you are in what area of data are you allowed to see" and nothing else.

You will have to come up with a structure that works. We have a "key" field and that is the beginning of the groups to match on. And the key field is unique in our application for the areas/agencies/ATOs/organizations grouping.

I chose this way as it does the job, is simple to manage, can work for just 1 or 100 or 1,000 groups, and it is not overly complex. If you make it too complex, it is even harder to debug/troubleshoot.

You could probably use clients and secret keys for that, then assign roles to it possibly. Your app has to know what client is used. And the user cannot change the client in any way or get to another client w/ their credentials that they should not. Just have to test. Per usual in software dev, there are always n+1 ways to do something.

Good luck!