4 ms·

OAuth 1.0a handles both authorization and authentication. I still think it’s unfortunate that Big companies are pushing for OAuth 2.0 and trying to blindsided

• rdegges 8y ago
  I agree! I really liked OAuth 1.0, especially from a security POV. But, the working group has moved on, and OAuth 2 is the standard now :x
  • woranl 8y ago
    Not everyone is using OAuth 2. Mastercard makes a security decision to stay with OAuth 1.0a. https://news.ycombinator.com/item?id=17482178 https://news.ycombinator.com/item?id=17482178
    • brlewis 8y ago
      Also twitter whenever the app is supposed to act on behalf of a user. (OAuth 2 is simpler, and is available for accessing public data not on behalf of a user.) https://developer.twitter.com/en/docs/basics/authentication/overview/oauth.html https://developer.twitter.com/en/docs/basics/authentication/...
      • dwaite 8y ago
        Twitter is very reluctant to find out how much removing OAuth 1.0a (and their previous incarnations like XAuth) will break in their legacy infrastructure and for existing trusted clients. A migration path would mean adding OAuth 2 in addition to all the previous mechanisms, and then likely acting over a long migration timeline.
    • dwaite 8y ago
      Its worth noting that MasterCard has made non-standardized extensions onto OAuth 1.0a to meet their needs.
• dwaite 8y ago
  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.