Authorize access to URLs and HTTP Methods

The OAuth2 access tokens do not contain user-ids and roles, in the traditional sense, for authorizing access to resources. Although a user-id exists in a self-contained access token for logging and audit trail use, it is not used outside of that scope. Instead, OAuth2 uses the notion of client-id and scope to authorize a particular client (application) to use the resource server and to define the operations that a resource owner has authorized the resource server to perform for that client.

The traditional Spring Security Role-Based-Authorization (RBA) and its configuration do not apply to OAuth2. Instead, a new form of authorization access control and configuration is used by Spring Security to grant the right to perform an operation.

Basically, OAuth2 authorization is configured using a file named WEB-INF/oeablSecurityJWT.csv. This file performs the same basic function as the traditional RBA configuration file, oeablSecurity.csv.

The format of the oeablSecurityJWT.csv file has the same three double-quote fields that hold the URI, HTTP-method, and access-control specification. The first two fields (URI & HTTP-method) are the same as in the RBA’s oeablSecurity.csv file. The third field holding the access-control specification uses a different Spring Security expression language.

The expression language used for traditional RBA and OAuth2 scope authorization share the concept of testing whether a security token has been granted a name, and that name corresponds to granting access to some process, function, or data. A name is just a name, so long as whoever grants the name and the resource server who associates it with access to some resource agree on what the name is.

In the case of OAuth2, the name is an OAuth2 scope that the authorization server inserts into the self-contained access token as directed by the resource owner. So the same rules apply as with RBA: the resource server’s configuration must use the scope names configured and used by the authorization server. In production environments, that information must be obtained by the administrator.

An OAuth2 access-control expression has the following format:

access-control-expr := “ oauth2-spec [ { or | and } oauth2-spec ... ] “

oauth2-spec = #oauth2.test( ‘value’ [, ‘value’... ] )

The following table is a list of tests:

denyOAuthClient( )	Denies access to all OAuth2 clients, but allows other types of clients
hasAnyAuthority(...)	Checks if the client has at least one of the specified authorities
hasAnyScope(‘name’ ...)	Checks if the OAuth2 client has any named scope specified
hasAnyScopeMatching( ‘reg-ex’...)	Checks if the OAuth2 client has one of the scopes matching a specified regex expression
hasAuthority(‘name’)	Checks if the OAuth2 client has a given authority
hasScope(‘name’)	Checks if the OAuth2 client has the named scope specified
hasScopeMatching(‘reg-ex’)	Checks if the OAuth2 client has a named scope matching a specified regex expression
isClient( )	Checks if the request is from an OAuth2 client (and not another type of user)
isOAuth( )	Permits only OAuth2 type requests
isUser( )	Checks if the current request is from a user and not from an OAuth2 client

Each test returns true or false, and the entire expression must return true for the resource server to grant access.