It seems like the more "open" and non-reliant on GitHub we go, the more the workload gets placed on administrators as a bottleneck for publishers.

Short answer: You can build the same shape of member auth (browser login → verified identity → VoxForge JWT → publish under authorized namespaces), but not a drop-in replacement for what GitHub tokens do today. OIDC covers authentication well; VoxForge's GitHub path is also authorization/proof tied to Puppet/GitHub author namespaces. That second half is the hard part.

This is more a GitHub token to authorize the user to their GitHub repo. You only need that when trying to prove to the forge who you are. After that, you have publish rights in the interface and from what I can tell, no further reach out to GitHub is required once your account is authorized. It simply asks a module author to add a new token to their already existent GitHub repo and copy/paste it into the interface for authorization, allowing it to be more "hands-off" for the admins. it's not a whole lot different than the current Puppet forge accounts we have today.