On Thu, 28 Mar 2024 at 21:53, brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > On 2024-03-28 at 08:00:00, M Hickford wrote: > > Is this design sufficiently flexible for OAuth DPoP (RFC 9449), or at > > least to make it work in future? > > > > OAuth 2.0 Demonstrating Proof of Possession describes "a mechanism for > > sender-constraining OAuth 2.0 tokens via a proof-of-possession > > mechanism on the application level. This mechanism allows for the > > detection of replay attacks with access and refresh tokens." > > https://www.rfc-editor.org/rfc/rfc9449.html > > > > Popular hosts GitHub, GitLab, Bitbucket and Gitea already support > > OAuth. OAuth DPoP "provides a general defense in depth against the > > impact of unanticipated token leakage". Motivated by a 2022 GitHub > > attack involving stolen tokens > > (https://github.blog/2022-04-15-security-alert-stolen-oauth-user-tokens/), > > some hosts are already experimenting with it. > > https://lore.kernel.org/git/20230128142827.17397-1-mirth.hickford@xxxxxxxxx/ > > > > In particular, the http request has to include both Authorization and > > DPoP headers https://www.rfc-editor.org/rfc/rfc9449.html#name-the-dpop-authentication-sch. > > The latter depends on timestamp and a server-optional challenge in a > > DPoP-Nonce header. > > https://www.rfc-editor.org/rfc/rfc9449.html#name-resource-server-provided-no. > > It will likely be sufficient with further extensions. Right now, we > don't have a way to provide DPoP headers or send nonces to the client. > However, there's no reason we cannot provide that functionality in the > future via additional key/value pairs, in which case this design should > be fine. > > This would have been sufficient if the OAuth working group had not added > extra additional headers that other authentication mechanisms would have > simply put (and, honestly, should have been put) in the WWW-Authenticate > and Authorization headers, but alas, we can't change it now. > > Since I think this gets us at least part of the way where we need to be, > I think we should be able to keep it for now and implement the extra > support for DPoP later. Fantastic, thanks for considering this. I look forward to sharing a test Git remote with OAuth DPoP when I can figure out how. > -- > brian m. carlson (they/them or he/him) > Toronto, Ontario, CA
