18

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?

Thank you.

  • 2
    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 May 9 '16 at 13:47
  • Hmm, thanks for the ideas. I didn't think of using scopes like that, and sounds much simpler than the mess of my backup plans :) Thanks again! – lv. May 9 '16 at 15:25
  • What did you do ultimately? – AlessandroEmm Oct 6 '16 at 5:45
  • 1
    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. Oct 10 '16 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 Jan 4 '17 at 11:12
4

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 :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.