> Sort of agree that the example I provided isn't the best use case for JWT. Perhaps a better example is email verification - you send a link in the email with a JWT.
Have you seen how Steam performs email verification as part of a 2FA successful login flow?
For password-recovery flows, you may still want to log (audit) attempted password recovery, which means a database hit anyway. From that perspective, "magic link" is good enough.
> OAuth2 is only useful if I want my users to decide what data they want to share with third party developers.
When you have logged in with an OAUTH2 provider, you're given a token which can be used against the API in any of the mechanisms you describe if your users are likely to do more than one request. Even if you only ever authenticate over your own OAUTH2 provider, this might still have advantages involving audit, reliability/availability, and so on.
One thing that I find very useful is using OAUTH2 to hand over authentication to my customers; they want to have their own password policy, and their own two-factor system, and so on. I don't want to implement that for every customer. Even when I implement a OAUTH2 provider for each customer I can do this easily, but nowadays, they might be able to use Amazon Cognito, or Azure to log into my API.
The first time someone wants to consume my REST API from within their dashboard, I'm already ready for this: I can build an SSO between their dashboard and my OAUTH2 provider (or just use theirs!) keeping everything separate from my actual business API, and the customer feels like this was a massive customization.
And so on.