How to design a OAuth2 Resource Server (RS)? Do I even care – shouldn’t there be already several existing open source implementations? Well, not exactly. The only implementation I have found is Authlete. In addition, the OAuth2 specifications are not covering Resource server implementation.
Different things to consider:
- Access token and its format
- Access token scopes
- Actual resource server resource access control mechanism
In OAuth2, you grant a (client) application to access a resource in RS on behalf of the user / resource owner / you. The client needs have an access token in order to access the requested resource. The level of access is defined as scopes, which are part of the OAuth2 standards.
What does a scope mean? Oauth2 scopes are used to express what app can do on behalf of a user. They are used for handling delegation scenarios. Resource endpoints are responsible for combining the incoming scopes and actual user privileges to decide effective permissions and make access control decisions. In a way, scope is a aggregate / interface which is then implemented on RS – and not on the Authorization server (AS)! In AS, clients are managed, all available scopes are managed, and UI for allowing user to give consents are there.
Resource server access control should start with HTTP CRUD access control: i.e. POST, GET, PUT, DELETE. See my other post about organizing REST APIs! Identity of a user comes from a same domain JWT ID Token, so the user information is present. Note that scopes are client specific and they are basically transformed into access control policies! What I mean by this is that actually scopes cover only a subset of all access rights in RS! So what people usually get wrong when designing a RS is that they think that scopes are the basis of controlling access to resources. Unfortunately, I haven’t found any good resources on designing this part – have you?
My Way With Java 