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

Post by sjtgraham » Thu, May 05, 2016, 6:03 PM UTC

parsnips wrote: post #89

sjtgraham wrote: post #82

Earlier quoted context omitted.

Author 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 s…

>This is shit developer experience. Why bother with a Rube Goldberg sequence of piped commands when you can just curl? For which developers?

Post by 80x25 » Thu, May 05, 2016, 6:13 PM UTC

Freak_NL wrote: post #72

andrewstuart2 wrote: post #49

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 impl…

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

   curl ... // perform authentication to obtain JWT | xargs -I TOKEN curl -H "Authorization: Bearer TOKEN" ... // Call your API

Post by sandGorgon » Thu, May 05, 2016, 6:23 PM UTC

obeattie wrote: post #27

chatmasta wrote: post #15

One big problem with OAuth on mobile apps is this scenario. I've seen this in the wild for non security-critical apps. As far as I can tell, it's not a bug so much as it is a problem with the OAuth protocol and webview permissions: 1) MyLittleApp wants OAuth access to BankOfMars 2) MyLittleApp bundles BankOfMars SDK into MyLittleApp 3) MyLittleApp requests oauth access via SDK 4) SDK opens WebView for user to log int…

The flow we (Mondo) are considering for this: 1. MyLittleApp opens web view to log into Mondo 2. User enters something to identify themselves into the web view (eg. email address, phone number) 3. We dispatch a notification to the user's registered device (ie. the Mondo app where the user is logged in – this may be the same device or a different device) 4. User opens the Mondo app and accepts/rejects the authorisatio…

Post by andrewstuart2 » Thu, May 05, 2016, 6:25 PM UTC

Freak_NL wrote: post #92

sjtgraham wrote: post #82

Earlier quoted context omitted.

Author 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 s…

> This is shit developer experience. Why bother with a Rube Goldberg sequence of piped commands when you can just curl? If you are a developer tasked with working with web security related techniques, I would expect being able to use Bash, Curl, and anything needed to string together a couple of HTTP requests on the command line before your first cup of coffee of the day to be the least requirement of their skill set…

Post by Freak_NL » Thu, May 05, 2016, 6:42 PM UTC

tadfisher wrote: post #96

Freak_NL wrote: post #81

Earlier quoted context omitted.

A lot of banks do use proper hardware tokens (TOTP and similar) for all transactions though. I am under the impression that we are now in a phase where security needs to be stepped up, but in the mean time tokens send via SMS are considered 'good enough'. There are lots of initiatives for the next step, each providing proper two-factor authentication, but a lot of services are waiting it out because the hardware toke…

> Ideally, a standard such as FIDO U2F gains ground, so users can safely and conveniently reuse a single hardware token for any service supporting that standard. Who knows, perhaps having your 'internet key' on you can become as commonly accepted as having your house keys on you. Unfortunately, most FIDO U2F services allow SMS as a fallback authentication method, including Google and Github. At least Github has some…