Generic OIDC support

[zooba]

What's the problem this feature will solve?
Some OIDC providers may not match the formats currently available, and some of the supported ones (e.g. GitHub) allow customization of the subject, which breaks publishing.

Describe the solution you'd like
A Trusted Publisher configuration that allows us to provide the issuer URL and subject identifier directly. That way, any provider is able to be used to obtain a publishing token, but configuration still requires interactive logon.

Additional context
GitHub organizations are able to override the OIDC configuration for all their repositories, which means some umbrella orgs may choose a more secure configuration (e.g. immutable IDs instead of repo names) and enforce it. This situation can usually be overridden, but it's likely often easier (and potentially safer) to update PyPI to accept the new subject rather than reverting the OIDC config.

[miketheman]

Hi @zooba ! Thanks for the issue, I'm trying to understand exactly what kind of shape of OIDC you're referring to.

One challenge that we have allowing "any ol' issuer URL" is that we have been selective in onboarding the types of issuers to maintain a degree of confidence in the platform that is publishing to PyPI is a trusted one - and not any random CI tool someone uses.

PyPI obtained the beta ability to enable notable GitLab instances via Organizations - see https://blog.pypi.org/posts/2025-11-10-trusted-publishers-coming-to-orgs/#expansion-of-trusted-publishing-to-gitlab-self-managed-beta for the details

If you are interested in such an ability for GitHub (either .com or GHES editions), let's figure that out.

For a more specific example, can you produce a JWT that has the changes that you're looking for?

The id project (used by the Trusted Publishing GH Action) can produce a useful token for debugging from inside a GitHub Action - I don't need the entire JWT, rather the "middle part" - so something like python -m id pypi | cut -f2 -d'.' is likely to produce the base64-encoded claims table that you can decide and sanitize if it has things you're worried about sharing publicly.

[zooba]

One challenge that we have allowing "any ol' issuer URL" is that we have been selective in onboarding the types of issuers to maintain a degree of confidence in the platform that is publishing to PyPI is a trusted one - and not any random CI tool someone uses.

If this is the concern, then I'd be happy enough with keeping the existing issuer URLs but allowing users to provide the entire sub value through the PyPI UI, instead of the repository/environment/etc. names.

Once you customize the subject (link in OP, and note that "cloud provider" in that doc means PyPI), the algorithm PyPI uses to parse and compare the subject identifier no longer holds. Since the subject can be made up of a range of identifying values, fully customizable by the repository/organization on GitHub, there may be no feasible way for PyPI to construct it from components. In this case, it seems best to just let the user tell PyPI exactly what the subject will be.

Changing the issuer is less of a big deal, though since services like Azure DevOps uses an issuer that varies (it includes an org UUID in the URL), it would be nice to have the flexibility to control both. But I understand not wanting people to build out publishing workflows on unvetted systems, so as I say, limiting the issuer URLs would be reasonable.

[di]

Another option here is to just stop checking the subject all together for GitHub because IIRC it is entirely duplicative of other claims that we also verify.

[zooba]

Another option here is to just stop checking the subject all together for GitHub

This sounds scary to me (as a non-expert in OIDC, since every other system using it seems to exclusively check the subject, and GitHub's docs about it suggest that the subject is what's going to be checked).

it is entirely duplicative of other claims that we also verify

Well, yes, the default subject identifier is. But an alternative one might be using immutable IDs rather than changeable names, and you aren't verifying those. Presumably that would mean that if I rename my organization, and someone renames theirs to what mine was, they'll be able to abuse my PyPI registration up until I update it? Whereas if you're verifying a subject that uses immutable repo IDs instead, they wouldn't be able to?

[miketheman]

Presumably that would mean that if I rename my organization, and someone renames theirs to what mine was, they'll be able to abuse my PyPI registration up until I update it? Whereas if you're verifying a subject that uses immutable repo IDs instead, they wouldn't be able to?

Existing behaviors look for stored owner ID to prevent owner name resurrection attacks.

[di]

This sounds scary to me (as a non-expert in OIDC, since every other system using it seems to exclusively check the subject, and GitHub's docs about it suggest that the subject is what's going to be checked).

Every item in the default subject that we are checking (specifically, orgname/reponame is currently duplicated in the set of additional claims, and verified. Given that we'll continue to verify these outside of the subject, I think it would be reasonable to assume that they should always match if they are present in the subject as well, meaning that we don't need to be checking them twice, and we can ignore the subject by default.

The customizability of the sub claim seems to already be presenting problems for some organizations, which leads me to think that ignoring it by default (and possibly giving users a way to optionally require a specific value) is worth pursuing: #19405

[zooba]

Both of those reports are also from my organization, so I doubt it's too widespread yet 😉

I ran the idea of ignoring the subject past some of our OIDC experts and none of them got angry about it, so I guess that's probably a good way forward here.

[woodruffw]

Yeah, I think I'm vaguely in favor of removing the subject check -- OIDC is a bit of a mess in that sub is the "usual" way to represent a unique subject claim, but with Trusted Publishing the goal is to have a more structured understanding of the publisher than the subject can give us. So we're always tied to a sufficient set of custom claims anyways, making the sub entirely redundant.

(Or in other words: I think we should remove the sub check, but this may foreclose on offering fully generic OIDC support. But honestly I think that's a good thing -- structured claims are a lot less scary to validate than a :-delimited mash of user-controlled data in sub!)

[zooba]

I think we should remove the sub check, but this may foreclose on offering fully generic OIDC support.

I mean, you can still do both. If you were to let a user configure a generic sub to match then you can just do a straight comparison, and if the user configures a "preset" provider then you compare the structured data.

I don't know if there's a way to change what structured data is made available as part of the process. If that exists, or if it's likely to be introduced, then having a user configurable "blind" sub option at least means people aren't blocked waiting on a Warehouse update.

[di]

I mean, you can still do both. If you were to let a user configure a generic sub to match then you can just do a straight comparison, and if the user configures a "preset" provider then you compare the structured data.

The issue is that the UX of configuring a custom subject claim check means we'd have to support a template string, essentially. For example for a sub like:

repository_owner_id:6154722:repository_id:966304329:environment:release

from #19405, the user would either have to know their repository_owner_id and repository_id in advance, or input a string like:

"repository_owner_id:{ repository_owner_id }:repository_id:{ repository_id }:environment:release"

which introduces lots of room for error.

And since all these values are already being checked as individual claims, I don't think there's sufficient reason to check them again via the sub claim.