Asymmetric Tokens and server issuing challenges #11521
Assignees
Labels
A-registry-authentication
Area: registry authentication and authorization (authn authz)
S-triage
Status: This issue is waiting on initial triage.
Z-asymmetric-token
Nightly: asymmetric-token authentication
Comments
Eh2406
added
the
A-registry-authentication
7 tasks
bors
added a commit
that referenced
this issue
Jul 20, 2023
feat(crates-io): expose HTTP headers and Error type ### What does this PR try to resolve? This is part of #11521. [RFC 3231] mentions the authentication process could have an additional **challenge-response mechanism** to prevent potential replay attacks. The challenge usually comes from HTTP `www-authenticate` header as a opaque string. When a client gets a 401/403 response with such a challenge, it may attach the `challenge` to the payload and request again to anwser the challenge. ``` ➡️ cargo requests ⬅️ server responds with `www-authenticate` containing some opaque challenge string ➡️ cargo automatically requests again without any user perception ⬅️ server responds ok ``` However, `crates-io` crate doesn't expose HTTP headers. There is no access to `www-authenticate` header. This PR make it expose HTTP headers and the custom `Error` type, so `cargo` can access and do further on the authentication process. [RFC 3231]: https://rust-lang.github.io/rfcs/3231-cargo-asymmetric-tokens.html#the-authentication-process
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The 3231 RFC describes that servers can issue a one time challenge to better protect against token reuse. This was not implemented in #10771 and should be implement it before stabilization.
The text was updated successfully, but these errors were encountered: