Routes and endpoints for JWT consumption

[woodruffw]

Once we allow projects to configure OIDC providers (termed "publishers" in user-facing views), we need to allow OIDC-minted JWTs to be exchanged for API tokens.

As discussed with @di, we should ensure that these can be configured to run on a separate subdomain during deployment, to simplify caching logic.

[woodruffw]

Needs #10792.

[woodruffw]

As a reminder to myself: all of the routing/endpoint here should have accompanying metrics, per @ewdurbin's feedback: #10753 (review)

[woodruffw]

Needs #11218.

[merwok]

Is there a ticket or roadmap somewhere that explains this OIDC federation feature?

[woodruffw]

The project board is here: https://github.com/pypi/warehouse/projects/4

Some initial design and threat model is in these issues: #10644 and #10619

[merwok]

I’ve seen the board, but am more looking for a non-technical document that explains the big goal here.
I follow distutils-sig and other places but was not aware of a plan for github integration until I saw one of these PRs by chance.

[di]

The 'big goal' is to add support for https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect

[merwok]

Oh I see automatic tokens from github actions to pypi upload?

[woodruffw]

Oh I see automatic tokens from github actions to pypi upload?

Yep! The idea is that you'll be able to trust specific GitHub Actions to authenticate on your behalf, which in turn will remove the need to manually provision separate API tokens.

Those trusted GitHub Actions will use GitHub's OIDC provider, which produces ephemeral JWTs that are bound to the current workflow. Those are then exchanged for ephemeral API tokens, which are scoped down to the project(s) that trust that workflow.