3

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.

enter image description here

yyunikov
  • 5,719
  • 2
  • 43
  • 78

3 Answers3

3

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

jwilleke
  • 10,467
  • 1
  • 30
  • 51
  • Thanks for the reply, Jim. Yep, I understand everything you've mentioned above, however it's still not clear for me how to implement a scope which can be applied on the organization level. LDAP or anything else can provide a way to group users but the question I have is how to provide a way to (authorize) delegate access of an app to resource only located under the organization level. For example, you can install an app which is scoped only to organization repo's, issues, etc. And as a user which authenticates you can have multiple organizations. – yyunikov Nov 15 '19 at 13:54
  • 1
    I assume this may stay out of what OAuth 2.0 / OpenID Connect protocols provide and this requires building a separate ACL's database and delegation mechanism but would rather find if there are any existing solutions to this problem. – yyunikov Nov 15 '19 at 13:54
1

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

Gary Archer
  • 22,534
  • 2
  • 12
  • 24
0

I'm making some assumptions here, but I believe the issue arises from trying to authenticate two things at once.

If the organization is what you need, then go ahead and create a flow to authenticate the organization as the principal subject (via a user who has access to it), instead of actually authenticating the user itself.

Once the access token is generated, you do not necessarily need to know which user generated it anymore (or at least, the token itself does not need to know). If your user needs to be able to view and/or revoke access tokens, they should still be able to do that, since they have access to the organization in your app.

Sygmoral
  • 7,021
  • 2
  • 23
  • 31