Using scopes as roles in Spring Security OAuth2 (provider)

Question

Let's consider a fairly simple hypothetical application where users can read or write posts.

Some users can read and write articles while some others can only read them. With Spring Security (3.2.1) I modeled this by having 2 roles:

• ROLE_WRITE: this role grants users access to writing posts.
• ROLE_READ: this role grants users access to reading posts.

Implementing this with Spring security is fairly straightforward...

Now I want to also allow third-party apps to read and write posts on behalf of users by implementing an OAuth2 provider using Spring Security OAuth (version 2.0.0.M3 ATM).

During the authorization step, the app asks the user whether they are willing to grant the right to read and/or write posts on their behalf. The user here is granting scopes here (not roles).

Then when the OAuth2 consumer calls my REST API, Spring Sec OAuth authorizes the token granted and creates an authentication containing the user with all their roles and only the scopes granted.

The problem (and the question) is that I now have to write different security logic depending on whether the API is called by a user normally authenticated (just check the roles) or whether it's called through OAuth2 (check roles + scopes).

Is it possible to "merge" the concepts of roles and scopes in Spring Security OAuth2 so that during the authorization step, the user grants the app a subset of the roles they have (and have the OAuth2 authentication only report these in the granted authorities)? That way when the 3rd party app makes an API call, the roles on the authentication are the ones granted? That way I don't have to write any OAuth2 specific security logic.

Answer 1

Scopes (and roles) are arbitrary strings, so there is no problem if you want to make then the same. To make the access rule declarations identical you could write an ExpressionHandler that tested authorities or scopes with the same values depending on the type of Authentication it found.

A different approach suggests itself after you read the comments: add a custom TokenStore or ResourceServerTokenServices. These are easily accessible extension points and would permit modifying the OAuth2Authentication so that its granted authorities were the same as the scopes.

My preference, however, is to control the allowed scopes using a OAuth2RequestFactory, limiting them at the point of the token grant to values that are consistent with the user's authorities.