Ah in 5. Security Considerations 👍 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:25 AM Ash Narayanan <ashvinnaraya...@gmail.com> wrote: > 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 <wpa...@rhosys.ch> 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 <ashvinnaraya...@gmail.com> >> 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 <wpa...@rhosys.ch> 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 <ashvinnaraya...@gmail.com> >>>> 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 <wpa...@rhosys.ch> 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 <ashvinnaraya...@gmail.com> >>>>>> 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 >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
