sbp commented on issue #335: URL: https://github.com/apache/tooling-trusted-releases/issues/335#issuecomment-3577553879
Although DPoP tokens can be used without OAuth once issued (§ 7), RFC 9449 § 5 says that tokens must be issued through OAuth. We can use an [RFC 8628](https://datatracker.ietf.org/doc/html/rfc8628) OAuth 2 device grant from the CLI for this, but Authentik, our planned OAuth server, does not yet support DPoP and so we would have to implement the relevant routes in ATR and delegate the actual OAuth component as usual. This would require a more complicated implementation than we were hoping, but should not be any more difficult for users. There is some ambiguity here as to whether or not this is normative, however, because § 6 says: > Other methods of associating a public key with an access token are possible per an agreement by the authorization server and the protected resource; however, they are beyond the scope of this specification. Another consideration is client support. We offer an official ATR CLI, but users may want to authenticate to the ATR API from other programming languages. We already had a request to make a Java client, for example. Most HTTP request libraries across languages allow the addition of custom headers such as those required by DPoP, but constructing the DPoP is not trivial and requires a secure cryptographic library to be used correctly. Moreover, due to the proof lifetime mechanism of § 8, clients must also track extra state. This local state may be invalidated, depending on the DPoP response from the server, and then an extra request must be made. This means that API calls are sometimes one request and response, and sometimes two requests and two responses, depending on state that the CLI cannot predict, only observe. The security benefits of DPoP are considerable, but the trade off is that users will either have to use our CLI or will likely have to work very hard to implement DPoP in their chosen language. Obviously we hope that more DPoP solutions will become available, and some already exist, but consider the example of `curl`. To use a bearer token in `curl`, you just read it and put it in the header. To use a DPoP token, you have to use a separate tool to generate the proof. Even then, the tool cannot not help us to implement the retry logic that we would need for RFC 9449 § 8. That would have to be done in pure shell. This is not necessarily much simpler than using bearer tokens, however, because bearer tokens still require rotation and refreshing. GitLab are [now supporting DPoP for their API tokens](https://docs.gitlab.com/user/profile/personal_access_tokens/#use-dpop-with-personal-access-tokens), and to allow DPoP header generation in the context of `curl` they built their own tool which is used like this: ``` glab auth dpop-gen --pat "<your_access_token>" --private-key ~/.ssh/id_rsa ``` There are a couple of unusual features of the GitLab support for DPoP. One is that they require an SSH key, and indeed you can see that the private key is passed to the `dpop-gen` subcommand above. The documentation doesn't say why the SSH key is required, but the inference is obvious and the [source is online](https://gitlab.com/gitlab-org/cli/-/blob/main/internal/commands/auth/generate/dpop_generate.go?ref_type=heads) for confirmation: they use the SSH keypair as the DPoP keypair. We could do the same in ATR. The second unusual feature is that they use a `PRIVATE-TOKEN: ...` header instead of the standard `Authorization: DPoP ...` header. They use `PRIVATE-TOKEN` for their existing PATs, so this is presumably for compatibility. The ironic thing about the use of an SSH key is that their [instructions for adding an SSH key](https://docs.gitlab.com/user/ssh/#add-an-ssh-key-to-your-gitlab-account) show that the process is similar to that used on ATR, and is similar to the process that I originally hoped to use for DPoP in ATR. In other words, GitLab do not comply with the first sentence of RFC 9449 § 5, and instead are using the approach that I too believe is obvious, with the extra twist of reusing an SSH keypair for DPoP. We could implement DPoP the way that GitLab does; it would have been helpful if RFC 9449 had considered this specific case and included it within their security analysis. Another more basic concern, however, is that DPoP will not be widely adopted. Of course, if engineers avoid implementing DPoP because they fear that it will not be widely adopted then it becomes self-fulfilling, but we still need to take into account usability because secure practices are of no benefit whatsoever if unused. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
