Menu
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.
523
OAuth 2.0 scopes provide a way to limit the amount of access that is granted to an access token. For example, an access token issued to a client app may be granted READ and WRITE access to protected resources, or just READ access. You can implement your APIs to enforce any scope or combination of scopes you wish.
OAuth 2.0 defines four roles: Resource Owner, Client, Resource Server and Authorization Server.
Scopes are typically used when an external application wants to gain access to the user's data via an exposed API. They determine what the client application can do. Role- or group based access is typically used within an application to determine what a user can do.
OAuth is an authentication protocol that allows you to approve one application interacting with another on your behalf without giving away your password.
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.
106
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 an application to access a resource on behalf of the user. If your 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.
21
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
