One thing I could imagine here is a signature flow happening from the sender side where they sign the nonce + the token, to avoid forgery. I don't know what the

One thing I could imagine here is a signature flow happening from the sender side where they sign the nonce + the token, to avoid forgery. I don't know what the signature validation looks like in that model though (if you request a public key from the provider, are you requesting that at every request flow? If you're not, now you're adding a request to every normal, non-malicious validation flow) > Maybe you need to implement some uncommon signature verification. It could be anything. So my feeling on this is that at the very least OAuth tends to be "well it's going to look like this, but there might be some tweaks". I have set up OAuth verification with multiple services in the past. The social aspects and the business aspects have always been more complicated, but at least "it's OAuth" (much like "it's REST" for APIs) establishes a core understanding very quickly. I'm open to saying that we should add more standard stuff to the flow, if it's optional then people who use oauth libraries will end up with a lot of this stuff by default. But I think the status quo is pretty nice, all things considered.