2

When building an OAuth 2 server, is there anything wrong with associating scopes to users? Essentially allowing scopes to act as your applications roles?

I've looked at the RFC but can't seem to find any guidance on this.

The use case for a flow would be something like this:

                   A client requests an access token.
                                  |
                                  ↓
             On the server side: it checks to see if the user 
                 is able to receive the requested scope(s). 
                       ⁄                              \
                     ↙                                 ↘
               Check Passes:                       Check Fails:
                     |                                 |
                     ↓                                 ↓
           Server issues token.           Server denies request for token.

Some more visual context, this is a SQL data representation:

enter image description here

Community
  • 1
  • 1
Kirill Fuchs
  • 13,446
  • 4
  • 42
  • 72

1 Answers1

2

The definition of scopes is out of scope (!) for the OAuth 2.0 spec itself. Typically scopes represent application permissions or roles indeed bases on shared understanding between the Authorization Server, the Resource Server and possibly the client. What you describe is a common use case for most OAuth 2.0 grants, such as the Authorization Code grant where an application (client) will act on behalf of a user, inheriting a (optionally limited) set of permissions that the user grants to the application, all within the powers that the user itself has.

Hans Z.
  • 50,496
  • 12
  • 102
  • 115