search

logto-io / logto

🧑‍🚀 The better identity infrastructure for developers and the open-source alternative to Auth0.
https://logto.io
Mozilla Public License 2.0
8.35k stars 408 forks source link

feature request: Claims for fine grained authentication #5107

Open steve-o opened 9 months ago

steve-o commented 9 months ago

What problem did you meet?

REF: https://curity.io/resources/learn/using-claims-in-apis/ A system with scopes read:invoice and write:invoice for coarse grained access control wants to limit access to a specific invoice for reading or writing, thus a claim of invoice:xyz could be presented in addition to the scope and audience. The sub is identity of the user submitting the API to enable an audit log.

How in the present Logto would one implement fine grained access control?

Describe what you'd like Logto to have

The ability to add custom claims to an access token that can be used to implement fine grained access control.

Example: There is a server https://dam.example.com (the aud or Resource Server), there is a coarse scope of read:asset, and fine grain control of the asset ID, bf282b31-4829-4fc1-a416-e0142d5ca7b5, etc.

github-actions[bot] commented 8 months ago

This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

charIeszhao commented 8 months ago

Thanks for the request.

Let me clarify one thing: Is the fine-grained custom claim dynamic? I assume the answer is yes. But if that's the case, then how do we configure it to access token?

Let's take invoice:xyz for example, since Logto doesn't manage your invoice, how do we map the xyz to an actual invoice ID? We can create dynamic custom claims and insert user table properties, though. E.g. read:user.id

steve-o commented 8 months ago

My understanding from Curity is that one initiates an OAuth Token Exchange with the desired claim. Curity uses a large mapping system component as a foundation of this feature.

So one accesses an app server with an authorization code and that server requests tokens on your behalf per API call with the required granularity.

It is not obvious how the claims are managed to the user, especially with dynamic resources.

charIeszhao commented 8 months ago

We'll take a look and explore the possibilities. Team is planning to support adding custom claims to JWT tokens, however, we're not sure if the dynamic custom claims is doable at this point.

steve-o commented 8 months ago

Open FGA seems to be the answer, Okta announced early access to their implementation today.

https://openfga.dev/