cloudfoundry-uaa - Difference between scope and authority in UAA

Question

In UAA There are two Concepts, Authority and Scope.

These concepts seems to overlap. I would like to know exact difference and purpose

For example , oauth.login

Answer 1

Scopes are permissions of an OAuth Client acting on behalf of a User. They are granted after obtaining a user token with one of the following grant types: auth_code, password, implicit. Scopes signify what the application is allowed to access on User's behalf (referred to as delegated authorisation).

Authorities are permissions of an OAuth Client acting on its own behalf and there is no User involvement. They are granted after obtaining a client token with grant_type of client_credentials. Typical use is an Application or API trying to access a resource with its own credentials without user involvement.

In UAA , oauth.login is a system level permission and was being used by the legacy implementation of the login-server project (When UAA and Login Server were separate components). This permission allows admin level access for login server.

Answer 2

1) authorities and roles are spring-security wording for permissions. It is not defined in OAuth2 specs.

2) scopes are defined by OAuth2. It is intended to define what the end-user allowed each client to do on its behalf (information from authorization-server to resource-servers).

As a consequence, authorities granted to a client should always be a subset of end-user ones : all possible scopes => all of user authorities ; the less scopes, the less authorites.

One trick, on "client" OAuth2 flow, the client is the end-user => scopes make no sense in that case (the client is not authenticating on behalf of someone, but in its own name).

Default OAuth2 spring-security converters turn scopes into authorities. To me this introduces a lot of confusion and should not happen. Scope claim should instead be used to filter end-user authorities.

Latest requires to write and configure your own authorities converter which is already possible for JWT but not yet for introspection (should come, a ticket is opened for that)

Also, nothing in OAuth2 specs requires permissions (spring authorities and roles) to be contained (using a private claim) in the token or managed by the authorization-server. It is legit for a resource server to retrieve it for instance from a database using the subject claim and then "scope" it (filter end-user authorities according to the scopes granted to the client).