The comparison to OAuth is quite reasonable. Perhaps the most obvious parallel is the use of a state parameter during the three-legged exchange, without which it's exposed to a CSRF clickjacking attack.
Right. Maybe it's paranoid, but it seems like a bearer token has potential avenues for forgery (CSRF or others), replay attacks, add-on jacking, etc. Also harder to coordinate with distributed apps. I think the Captain Tightpants approach would be to initialize some client-side private key/cert, use that to sign each request and verify based on that cert.
That should also make it easier to, say, verify and unwrap the request at the gateway to the server, before sending it to the rest of the application-proper.
That should also make it easier to, say, verify and unwrap the request at the gateway to the server, before sending it to the rest of the application-proper.