And just to add a bit more context for folks who stumble on this topic.
The OAuth basic does seem to only support sourcing attributes from a defined user data endpoint and does not support mapping JWT claims. So it’s similar to the OIDC plugin, but instead of the userinfo location provided by discovery doc you can target any JSON endpoint and then mapping by path. Adding in the settings for including auth in header and you can get to places like https://graph.microsoft.com/v1.0/me which we use for Entra based OAuth.
Now Entra ID offers some extensibility for core objects, but it’s not as easy as tacking on an optional claim and it would be a global change from what I see. So not sure it’s a real option for us. Stepping even further back the maturity path and just doing the JWT plugin seems like the only path, but it would require some PR work to add claims mapping support. Basically in the same fashion that the existing oauth2-basic allows for customizing the mapping of the Discourse field to a JSON attribute it would need to allow for more customization of field to JWT claims.
Now that is a path for us, but I ran into a different issue that i think stops it all in its tracks.
After getting oauth2-basic working it prompts for a new user and sees there is an existing user using the email from the existing OIDC plugin use. Even though they share the same mail attribute I think it can’t move between providers for the same Discourse user. Having everyone start from scratch isn’t a real option and while I could probably hack in a migration of an oauth provider record in user_associated_accounts form an oidc provider feels like I am just asking for trouble. So even if JWT had the claims mapping support all the existing Users are pinned to the OIDC provider without some database shenanigans or building an “existing user” handler to allow changing associated account it seems like you are stuck.