#talk-hydra
Title
# talk-hydra
b
best-shampoo-20854
11/23/2021, 1:35 PMHi 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
clean-hamburger-91078
11/23/2021, 2:22 PMHydra 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
best-shampoo-20854
11/23/2021, 2:59 PMbut 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
limited-tent-11422
11/23/2021, 3:39 PMEvery 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
best-shampoo-20854
11/23/2021, 3:45 PMsure, 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
limited-tent-11422
11/23/2021, 4:13 PMthis is outside oauth2 and should be done by some kind of ACL/RBAC
look at https://github.com/ory/keto
b
best-shampoo-20854
11/23/2021, 4:28 PMwouldn'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
limited-tent-11422
11/23/2021, 4:33 PMnothing stops from having client id as an ACL subject 🙂
b
best-shampoo-20854
11/23/2021, 4:33 PMah!
That seems to be a clean solution indeed
c
clean-hamburger-91078
11/24/2021, 7:14 AMAnyway 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👍 1
2 Views