OAuth scopes and application roles & permissions

Question

Currently my application is verifying user's access based on the roles and permissions. For example, if a user is admin then he has all permissions.

However, now I am implementing OAuth 2.0 and OpenIdConnect for single sign on and token based authentication for web applications and REST API's.

OAuth 2.0 and Open id connect rely heavily on scopes for access control. Scopes such as account.write account.read account.delete are very similar to permissions "CanCreateAccount" "CanReadAccount" "CanDeleteAccounts" "CanAssignRolesToPermissions".

I don't understand what is the difference between the two. This separation forces my application to check the client's scopes when access REST API's and separate check for user's permission. This i believe leads to code duplication.

Am I right in thinking that OAuth 2.0 scopes and application permissions are same? If this is true, then instead of maintaining separate application permissions, should I just stick to scopes through out my application?

For example, currently the user is assigned to a role and role has permissions. If I replace permissions with scopes then I wound't have to duplicate the client/user scope/permission checking functionality.

You might be thinking why not replace scopes with permissions. That is because I want to stick to OAuth 2.0 spec and scopes are used throughout the spec.

Tzong

Answer 1

Scopes are per Client app, while permissions are per user. In other words - one client app can have a scope(s) to access certain API(s), but the users of this client app will have different permissions in this api (based on their roles). Your application should not check for the scopes. IdentityServer (I see that you have used it as a tag, so I suggest that you are using this as an OAuth authenticator) will reject a client, that doesn't have the required scope(s). Your app must only check the user permissions.

Reremouse

But, if i don't check the scopes on the API then how can I restrict the client to certain resources of the API? for example, if a 3rd party client has readonly access to account endpoint then it's the API's responsibility to reject any clients request for other resources. – Tzong

Well this is kind of a corner case, but you either restrict users (you have the clientId and scopes in the user claims) or you should separate the API resources. – Reremouse

I don't believe this is a corner case. From my reading around OAuth so far, scopes controls access to the Api resource. See github & slack Api's. They seem to be using scopes to control client's access to API resource it's kind of used like a permissions. But looking at Github.com It's not clear how they handle separate user permissions and api scopes. developer.github.com/apps/building-oauth-apps/… – Tzong

This is exactly what I said. Scopes are used to control access from client point of view, and roles/permissions are used to control access from user point of view. – Reremouse

> "IdentityServer will reject a client, that doesn't have the required scope(s)" When exactly will it do that? As per my understanding, when a request comes to service, it does not need to make a call to IdentityServer. It just verifies the token with it's public key. – Stilbestrol

I guess by service, you mean some API that is protected with Identity Server. In this case, the requests comes with a token, which token contains the scopes and which token was issued by Identity Server. If the client requests scope(s), that are not allowed to him, IDS will reject the authentication. Then if the client gets a token, with some scopes, but tries to access an API, that requires different scope, the API itself will reject the request – Reremouse

@Reremouse So, to sum this up, the resource server (API) must check both: user roles/permissions AND token scopes to make decision on authorization for each API method. Is my understanding right? – Feud

@RuslanStelmachenko - well technically (looking from the dotnet perspective) the API ID is the scope, so if a token with a missing scope is coming in, it will be automatically rejected and you need to check only user perms. I don't know what technologies you are using, but usually the oidc library that you use for validating tokens, will reject one, that is not supposed to hit the current API – Reremouse

Answer 2

Am I right in thinking that OAuth 2.0 scopes and application permissions are same?

Technically, this is not correct.

OAuth 2.0 scopes are NOT application permissions. They allow a client application to access a resource on behalf of the user. If your client application has been granted the scope X on a resource, it is allowed to access that resource ONLY IF the user has the corresponding privilege.

In other words, your app's scopes MUST be checked together with the user's privileges.

To learn more, check out this article about the difference between permissions, privileges, and scopes.

Hardin

To make the distinction clearer: the user's privileges is all they can do, with scopes they can narrow it down. Maybe they can read and write pictures, but for the photo app, they only grant them a read-only scope. Then the third party can only read, while the user themselves can also write. – Calciferol

Answer 3

You could read this excellent post or watch the video in the same post to get a clear understanding of scopes, permissions and privileges.

Villanovan