Enforce use of scopes?

[aeneasr]

Scopes are something that is thrown a little bit under the table in most OAuth2 tutorials but scopes are a very important part of OAuth2, as OAuth2 is a delegation protocol for a limited scope. Issuing tokens that are allowed to do anything by default ist bad practice.

Forcing developers to define and use scopes countermeasures that but it is also another thing one has to think about when using this library.

What do you prefer? Making it easy to use scopes or enforcing to use scopes?

[leetal]

I personally would like the scopes to be enforced. A way of mitigating the developer actions would be to always have a "basic" scope defined in fosite (enforced) and delegate the use and creation of other scopes via a scope handler to the developer. As long as the client data and resource owner data is exposed internally in the hander, the developer can choose what information to return based on the scopes defined. There are very few companies that doesn't enforce at least a basic scope by default when using OAuth2.

[aeneasr]

Sounds like a good idea! I think "basic" or "core" should be good basic scope names but I will make this configurable.

[tacurran]

While I would also prefer scope enforcement, there are some issues with
today's Oauth usability in numerous situations:

1. third party access to end user data i.e. privacy protection
2. incrementing scope privileges, i.e. every increment in authentication
   could require a new token
3. managing large number of privileges, some of them implied, in one call,
   i.e. make every privilege or set thereof subject to an explicit
   parameterised with the privilege call
   For microservices it may make sense to consider limiting the number and
   granularity of permissions, still registering each service as a separate
   client. Perhaps that would even be a design aspiration leading to more
   specific and smaller scope micro services? Without violating the principles
   of rfc6749, it would also make sense to plan some kind of federation
   principles i.e. in a hybrid cloud case there may be other ID management
   systems working in each cloud and there would be a need to federate the ID
   across the two systems (see
   http://link.springer.com/chapter/10.1007/978-3-642-10665-1_15#page-1).
   Building in a security domain template or resource, that can also be
   signed, and passed as a string of privileges might also make it harder for
   another program or app to use implied privileges.
   Perhaps we should take this offline? It may be out of scope for the beta.

On Sun, Jan 10, 2016 at 1:12 PM, Aeneas notifications@github.com wrote:

Sounds like a good idea! I think "basic" or "core" should be good basic
scope names but I will make this configurable.

—
Reply to this email directly or view it on GitHub
#14 (comment).

[aeneasr]

Thanks for your thoughts, the issues you mention are very valid. As you mentioned I too think that scopes should not be too specific or granular. It might make sense registering scopes by theirendpoint urls like Google is doing it.

I am not sure if I understood the micro services part corretly however. Usually, the micro services act as resource providers which themselves do not require client credentials. Resource providers need simply a method to validate a token. This method could however be an RESTful enpoint requiring valid client credentials but it is not specified to my knowledge. This endpoint is something that is currently drafted at Hydra (would love feedback on that, too!)

To reduce scopes, a resource server could implement the following flow:

1. Check if bearer token is set, if not reject request with 401 unauthorized
2. Validate bearer token and fetch additional metadata (username, scopes). if network is down or some other issue respond with 500 internal server error
3. Check if the services endpoint url (e.g. resource-foo-service.foobarapp.com) exists in the scopes, if not reject the token and reject request with 403 forbidden
4. Make an sophisticted access decision using e.g. Ladon. If invalid, reject request with 403 forbidden
5. Serve the request

What do you think?

Regarding ID federation (commonly known as connectors or remote identity providers): This will be possible because developers can define their own authorize and token endpoint behaviour by implementing these interfaces

Let me know if I misunderstood something, I will give the springer link a read in a few

[tacurran]

Regarding the microservice, I think it may be an option to restrict a
service to one scope only, meaning that additional services would be needed
to increment an existing scope in use, or add another complete scope. This
idea is not yet baked, I need to do a little more research.

On Sun, Jan 10, 2016 at 6:37 PM, Aeneas notifications@github.com wrote:

Thanks for your thoughts, the issues you mention are very valid. As you
mentioned I too think that scopes should not be too specific or granular.
It might make sense registering scopes as url endpoint like Google does it.

I am not sure if I understood the micro services part corretly however.
Usually, the micro services act as resource providers which themselves do
not require client credentials. Resource providers need simply a method to
validate a token. This method could however be an RESTful enpoint requiring
valid client credentials.

To reduce scopes, a resource server could implement the following flow:

1. Check if bearer token is set, if not reject request with 401
   unauthorized
2. Validate bearer token and fetch additional metadata (username, scopes).
   if network is down or some other issue respond with 500 internal server
   error
3. Check if the services endpoint url (e.g.
   resource-foo-service.foobarapp.com) exists in the scopes, if not reject
   the token and reject request with 403 forbidden
4. Make an sophisticted access decision using e.g. Ladon
   https://github.com/ory-am/ladon. If invalid, reject request with 403
   forbidden
5. Serve the request

What do you think?

Regarding ID federation (commonly known as connectors or remote identity
providers): This will be possible because developers can define their own
authorize and token endpoint behaviour by implementing these interfaces
https://github.com/ory-am/fosite/blob/unstaged/handler.go

Let me know if I misunderstood something, I will give the springer link a
read in a few

—
Reply to this email directly or view it on GitHub
#14 (comment).

[aeneasr]

Feel free to keep posting, I marked it close because it is now implemented in Fosite. That doesn't imply that further discussion is not welcomed though!