Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
In my opinion, having worked extensively with OAuth2 (mostly in the form of OIDC) and other modern AuthN&#x2F;Z protocols, the author of this post does not truly understand OAuth 2, nor have they looked in any appropriate depth into supplements like OIDC or alternatives.<p>For one, bearer token [1] is only one type of &quot;Access Token&quot; described by the OAuth2 spec [2]. In fact, the OAuth2 spec is very vague on quite a few implementation details (such as how to obtain user info, how to validate an Access Token), which the author seems to just assume are part of the spec, as he does with bearer token. Other parts, like the client&#x2F;user distinction, and the recommendation for separate validation of clients, the author ignores completely, generating his own (ironically mostly OAuth2-compliant [3]) spec.<p>&gt; Shared secrets mean no non-repudiation.<p>Again, not true. Diffie-Hellman provides a great way to come to a shared secret that you can be cryptographically sure (the adversary&#x27;s advantage is negligible) is shared between you and a single verifiable keyholder.<p>&gt; Most importantly using JWT tokens make it basically impossible for you to experiment with an API using cURL.<p><i>sigh</i>. If only there was a way to write one orthogonal program that can speak HTTP, and in a single cli command send that program&#x27;s output to another program that can understand the output. Maybe we could call it a pipe. And use this symbol: |. If only.<p>&gt; OAuth 2.0 is simply a security car crash from a bank&#x27;s perspective. They have no way to prove that an API transaction is bona fide, exposing them to unlimited liability.<p>TL;DR: This article, led by comments like this (&quot;unlimited&quot;, really?), strikes me as pure marketing (aimed at a naive audience) for a &quot;spec&quot; that probably would not exist had proper due diligence into alternatives, or perhaps some public discussion, occurred. At the very least, inconsistencies (a few of which I&#x27;ve mentioned above) could have been avoided.<p>[1] <a href="https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc6750" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc6750</a>     [2] <a href="https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc6749" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc6749</a>     [3] <a href="https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc6749#section-2.3.2" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc6749#section-2.3.2</a>