Nobody Cares About OAuth or OpenID Connect

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.

With OpenID Connect adds things like dynamic client registration for a client (acting as an RP) to get authentication information, and you can use OpenID Connect to get both that authentication token and an access token at the same time.

However, this unfortunately doesn't extend to weakening the dependency on a protected resource receiving one of these access tokens needing a relationship with the issuing AS.

Unfortunately, dynamic client relationships haven't caught on enough for there to be focus on this issue. But on the flip side, there would be a lot of other agreements around what those access tokens mean and what API they can apply to before you could have such a dynamic authorization relationship.

Now, if the goal is for _your own_ protected resources to rely on authorizations provided by other ASs - likely you just shouldn't do it that way. Instead, you should have a local AS that itself has relationships with multiple other ASs acting as an intermediary (or what Microsoft has historically called an STS). It authenticates based on other providers, gets their authentication and access tokens, and translates them into tokens that the local environment can understand based on a single, centralized policy.

Any assertion that you are dealing with a particular person needs to be targeted at you. There were security vulnerabilities with some early OAuth deployments that used OAuth for authentication which didn't understand this - and that allow one service that had a relationship with a user to act as that user against all other services which trusted that AS.

For Facebook, they solve this by having the token stamp information about which client it was issued to, which the client is required to verify. For OpenID Connect, they decided to preserve the ability of OAuth access tokens to be opaque to the client, and create a new token called an id_token.