https://www.ory.sh/ logo
Join Slack
Powered by
Hi there, just getting started with hydra (and oau...
# talk-hydra
b
Hi there, just getting started with hydra (and oauth in general). Looking good so far! However I can't seem to find anything about limiting resource access, i.e. like how github lets you select which repositories you want the client to see rather than just setting read/write scopes for everything. I wonder if there's a hydra or oauth approach for this or are you supposed to roll your own solution?
c
Hydra is just an OIDC protocol "adapter", not the authN/authZ solution, it takes part of implementing everything related to OAuth2/OIDC, but delegates actual "login" (authN) and "consent" (authZ) processes to your own implementation
So you get /authorize, /token etc. on Hydra, but actual login/password/select repository/grant read/write access is up to you and your app
b
but should my /consent handler add the list of selected resources to, say, a key under the session access_token? or am I expected to store this within my application db?
I mean, it seems to be very convenient to be able to retrieve this data using the introspection API but I see the login-consent-logout repo specifically mentions that I should avoid "sensitive information" there...
looks like there's no such thing as a "scoped scope" in oauth, so if I wanted to concede read-only access to some repos and read-write acces to others I wouldn't be able to rely on scopes anyway, further adding bloat to access_token if I go with that route.
It seems like the right way to do this would be indeed within my app db, linking the user id and resources with a given client id (or should I use the session id?) to a set of consents. still that kind of implies I could provide an interface to update these consents without communicating with the client, which goes against what I've been seeing so far. still on the github example, it asks the user to do the the authorization flow once again (which always led me to believe there was some kind of involvement from the oauth side).
l
Every Hydra client has a set of allowed scopes.
When you create a client you can configure which ones are allowed for client to request and based on these scopes you can do authorization.
b
sure, but scopes don't cover granular resource consents. i.e. resource owner A wants to concede client B with read_repo scope for all repos but write_repo scope only for repo X and Y
l
this is outside oauth2 and should be done by some kind of ACL/RBAC
b
wouldn't ACL sit at the next layer though? I mean, I know I need to ensure the user can't do funny things but how would ACL fit the oauth consent context?
l
nothing stops from having client id as an ACL subject 🙂
b
ah!
That seems to be a clean solution indeed
c
Anyway you could add any custom claims to id_token and access_token (to it's JSON representation that is returned via introspection, of course) with PUTting them to 
session
in https://www.ory.sh/hydra/docs/concepts/consent/#accepting-the-consent-flow
👍 1
2 Views
Open in Slack
PreviousNext
Powered by