Access Management With OAuth Scopes

Scopes are a concept defined in both the OAuth specification (RFC 6749, Section 3.3) and the OpenID Connect specification (OpenID Connect Core 1.0 incorporating errata set 2, Section 5.4).

Important: OpenID Connect is an identity layer built on top of OAuth, meaning the concept of scopes carries additional significance in the OpenID protocol.

This article focuses specifically on scopes in the context of plain OAuth, as defined in RFC 6749.

What Is a Scope?

The OAuth protocol is designed to enable delegated access. A common example is allowing one website to access resources from another website. For instance, importing your Gmail contacts into LinkedIn.

It is not desirable to give LinkedIn full access to your email account. Instead, the scope of its access should be restricted to just your contacts. That’s the purpose of scopes in OAuth.

Scopes and Tokens

An access token is a vehicle that is used to prove authorization to a resource. As such, there needs to be a relation between a token and its scope.

It is common to think of scope as a claim in a JWT. However, the OAuth specification does not mention claims or JWTs (JSON Web Tokens). There is not necessarily such a thing in a plain OAuth 2.0 implementation. Instead, OAuth 2.0 refers to access tokens as opaque strings, meaning they are not designed to be readable or interpretable. It's important to understand that in the context of OAuth alone, the scope does not necessarily need to be represented within the token as claims.

Instead, the access token must be associated with a scope in some manner. However, the OAuth specification does not define how this association should be achieved. The way scope is encoded or stored within the token is left up to the implementation and is not explicitly specified in the OAuth standard.

How To Request Access With Scopes

When a user authenticates, the client specifies the scope it requires. To obtain authorization, the user is redirected to the /authorize endpoint. This is the beginning of the authorization process.

In contrast to OpenID Connect, the scope parameter is optional in the /authorize URL. If it is not included, the authorization server must assume the client is requesting access to all available scopes. If the client wants a specific subset of scopes, it must explicitly specify them in the `scope` parameter, separated by spaces. The resulting authorization URL would be formatted as follows:

/authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb&scope=documents%3Aread%20calendar%3Aedit

This example requests an access token with the documents:read and calendar:edit scopes. Note that this request will result in an error on an OpenID Connect server, as the openid scope is required in every authorization request to an OpenID Connect server and will work on plain OAuth 2.0 servers only.

Requesting scopes does not mean they are granted. Because of that, the access token request includes the scopes that are not granted.

Our Opinion

In the context of OAuth 2.0, scopes are inherently tied to a token. When you remove the identity aspect of OpenID, it becomes impossible to apply policies to a principal, transforming the OAuth 2.0 server into a pure authorization server. Since OpenID is an additional layer on top of OAuth 2.0, using scopes in this manner is appropriate but not mandatory.

Implementing access management through scopes is neither inherently good nor bad. However, it is important to understand that this approach creates a tight coupling between the authorization server and its client. Whether this is beneficial or problematic depends entirely on the specific context.

As such, Entrypage IDaaS allows scopes to be applied in this way but does not enforce it.