Comments (6)
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.
from fosite.
Sounds like a good idea! I think "basic" or "core" should be good basic scope names but I will make this configurable.
from fosite.
While I would also prefer scope enforcement, there are some issues with
today's Oauth usability in numerous situations:
- third party access to end user data i.e. privacy protection
- incrementing scope privileges, i.e. every increment in authentication
could require a new token - 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 [email protected] 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).
from fosite.
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:
- Check if bearer token is set, if not reject request with 401 unauthorized
- Validate bearer token and fetch additional metadata (username, scopes). if network is down or some other issue respond with 500 internal server error
- 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
- Make an sophisticted access decision using e.g. Ladon. If invalid, reject request with 403 forbidden
- 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
from fosite.
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 [email protected] 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:
- Check if bearer token is set, if not reject request with 401
unauthorized- Validate bearer token and fetch additional metadata (username, scopes).
if network is down or some other issue respond with 500 internal server
error- 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- Make an sophisticted access decision using e.g. Ladon
https://github.com/ory-am/ladon. If invalid, reject request with 403
forbidden- 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.goLet 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).
from fosite.
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!
from fosite.
Related Issues (20)
- Allow revoking access token without revoking refresh token HOT 2
- authorize_helper.isLoopbackAddress has flaws HOT 1
- clientCredentialsFromRequest should not expect Basic Authorization terms being URL Escaped HOT 2
- Refresh token flow handler does not set the original request ID in the handler early enough
- use mattn/go-sqlite3 v2.0.3+incompatible no the new version HOT 6
- Failed to decode `id_token_hint` when using different signer for `id_token` and others
- `iat` field in access token (JWT) issued as part of `refresh_token` grant. HOT 8
- Concurrent requests for token endpoint on auth-code flow with same code succeed. HOT 7
- Can not run the example code
- OIDC callback is always HTTPS, even when entered as HTTP HOT 1
- DefaultSigner should support key rotation
- Support per-client signing algorithm HOT 8
- Make prefix used in HMACSHAStrategy configurable
- openid session storage should be deleted when the authcode is exchanged HOT 9
- private_key_jwt assetion tokens can have unbounded expiration which can fill data store HOT 3
- NewDefaultSession's SetSubject should set IDTokenClaims as well
- Consider upgrading to github.com/go-jose/go-jose/v4
- id_token_hint should not persist to storage HOT 2
- Unable to obtain expiration time of refresh tokens HOT 1
- Why does HMACStrategy.Generate uses a lock? HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fosite.