Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it

Re:Introducing TAuth: Why OAuth 2.0 is bad for banking APIs ... by sjtgraham on Thursday May 05, 2016 @01:02PM (#11637846)

> 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.

[ Parent | on HN ]

Re:Introducing TAuth: Why OAuth 2.0 is bad for banking APIs ... by ForHackernews on Thursday May 05, 2016 @03:06PM (#11638876)

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.

[ Parent | on HN ]