33

I'm trying to use OAuth2 for authentication/authorization, but after much reading around, I am confused... I'm trying to understand how OAuth and OpenIDConnect relate to each other, and how exactly I can use them for authorizaton.

From what I understood so far:

  • OpenID Connect is best for authentication, OAuth is best for authorization

  • OAuth2 authorization is done through scopes

  • A scope is the permission given BY the user TO a client, validated at the resource server

  • an OpenID Connect id_token is meant mostly for the client application, to provide user info, and NOT as a way for the resource server to validate the user

Here is my use case:

  • I need provide SSO to a set of completely stateless webservices made by us
  • OAuth is restricted to resource_owner grant
  • The identity server is provided on our side, and connected to an LDAP server
  • Only trusted apps can be registered as service providers

And what I'm trying to do, which boggles me:

  • Only authorized users can access a given webservice API

So, I need some way to check the permission given BY an external entity TO an user, at the resource server. Which, I believe rules out the use of OAuth for authorization?

I'm not sure how to accomplish this with OAuth/OpenID connect, or even IF it fits my use case.

  1. Can role-based access be made to work with OAuth2 scopes at all?
  2. Would it be ok to pass the id_token to the resource server, with a claim containing the user's roles (and discard the access_token altogether)? So the id_token would be used for both authentication & authorization. Given that the id_token is signed and contains hashes, it would be fine, right?
  3. Should I just authenticate with OpenIDConnect, by checking the presence of the id_token, scrap the access_token altogether, and develop my own role-based authorization system?

Apologies for the wall of text, I'm just not sure if I misunderstanding the scope of OAuth/OpenID Connect here. Am I making the wrong assumptions?

Improve this question
7
  • 3
    Firstly, oAuth 2 and OpenId Connect are not different technologies, one is stacked ontop of the other, ea. Openid connect uses oAuth2,it just adds an Identification layer. I would make this just with oAuth2 by utilization scopes for each role. that means that the user much re-authenticate whenever they want to acces a new 'role' (scope) and you can have the oauth client validate that user 'x' has actually been given access for scope 'y'. Another way would be to setup a 2nd oAuth2 acces chain for the servers to exchange role information on based on the user identifiers provided at intial login.
    – LvB
    Commented May 9, 2016 at 13:47
  • 1
    What did you do ultimately?
    – AlessandroEmm
    Commented Oct 6, 2016 at 5:45
  • 2
    I ended up creating a scope for each role. So, whenever someone requests a token, the OAuth server will check whether that person has the role required for that scope. For instance, if I want to limit login to a webservice Foo, I create a role "webservice_foo_access" and a scope "foo". If the user wants to access webservice Foo, he needs to do it with a token with scope="foo". When the OAuth server receives a token scope="foo" request, he checks if the user has the role "webservice_foo_access". I hope this helps.
    – lv.
    Commented Oct 10, 2016 at 9:23
  • 1
    Do you really want a user being bothered every time a new scope (role) is requested? Or is user consent stored for a certain SP so that only the first time, consent is necessary? In a corporate environment we might not care if all SPs get to see all user roles and you can have one scope 'roles' which returns all the roles. Any thoughts on this?
    – Silver
    Commented Jan 4, 2017 at 11:12
  • 1
    We struggled with this too, and found the way Azure Active Directory (AD) does this illustrative. In Azure AD you can register an application, and then add app roles to that application registration. For example "contract manager". Then you can configure Azure AD such that when specific users or groups consent as part of the OAuth 2 flow, the access token is 'enriched' with one or more of those roles. So although the user consenting is still a bit strange, at least the resulting access token will have a role claim that can be checked by the web service. I hope this is helpful.
    – Michiel van Oosterhout
    Commented Sep 2, 2023 at 10:56

1 Answer 1

Reset to default
11

The role concept can be used with access tokens in OpenID Connect (Oauth2).

Consider that a scope is a request for claims about the user that should be included in the access token. The API requesting access knows that it needs the (say) "employee" role, includes the "scope=openid roles" query parameter in the request.

The authentication server (AS) has access to role information about the user (for instance in an LDAP directory). It can then look up the user's roles, and include them in "roles" claim in the access token.

You could also narrow the scope by requesting the role itself (scope=openid employee), in which case the AS could include it if the user is a member of that group. This is a bit less scalable as it requires detailed knowledge about the required roles, but reduces the amount of PII in the token, and reduces its size. Also, if the user is not a member of the specified group (ie, the scope cannot be included in the token), the AS must inform the API about this as per OAuth2.

The role use is fairly common, and some examples can be found on:

So as for questions 2) and 3): Don't do this :)

Improve this answer
4
  • "Consider that a scope is a request for claims about the user that should be included in the access token." Where can I find more information about this idea? I thought the scope is an indication of what the client intends to do, and the end-user is asked to consent to allowing the client to do that. E.g. "yes, allow this photo editing application to download my photos from Google Drive"
    – Michiel van Oosterhout
    Commented Sep 2, 2023 at 11:01
  • 1
    It's largely semantics, I think. You could (or, usually would) use a scope the way you describe it. Then the claim becomes an attribute of the user that proves they have consented to the client's intended action. Personally I like Auth0's documentation in this instance: auth0.com/docs/get-started/apis/scopes/openid-connect-scopes.
    – Geir Emblemsvag
    Commented Sep 3, 2023 at 10:47
  • These links are surprisingly useless for learning about roles are usually stored in the access token claims. Which is what you should do. Keycloak puts them in a hierarchy under the "realm_access" claim, others put them in "roles" or an application-specific claim.
    – tekHedd
    Commented Apr 17 at 19:06
  • I agree, there's an annoying lack of standardization on the actual token format for user access. At least Keycloak's format is fairly well supported by libraries, even if it isn't "more correct" than the format chosen by other vendors.
    – Geir Emblemsvag
    Commented Apr 18 at 4:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .