>
> According to this specification, a client's request must contain a
>    valid client_id, in the case of a public client, or valid client
>    credentials, in the case of a confidential client.
>
>

On Thu, Sep 2, 2021 at 6:22 PM Warren Parad <[email protected]> wrote:

> Can you point out where it says that, I think I must of missed it.
>
> Warren Parad
>
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress <https://authress.io/>.
>
>
> On Thu, Sep 2, 2021 at 10:21 AM Ash Narayanan <[email protected]>
> wrote:
>
>> Hey Warren,
>>
>> 7009 states that you need to pass just the client_id for public clients,
>> so if:
>>
>>> The client_id isn't necessary.
>>>
>>
>> Then obviously something about 7009 needs to change.
>>
>> Whichever angle you look at, 7009 needs to change.
>>
>> On Thu, Sep 2, 2021 at 5:16 PM Warren Parad <[email protected]> wrote:
>>
>>> Great, then let's fix 6749 not this one. The client_id isn't necessary.
>>>
>>> And then wouldn't 7009 not need to be changed because it already says
>>> you don't need to pass any authorization for public clients?
>>>
>>> For credentialled client issued grants, refresh tokens, and access
>>> tokens, these must not be able to be revoked without client credentials, so
>>> using the refresh token or access token only for all other client types
>>> must not be supported.
>>>
>>> On Thu, Sep 2, 2021, 08:52 Ash Narayanan <[email protected]>
>>> wrote:
>>>
>>>> Hi Warren,
>>>>
>>>> If you are referring to the client_id as arbitrary information, then
>>>> the same would also be true for refresh requests to the token endpoint from
>>>> public clients.  As per 6749, you need to pass the client_id along with the
>>>> refresh token. The client_id adds no additional security.
>>>>
>>>> But really, the whole point I've been trying to make from the start is
>>>> that the token itself should be the only form of 'security' needed...as
>>>> that's the point of OAuth.
>>>>
>>>> Regardless, 7009 needs to be made obsolete by a newer RFC.
>>>>
>>>> Ash
>>>>
>>>> On Thu, Sep 2, 2021 at 4:41 PM Warren Parad <[email protected]> wrote:
>>>>
>>>>> What's the point in passing arbitrary other information that is
>>>>> already known by the AS and does not provide the level of security
>>>>> necessary to prevent abuse of the revocation endpoint?
>>>>>
>>>>> On Thu, Sep 2, 2021, 01:12 Ash Narayanan <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hi Thomas,
>>>>>>
>>>>>> The approach you've suggested sounds good. Passing just the client_id
>>>>>> along with the token and type (regardless of client type) would be
>>>>>> consistent with how refresh_token requests are structured. As long as the
>>>>>> new RFC obsoletes this one.
>>>>>>
>>>>>> Ash
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [email protected]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to