https://www.ory.sh/ logo
Join Slack
Powered by
I know this is slightly out of scope for Hydra/oau...
# talk-hydra
m
I know this is slightly out of scope for Hydra/oauth, but I'm looking for some thoughts from experts in the field to find the best design. We have an authn/z model where users are granted access to several tenants, but oauth tokens should be constrained to a single user-tenant combination. AFAIK a consent session is uniquely identified by a subject and a client_id, and it's not possible to add more dimensions to that to let one user have several open consent sessions with different contexts (i.e. tenant_id). Now, say someone had created a simplified frontend, authorizing via Hydra; they want to allow the user to switch tenants without revoking the previous consent session. How would you go about that?
m
Hey @mysterious-rose-44236 apologies for the late answer, but I couldnt quite wrap my head around your use case. Maybe it is something that Ory Keto (our AuthZ solution: https://www.ory.sh/docs/keto/modeling/create-permission-model) would be a good fit for.
m
I actually had a look at Keto, but I this is more a authn case than authn. Consider the following. Client is a Hydra oauth client A workspace contains Documents User has access to Workspace A and Workspace B User grants Client 
document.read
on Workspace A User grants Client 
document.read
on Workspace B User wants to revoke Clients permissions (aka consent session) from Workspace A, but not from Workspace B
So my question is how to design that. My immediate thought was to make the subject scoped, i.e.
Copy code
{
  "sub": "john@workspaceA"
}
But I want to scope the login session to the user, ie 
{"sub": "john"}
Another thought was putting the Workspace ID into the consent sessions 
session.access_token
property and selectively revoke that specific consent session; but afaik, it is not possible to revoke a single consent session. You can only revoke all sessions for a specific client; which, in my case, would also revoke access to Workspace B.
m
Hey @mysterious-rose-44236 apologies for the late answer. Hmm but your example with “revoking permissions” and granting permissions does sound like an AuthZ usecase. Do users grant these permissions to a third party or is that between you and your users? In that case I think OAUth2 is a good fit, otherwise have a look at Ory Kratos/Keto. See this for an opinionated overview of when you should use OAuth2: https://www.ory.sh/oauth2-openid-connect-do-you-need-use-cases-examples/
m
Don't worry, I realize it's community support, so theres no SLA 😄 I'm just super grateful you even have a Slack!
They do grant it to a third party. This is definitely a case for oauth, no doubt. This is more of a question on how consent sessions are remembered. I don't agree that this is in the authz layer. I'm not trying to solve what a client has access to, but if it has access altogether. If we just temporarily forget about the scopes concept, we can simplify the example to: Client is a specific Hydra oauth client (third party 'app' wanting to access resources within workspaces) User has access to Workspace A and Workspace B User grants Client on Workspace A User grants Client on Workspace B User wants to revoke Clients permissions (aka consent session) from Workspace A, but not from Workspace B
Technically (and business logic-wise), the user is not the resource owner. The workspace is. That leads me to think that in terms of Oauth, the 
sub
should probably be the Workspace ID, and then the "Access granter" (i.e. the user) could be stored in the session metadata. That also solves another headache of mine; being able to list all "apps" installed in a workspace, and have admins of that workspace uninstall/remove apps. I'm using these terms to view it from the customers perspective: • App: An Oauth client • "Installed app": an oauth client that has an active consent session and/or token • "Uninstalling an app": Revoking a clients consent session and active tokens
A major point here is that workspaces do not "belong" to users; users are just members of workspaces.
One example of this pattern in the wild is Shopify Apps. When you install an app, you choose which shop to install it on (i.e. acme-inc.myshopify.com), and all other users who has access to that Shopify shop can then see, use and uninstall that 'app' (which is just an oauth client). That means that the resource owner is technically the shop, not the user. If you then head over to shoe-shine-inc.myshopify.com, which you also have access to (with the same user account), you can install the same app on that shop; you're presented with the oauth consent screen again, so thats a completely separate consent session even though it's the same user and oauth client. My hunch is that it's not possible to recreate that pattern with Hydra.
I'll probably need to make my login UI two-staged; one which logs in the unified user, and afterwards letting the user choose which workspace they want to interact with, then accepting the login request with a sub 
userA@workspaceA
, always sending Remember: false and deferring the 'remember login' logic to the login UI (even though it's discouraged).
I'm slowly rubber ducking myself here. I think the sub is definitely the workspace, because the workspace is the resource owner.
2 Views
Open in Slack
PreviousNext
Powered by