Live data from Hacker News

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

blog.teller.io

61–70 of 186 posts

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

#61

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…

Wouldn't this be a reason to promote the use of (trusted) web browsers and web applications instead of native apps or third party API's for high security scenarios? While TLS verification is something that is not flawless, it is something that users are being constantly reminded of by their banks and governments (check the domain name, check the green lock next to it), and modern web browsers go to great lengths to improve the user experience for keeping an eye on the validity of a website.

When I pay for something at a webshop via my bank account using a common standard created for that purpose (IDEAL in the Netherlands, other countries have similar systems) I get forwarded to my bank's authentication service to authorize that payment. I can clearly see that the TLS certificate belongs to my bank, and my browser is content that it is valid.

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

#62

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

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

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

#63

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…

SafariViewController on iOS and CustomTabsClient on Android solve this problem.

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

#64
post #55

I visited the homepage ( https://www.teller.io/ ) and got a warning about the SSL cert being invalid. Kind of ironic. :)

> I visited the homepage (https://www.teller.io/) and got a warning about the SSL cert being invalid. Kind of ironic. :)

The correct URL is https://teller.io and then you wont get an SSL cert warning. Not everyone uses "www". Nowhere on teller.io do you see a link to www. You put garbage in and got garbage out.

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

#65

1. To my mind, the fundamental problem OAuth solves is "letting a user decide" to share data with an app, without making the user responsible for jumping back and forth between the app and her API provider (her bank, in this case). OAuth holds the user's hand through a series of redirects, and the user doesn't have to copy/paste tokens, or remember where she is in the flow, or know what comes next. Does TAuth have a…

On 2: from the OP, "TAuth is available in production today for our existing beta users and we've already begun the work to make it an open standard we hope the industry adopts."

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

#67
>The EU is forcing all European banks to expose account APIs with PSD II by end of 2017.

Any reference for this? The text of PSD II is here — http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:320... — but it's too long and it isn't clear to me whether it is actually ratified.

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

#68

https://xkcd.com/927/

Can someone just blacklist every post that is nothing but a link to this comic.

Can someone just blacklist every post that is nothing but a new standard trying to add to the list of crappy pre-existing standards?

Also, you forgot the question mark on the end of your sentence there. Unless you meant a sarcasm mark or an interrobang and the comment parser stripped it?

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

#69

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…

2FA helps here.

Also, it would help greatly to be able to generate multiple auth users on your bank account (e.g. a read-only identity for giving access to MyLittleApp). I have seen this occasionally on banking portals, but it's very rare.

Post reply on HN