[Openid-specs-fapi] Comments on Grant Management for OAuth 2.0
taka at authlete.com
Fri Aug 14 05:01:09 UTC 2020
Well, I noticed that some purposes of "Grant Management for OAuth 2.0" are
similar to ones of "OAuth 2.0 Incremental Authorization" (
https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-authz/ ). How
are the two specifications related? Is "Grant Management for OAuth 2.0"
trying to replace "OAuth 2.0 Incremental Authorization" or become
complementary to each other? (I'm sorry I don't know the background of
development of "Grant Management for OAuth 2.0").
On Thu, Aug 13, 2020 at 6:04 PM Takahiko Kawasaki <taka at authlete.com> wrote:
> Explanation in detail is as follows.
> The current specification will be able to make UI/UX better only while a
> resource owner is using an instance (Instance A) of a particular client
> application on a single device (Device A). However, when the resource owner
> tries to use the same client application on another different device
> (Device B) and give authorization to another instance (Instance B) of the
> client application on the device, she will be asked whether to give
> privileges to the instance B even if she has already given the same
> privileges to the instance A. This will happen because the authorization
> server will issue a different grant ID to each client application instance.
> I'm wondering whether this behavior is what the specification wants to
> achieve or not.
> When the instance A on the device A requires another new privilege with
> grant_management_mode=update, the authorization server will show only the
> new privilege to her for confirmation and issues a new access token
> associated with the new privilege and other privileges that have already
> been granted. The specification ensures that the authorization server
> behaves in this way, but many service providers in the wild have already
> implemented a similar behavior. Such implementations will be able to issue
> access tokens with accumulated privileges when the instance B on the device
> B requires another new privilege, too. However, the specification will,
> rather, prohibit implementations from behaving in that way because multiple
> grant IDs are issued to one combination of a client application and a
> resource owner.
> It may be possible to say that multiple grant IDs can cover use cases
> where each client application instance wants to have different privileges
> even when the resource owner is identical. However, most of such use cases
> can be covered by access/refresh tokens. This is the reason I said
> "benefits gained won't be so big compared to efforts". To be concrete,
> benefits can be gained mainly only when a client application requests
> additional privileges later. But the difference would be just the one
> between (1) listing all necessary scopes every time in an authorization
> request and (2) listing additional scopes only with a grant_id. I'm afraid
> client application developers won't find great benefits in the latter (2)
> compared to the traditional (1).
> grant_management_mode=update will enable client applications to specify
> scopes for immediate use only but get an access token with accumulated
> privileges. This behavior is new. However, if each client application
> instance is issued a different grant ID and expected to manage it
> independently, there are no big differences between grant IDs and
> My guess is that what people want to achieve by the new specification is
> "grant management per combination of a client application and a resource
> owner". If my guess is not wrong, I recommend not issuing multiple grant
> IDs to a particular combination of a client application and a resource
> owner. And, in turn, I would say that the new behavior would be able to be
> achieved without need to issue grant IDs.
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
> On Thu, Aug 13, 2020 at 12:05 AM Takahiko Kawasaki <taka at authlete.com>
>> My comments on "Grant Management for OAuth 2.0" (
>> ) are as follows.
>>  Multiple Grant IDs
>> If the spec allows multiple grant IDs to be issued to a particular
>> combination of a client application and a resource owner, there are no big
>> differences between grant IDs and access/refresh tokens. I'm afraid that
>> benefits gained won't be so big compared to efforts that would have to be
>> made for the introduced complexity.
>>  Single Grant ID (or No Grant ID)
>> If the spec ensures that the number of grant IDs issued to a particular
>> combination of a client application and a resource owner is at most one,
>> the spec can be simpler. I guess it would be possible to omit even issuance
>> of grant IDs. "grant_management_mode=(update|replace)" without "grant_id"
>> would be enough.
>> I don't think another access token is needed to call Grant Management
>> APIs. In other words, I think the same access token that has been issued as
>> a result of an authorization request can be used to call Grant Management
>> APIs. In addition, because an access token has information about a client
>> application and a resource owner, information about a grant ID won't be
>> necessary in the API path or as a request parameter.
>> Best Regards,
>> Takahiko Kawasaki
>> Authlete, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-fapi