4

In most OAuth2 typical use cases, the scope is used by resource owner password grant type, or authorization code flow, where a user login is required.

It seems that scope is mainly used to control access of users' resource. For example, to authorize a 3rd party client to access the resource owner (user) resource at another server.

In some cases, user is not present. For example, a company wants to provide a API for another company only. Client credential is being used. Most API gateway products have subscriber management option to control which client ID can access which APIs. In that case, is it still meaningful to use OAuth scopes to manage access to APIs? Why?

Besides, I cannot find any examples using scopes along with client-credential grant type. Is it rare use case?

Frankie Hung
  • 561
  • 1
  • 6
  • 16

1 Answers1

7

The Client Credentials grant type is used to access protected resources that both sides own/control/trust.

Scopes are supported by this grant type. They are typically not used because the trust is already there and limiting that trust via scopes is not required.

In other words, the reason that scopes are not used is that if the trust is not there, other grant types are more appropriate.

John Hanley
  • 74,467
  • 6
  • 95
  • 159
  • What do you mean by mutual trust between the client and the resource server? Does it imply that the resource server always trust every requests coming from that client? What if the server only allows the client to access subset of its resource but not all? What are the best examples of using this trust model instead of scopes? – Frankie Hung Oct 15 '19 at 10:04
  • 2
    1) If the client and server do not trust each other, use a different grant type. 2) This grant type supports scopes. Permissions can be managed by the scopes requested. Since the client ID is also part of this grant type, permissions can be controlled based on the Client ID as well. 3) This grant type is used between two systems, for example, two systems in a company's data center. 4) It is up to you to decided trust and features. The OAuth spec does not define this. – John Hanley Oct 15 '19 at 16:02
  • I use this grant type to authorize one application to communicate with another application running over the internal network. The OAuth token is placed into the HTTP `Authorization: Bearer ` header. For this grant type, this is how it is typically deployed. – John Hanley Oct 15 '19 at 16:04
  • I work for a team that depends on a Duende IDP and its current validation requires a scope to exist for a client credential token request! Also, OAuth2.0 says that the 'openid' scope is required since it "Informs the Authorization Server that the Client is making an OpenID Connect request". But somehow this requirement does not apply to the client_credential flow? I'm having trouble locating this information in the spec. – lonious Sep 15 '22 at 00:05
  • @gordlonious - Post a new question. – John Hanley Sep 15 '22 at 00:37
  • I disagree on the " if the trust is not there, use something else". Scopes can limit the damage if something goes south - privilege escalation is one of the most abused and dangerous attacks. Not only from "hacker" perspective (= lateral movement), but really from a developer point of view too: if someone calls an endpoint accidentally, damage can happen. – Markon Jul 31 '23 at 10:21
  • @Markon - I am not sure how your comment applies to `Client Credentials`. If a system using client credentials is hacked, scopes do not protect you. The hacker (bad employee) has the secrets necessary to create new credentials without scope restrictions. Therefore the client and server must be secure and trust each other. Do not use client credentials if that cannot be guaranteed. – John Hanley Jul 31 '23 at 16:11
  • Security is not just about a bad guy/employee hacking your system, but also protecting from accidental damage. A new guy or someone experienced with little knowledge about a system that accidentally calls a wrong endpoint (= delete account) while the scope should be only "read/list" for example. Client Credentials does NOT exclude using scopes - it just says that service A can "trust" service B. It doesn't say -> it should trust service B for everything by default. The solution is there: scopes. PS: not every employee has the secrets necessary. Maybe a very restricted group? ;) – Markon Aug 10 '23 at 09:05
  • @Markon - Client Credentials are for machine-to-machine authorization, not user authorization. You grant the credentials the machine requires and no more. If a user does not know how to properly use/configure the credentials or makes mistakes that is a different problem to manage. – John Hanley Aug 10 '23 at 16:47
  • Have you ever heard of the least-privilege principle? You never give some service/role more permissions than needed. In this case you're giving a machine more permissions than required - while all you need to do is to define the scopes. I could counter-argue by saying: if it's "just" machine-to-machine, why not to give *all* possible permissions for all services in the system? If someone configures or misuses the service is actually the same problem: assume that the network is/can be compromised, always; give less permissions, make permissions as fine-grained as possible, etc. – Markon Aug 17 '23 at 09:52
  • @Markon - Post your own answer. I will comment on your answer. – John Hanley Aug 17 '23 at 15:24