Re: [OAUTH-WG] draft-hardt-oauth-mutual-01

[Dick Hardt <[e-mail]>]

and inline again ... :)

On Tue, Jan 16, 2018 at 1:50 PM, Brian Campbell <[e-mail]>
wrote:

> Inline also...
>
> On Tue, Jan 16, 2018 at 2:25 PM, Dick Hardt <[e-mail]> wrote:
>
>> Comments inline ...
>>
>> On Tue, Jan 16, 2018 at 1:11 PM, Brian Campbell <
>> [e-mail]> wrote:
>>
>>>
>>> *On client_id:*
>>> With the authorization_code code grant (sec
>>> https://tools.ietf.org/html/rfc6749#section-4.1.3), the client_id is
>>> "REQUIRED, if the client is not authenticating with the authorization
>>> server as described in Section 3.2.1."  And Section 3.2.1 (see
>>> https://tools.ietf.org/html/rfc6749#section-3.2.1) kinda describes why
>>> it is required for unauthenticated clients:
>>>
>>>    "A client MAY use the "client_id" request parameter to identify itself
>>>    when sending requests to the token endpoint.  In the
>>>    "authorization_code" "grant_type" request to the token endpoint, an
>>>    unauthenticated client MUST send its "client_id" to prevent itself
>>>    from inadvertently accepting a code intended for a client with a
>>>    different "client_id".  This protects the client from substitution of
>>>    the authentication code.  (It provides no additional security for the
>>>    protected resource.)"
>>>
>>> So it's there to let the AS detect code substitution and protect public
>>> clients from it. I don't think that the same situation applies to the code
>>> that's created and pushed with this reciprocal flow.
>>>
>>
>> The client_id is linked to the access token for reciprocal, and to the
>> client secret. The client_id let's the AS know which secret it should be
>> comparing, and to verify the access token really does belong to the
>> client_id.
>>
>> Is there a reason you would NOT want to pass the client_id?
>>
>>
> I was aiming for consistency with of the other token endpoint calls that
> don't require the parameter when the client id can be found out from
> whatever method the client is authenticating with. That's all. But I guess
> it really doesn't hurt either so requiring it is fine too. Sorry for
> dragging that all into a rabbit hole.
>

It was a good question, and worth exploring. I think there are clear
advantages from a security point of view.


>
>
>
>>
>>
>>>
>>>
>>>
>>> *On the response:*
>>> The extension grants section (see https://tools.ietf.org/html/rf
>>> c6749#section-4.5) of OAuth says,
>>>
>>>    "If the access token request is valid and authorized, the
>>>    authorization server issues an access token and optional refresh
>>>    token as described in Section 5.1 <https://tools.ietf.org/html/rfc6749#section-5.1>.  If the request failed client
>>>    authentication or is invalid, the authorization server returns an
>>>    error response as described in Section 5.2 <https://tools.ietf.org/html/rfc6749#section-5.2>."
>>>
>>> So I'd sorta expect the reciprocal code grant to try and comply with
>>> those responses. Mostly for consistency and, while it doesn't exactly fit,
>>> for what is already there like error codes.  Or give more detail about why
>>> it's doing something different and how different looks (like the response
>>> body). But maybe that's overly pedantic and just 200/400 are enough. I
>>> dunno.
>>>
>>
>> But it is not an access token request, and I think having it look like an
>> access token request will be confusing to developers. It is the opposite of
>> an access token request. This really is a back channel version of the
>> Authorization Response https://tools.ietf.org/html/rfc6749#section-4.1.2,
>> which of course has no response codes.
>>
>
> Perhaps a little more explanation along those lines would be useful. I
> agree with the sentiment. I was just trying to stay within the lines of the
> OAuth extension framework. But, yeah, this flow is different.
>

good suggestion to call out how reciprocal is different from other flows.
Will note that for the next draft. Thanks!