> One of the biggest problems with OAuth 2.0 is that it delegates all security concerns to TLS but only the client authenticates the server (via it's SSL certificate), the server does not authenticate the client. This means the server has no way of knowing who is actually sending the request.
That's not just plain not true. In the OAuth2 authorization_code grant, a "confidential" client is REQUIRED to send a client_id and client_secret to authenticate itself to the server.
> If the client type is confidential or the client was issued client
credentials (or assigned other authentication requirements), the
client MUST authenticate with the authorization server as described
in Section 3.2.1.
Now, this doesn't work for "public" clients like a pure-javascript webapp, but that's a separate question.
Count me as pretty dubious of letting some unknown group try to re-implement bank authentication without fully understanding the specification they're trying to fix.
> That's not just plain not true. In the OAuth2 authorization_code grant, a "confidential" client is REQUIRED to send a client_id and client_secret to authenticate itself to the server.
All secrets go over the wire, which is protected with TLS. Ultimately the security is delegated to TLS. You're simply wrong here.
> Count me as pretty dubious of letting some unknown group try to re-implement bank authentication without fully understanding the specification they're trying to fix.
Your misunderstanding is also indicative that OAuth 2.0 is too complicated.
You're correct that OAuth2 ultimately delegates all security to TLS--if that concerns you, you're better off using OAuth1a that has its own signing/verification protocol.
The statement in the OP that:
> the server does not authenticate the client. This means the server has no way of knowing who is actually sending the request.
is incorrect as written. [In the case of a confidential client] The server does authenticate the client, and it does know who is making the request.
If you're going to claim that TLS-protected authentication somehow counts as "does not authenticate the client" then I guess you'll agree that Gmail "does not authenticate" my IMAP client when it makes a TLS-secured connection and sends my 'app password' over the wire.
That's not just plain not true. In the OAuth2 authorization_code grant, a "confidential" client is REQUIRED to send a client_id and client_secret to authenticate itself to the server.
https://tools.ietf.org/html/rfc6749#section-4.1.3
> If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1.
Now, this doesn't work for "public" clients like a pure-javascript webapp, but that's a separate question.
Count me as pretty dubious of letting some unknown group try to re-implement bank authentication without fully understanding the specification they're trying to fix.