OAuth 1.0a does not provide authentication to the client. There is nothing about a token that tells a client which user it represents, or if that user is curren

OAuth 1.0a does not provide authentication to the client. There is nothing about a token that tells a client which user it represents, or if that user is currently authenticated. You can imply there was possibly some authentication guarantee against some user by the Service Provider if you request a new token, but that's it. OAuth 1.0a provides integrity only for the client request parameters. It does not provide integrity for the client request headers or body. It does not provide integrity for any of the server response - which means while clients can make valid requests, a MITM could be providing it completely fraudulent data to act on. Likewise, since OAuth 1.0a does not provide integrity over the entire request message, it also does not provide non-repudiation over the entire request message, or non-repudiation of the client for any server responses. Some organizations have chosen to leverage OAuth 1.0a with non-standardized extensions parameters like a body hash to try and partially solve these issues, but they tend to be very underspecified (which hashing algorithm? Before or after Content-Encoding / Transfer-Encoding ?) Finally, there are no standardized modern cryptographic methods for OAuth 1.0a - it will likely remain on SHA-1 forever. OAuth 2 provides integrity over the entire request/response by relying on TLS. Generally the only reason you would worry about this is if you are paranoid that: - Clients are turning off TLS validation. Granted, this is still pretty common, and can be solved for your use case by requiring mutual TLS. - Normally trusted intermediaries cannot be trusted not to modify your traffic. This would be something like a compromised TLS-terminating reverse proxy. This tends to not be solvable by mutual TLS. There have been many failed attempts at improving on the signature algorithms in OAuth 1.0a - it turns out it is hard to make guarantees that there won't be legitimate reasons for an intermediary to muck with the request/response. There is actually no reason why someone couldn't extract the existing request signature logic from OAuth 1.0a (sans token-secret in the HMAC, which IMHO was pointless) and propose it as an independent spec for doing end-to-end request signatures. But so far it seems nobody has wanted to do so, instead focusing (and stumbling) on trying to provide something better.