6 ms·
In my opinion, having worked extensively with OAuth2 (mostly in the form of OIDC) and other modern AuthN/Z protocols, the author of this post does not truly und
by andrewstuart2 10y ago
In my opinion, having worked extensively with OAuth2 (mostly in the form of OIDC) and other modern AuthN/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.
For one, bearer token [1] is only one type of "Access Token" 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/user distinction, and the recommendation for separate validation of clients, the author ignores completely, generating his own (ironically mostly OAuth2-compliant [3]) spec.
> Shared secrets mean no non-repudiation.
Again, not true. Diffie-Hellman provides a great way to come to a shared secret that you can be cryptographically sure (the adversary's advantage is negligible) is shared between you and a single verifiable keyholder.
> Most importantly using JWT tokens make it basically impossible for you to experiment with an API using cURL.
sigh. If only there was a way to write one orthogonal program that can speak HTTP, and in a single cli command send that program's output to another program that can understand the output. Maybe we could call it a pipe. And use this symbol: |. If only.
> OAuth 2.0 is simply a security car crash from a bank's perspective. They have no way to prove that an API transaction is bona fide, exposing them to unlimited liability.
TL;DR: This article, led by comments like this ("unlimited", really?), strikes me as pure marketing (aimed at a naive audience) for a "spec" 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've mentioned above) could have been avoided.
[1] https://tools.ietf.org/html/rfc6750 https://tools.ietf.org/html/rfc6750 [2] https://tools.ietf.org/html/rfc6749 https://tools.ietf.org/html/rfc6749 [3] https://tools.ietf.org/html/rfc6749#section-2.3.2 https://tools.ietf.org/html/rfc6749#section-2.3.2
- Freak_NL 10y agoAs a developer currently working with OpenID Connect (OIDC) and JSON Web Token (JWT), using curl is indeed not a problem at all: curl -i ... // Perform authentication to obtain JWT export JWT="eY..." // Place JWT in a shell variable curl -i -H "Authorization: Bearer $JWT" ... // Call your API That's all there is to it.
- 80x25 10y agoExactly, perhaps even simpler: curl ... // perform authentication to obtain JWT | xargs -I TOKEN curl -H "Authorization: Bearer TOKEN" ... // Call your API
- sjtgraham 10y agoAuthor here: > For one, bearer token [1] is only one type of "Access Token" 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/user distinction, and the recommendation for separate validation of clients, the author ignores completely, generating his own (ironically mostly OAuth2-compliant [3]) spec. Last time I checked other access token types were still drafts and bearer tokens were the only stable kind. > Again, not true. Diffie-Hellman provides a great way to come to a shared secret that you can be cryptographically sure (the adversary's advantage is negligible) is shared between you and a single verifiable keyholder. I as a bank cannot attribute liability for an erroneous transaction to a developer if with both share the secret with which a signature is computed. If I as a bank am compromised and want to cover my arse by moving the blame to a poor external developer I can do that with a shared secret by forging signatures after the fact. This is precisely why I don't want shared secrets. Even if your point is valid re DH, why push that up to the application level and reinvent the wheel when you can get the same benefits, less intrusively by using a battle tested protocol circa 20 years old? > sigh. If only there was a way to write one orthogonal program that can speak HTTP, and in a single cli command send that program's output to another program that can understand the output. Maybe we could call it a pipe. And use this symbol: |. If only. This is shit developer experience. Why bother with a Rube Goldberg sequence of piped commands when you can just curl? Finally, despite everything you say no OAuth 2.0 based protocol can guarantee privacy. People like that privacy when it comes to their finances I find. Sorry for any typos, I'm on the move. Thanks for your comments :)