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 authorisation request

5. User returns to MyLittleApp, OAuth flow completes

In this flow, the user is not exposing their login credentials to the app… at worst, the app could extract their email/phone number. It also introduces another factor into the auth flow: the user's registered device.

The reason webviews are present in the SDK is because of the possibility that your app is not installed.

You cannot depend on SMS pin without your app, because that can be spoofed. I don't see any option except for manual pin copy paste from the app to a well known website that can be opened in the browser.

I agree in the "native app on same device" situation, we can bypass all this by bouncing straight to our app though.

I think you should talk about the case when a customer does not have Mondo app installed and another app asks for authorization to access. How will the auth flow work.

Of course, that doesn't work without a phone.

> and the only SMS is one from the service to the user

There is zero possibility of a customer actually recognizing a phone number...or even a shortcode. Assume that whatever SMS comes in your phone is going to be trusted by users. However the one thing that people will know how to do is Google their banks name and go to the corresponding website.

It's like me telling you I'm going to email you the passcode to a gate. If Bob overhears this and knows your email and my email, he still isn't in a position to do anything if he can spoof emails. Best case is he sends you the wrong code and you don't get access until you get the real code from me.

Bob is impersonating you in the first place and asking for the password. How do I know whether it is you or him?

If the spoof app has a "Connect with Twitter* (and you don't have the Twitter app installed), and then a webview is opened, the spoof app can replace Twitter's login page with their own, and capture the username and password.

While a malicious application can inject JavaScript to intercept the username, this alone is useless to an attacker.

User education only goes so far, this type of attack can also make a web view that traditionally asks for a TOTP one-time password code susceptible to leaking a users password, even if the normal login flow doesn't ask for that password.

[ed: note that it's pretty trivial to eg: set up hidden cameras in voting booths, if you want to spy on a few people, or perhaps have people film themselves in a voting booth - the point is rather that if most people make an effort to follow the common rules wrt. voting booths, the system is reasonably secure. And it's not trivial to make similar claims about a (presumably) centralized on-line system.]

We'll almost certainly add additional required factors to this process (eg. biometrics), as we see the user logging into the Mondo app on a new device as one of the most critical from a security perspective.

You must have a flow where this works without your app being installed.

If your flow is blocking on Mondo app being installed - that's fine. This means that the surface area of attack is restricted around your app. That's totally OK.

However - that is a very different positioning than oauth. I would say Oauth will degrade gracefully to your protocol if the endpoint is restricted to another app that must mandatorily be installed on the host device.

    1) MyLittleApp wants OAuth access to BankOfMars
    2) MyLittleApp bundles BankOfMars SDK into MyLittleApp
    3) MyLittleApp registers itself with BankOfMars, 
       which then has sole discretion over whether 
       to allow it to access data hosted by BankOfMars.
    5) If approved by BankOfMars, MyLittleApp can now 
       request oauth access to a user's data 
       with the BankOfMars SDK.
    6) SDK opens WebView for user to approve MyLittleApp's
       request to access user's data hosted by BankOfMars.
       User may reject the application's request.
    7) If the user approves the application's request, 
       the user is then prompted for authentication. 
       This can be in the form of a username/password, 
       but may also include two-factor authentication 
       or whatever BankOfMars deems necessary for security.
    8) Should BankOfMars or the user choose to do so, 
       either can revoke the right of MyLittleApp 
       to access BankOfMars data.

This is a problem with mobile apps unfortunately, since this type of browser interaction is going to be all over the place. For web apps it works just fine.

Plus it's way more complicated and has way more failure scenarios than simple password auth.

The only saving grace that I saw was that a service no longer has to store users' passwords to other systems, for persistent interaction with their data. I think this is really why people bother using it.

How so, if you're in a browser and you check the URL? It's only flawed here because the app controls the browser itself, but that wasn't the original use case of OAuth.

One way to circumvent that would be to enforce password change after any oauth authorization, but that's not very user friendly.

Someone should internally want to review code, especially for a bank.

The proper solution would be either 1) the ability to register 3rd party libraries with apple and require some kind of integrity check before approval (but even then, the 3rd party app could override library methods at runtime), or 2) code signing the binary blob library separately for every 3rd party developer (but then the problem is enforcement of where developers get the library from -- how do you verify SDK integrity from the bank server side?)

The fundamental problem is that, as soon as you give 3rd party developers the ability to natively integrate with your service via an SDK in their own app, you are playing a cat and mouse game.

But yes, aside from that potential difference, I understand what you're saying.

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.

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.

I am not experienced with iOS but I also suspect there are more advanced WebView detection tricks. It also doesn't help that Apple really doesn't like fast app switching.

http://www.priyaontech.com/2014/12/native-%E2%80%93-js-bridg...

mmm, thinking about it, might be compatible with the current spec.