Grant anchor
Issue #326
resolved
A grant (identified by a grant_id) shall be a resource associated with the user.
-
At creation, the authorization server will allow the originating client to specify the visibility of the grant:
- CREATING_CLIENT
- ANY_CLIENT
- ListOfClients
-
API shall also allow the originating client to specify corresponding access mode on a per client basis (read, manage, …)
Comments (11)
-
-
reporter
Here is the rationale behind ANY_CLIENT
The grant is a possession of the user. Grant wont be accessed without an authenticated user token. A user willing to use any_sort_of_client to view this grant shall be allowed to do so.
Protection is covered by the user access token.
-
What do you mean with “The grant is a possession of the user.“? A grant is maintained at the AS and is the underpinning of access tokens issued to clients. A user won’t know the id of a grant. So if one client shares the grant id with another client (probably inadvertent via leakage), this client can access the resources covered by this grant without further notice (no consent required). If this is combined with SSO at the AS, there is not even a user authentication happening.
What is the use case for this unlimited sharing of grants?
The only use case I see for grant sharing is, if a certain legal entity has multiple client_ids, e.g. for different apps. Since a consent (grant) is given for a certain legal entity, sharing the grant among technical clients for the same legal entity is fine.
Every other client shall acquire a dedicated consent (grant).
-
reporter
What do you mean with “The grant is a possession of the user.“?
A GRANT is a RESOURCE and the RO is the user.
The visibility of the GRANT as I refer above is related to management of the GRANT and not to the entitlement provided by the GRANT.
What is the use case for this unlimited sharing of grants?
I am not relating to GRANT sharing, but to the access to a GRANT for the purpose of managing that GRANT.
The only use case I see for grant sharing is, if a certain legal entity has multiple client_ids, e.g. for different apps. Since a consent (grant) is given for a certain legal entity, sharing the grant among technical clients for the same legal entity is fine.
GRANT sharing as you mention here refers to the entitlement contained in the GRANT. This is strongly dependent on the GRANT use case. I am not sure this shall be part of a GRANT. management API.
-
Just to make sure I understand correctly. You are talking about what client is allowed to read or revoke a grant. You are not talking about what client is entitled to obtain access tokens based on that grant. Correct?
-
reporter
You are talking about what client is allowed to read or revoke a grant.
I am talking about what client the user can use to revoke a grant, yes.
You are not talking about what client is entitled to obtain access tokens based on that grant. Correct?
Yes…
-
Ok.
I assume the client is supposed to specify the other clients in the authorization request. Since this is a unprotected request through the browser, the client list can be modified in transit, allowing an attacker to add his client to the list. I see the following countermeasures:
- a per client_id whitelist in order to limit the value range
- signed request objects to protect the request in transit
- PAR for the same purpose
I still don’t understand why any client shall be allowed to read and revoke a certain grant. Can you please explain?
-
I think this is related to the grant sharing discussion in https://bitbucket.org/openid/fapi/pull-requests/261 and https://bitbucket.org/openid/fapi/issues/378/sharing-grant_id-among-different-clients
Currently we will keep this out of scope for Implementers Draft 1. Is that Ok to close this issue @Francis Pouatcha @Torsten Lodderstedt ?
-
works for me
-
Fine for me too.
-
- changed status to resolved
Agreed to close the issue
- Log in to comment
I understand 1 and 3 but consider 2) as really dangerous. What is the rationale for this option?