OAuth 2.0 flow for user groups / organizations

Question

OAuth 2.0 protocol provides permissions delegation of a user so that third-party apps can operate on its behalf. A typical way this is done on the OAuth flow is requesting a user consent to either approve or deny access for the app (Okta example). Here is an official spec describing how it works in general concepts.

I'm looking for the standardized approach to perform the same flow but for the user groups (e.g. organizations). GitHub does that in some way for organizations, so it looks like organizations represent just a group of user accounts. Are there any standardized approaches to this problem?

If not maybe there are any recommended ways how its typically done architecturally or can fit into OAuth 2.0/OpenID Connect protocols.

Answer 1

The OAuth 2.0/OpenID Connect protocols do not cover how access control is performed.

You can, within the OAuth 2.0/OpenID Connect protocols, pass OAuth Scopes or use the OIDC user info endpoint data to allow the resource server to make determination for Access Control.

Many of the commercial products within this area allow the use of LDAP as a back-end for authentication and will even convert LDAP Groups to Scopes.

I would assume, but I do not know, that GtHub stores data with a link (like a group) for the on Organization and/or the user. I know GitHub exposes this using OAuth Scopes.

Oh, and the OAuth Spec is at: https://oauth.net/2/ But if you require Authentication of users then you need to be using OpenID Connect which is built on-top of OAuth 2.0. Remember that "OAuth 2.0 is NOT an Authentication protocol"

-jim

Answer 2

There are limits to what you can show on the consent screen and dynamically calculated data is not usually supported.

You ought to be able to express a high level scope that you can present to the user though.

In terms of authorizing based on a user's organisations the claims caching technique here can be useful: https://authguidance.com/2017/10/03/api-tokens-claims/

That is: * Use OAuth for user identification and high level checks " Then do the real Authorization based on your back end data