5 ms·

> "So long as you remain within the app, there’s no security advantage for OAuth in an embedded web view over xAuth" Yes there is. I don't trust the developer

> "So long as you remain within the app, there’s no security advantage for OAuth in an embedded web view over xAuth" Yes there is. I don't trust the developer enough to give her/him my user ID and password so OAuth works for me.

gridspy 15y ago
You can't trust that the webview (controlled by the app) isn't intercepting your credentials.
tolmasky 15y ago
The point is that this is an illusion. If the native app puts up an in app browser (which is a very common strategy), then they have access to everything you type. They can query the page for that same username and password, they can simulate clicks, they can do whatever they want. And additionally, for all you know, its not even the real page you are seeing. OAuth security only makes sense on the web.
- zmmmmm 15y ago
  Well, there are different layers of trust. I trust the intent of many app developers, I just don't trust their competence to store my credentials securely. So OAuth still requires me to trust their intent, but does solve the problem of competence (as long as I trust them to implement OAuth properly which can also be an issue).
  - mnutt 15y ago
    And that's exactly what xAuth is. It just drops the pretense that oAuth inside a developer-controlled webview is trusted, authenticates directly using email/password, and then stores a token like oAuth.
    - zmmmmm 15y ago
      When implemented using a contained web view I agree, it's not terribly useful and arguably even harmful. However if the user is directed through the real browser then they can clearly see where they are logging in and doing the authorisation. This is partly just a problem with iOS and it's limited ability to flow and pass data between apps than OAuth per se.
  - ceejayoz 15y ago
    OAuth is storing credentials, it's just an access token rather than a password. The end result is the same - they have access to your account until you revoke it, either by canceling the token (OAuth) or changing password (non-OAuth). Clients using xAuth don't store username/password, anyways. They just use it once to request a token, every future request is just like normal OAuth.
    - zmmmmm 15y ago
      > it's just an access token rather than a password. The end result is the same No, its dramatically different. If someone has my password then they have full authority over my account right up to and including changing the password itself. If they have an OAuth token they have whatever limited rights I granted to the token (could be read only, or limited to a subset of data, or automatically expiring after 24 hours). The analogy that is often used is the special set of valet keys that come with some cars. They allow someone to drive the car - but no faster than 20mph, cannot use stereo, etc. etc.
- chrismoos 15y ago
  An in-app browser isn't the only way to provide OAuth, on most platforms you can invoke a URL and the browser application will open on the phone. For example, on iPhone you can invoke an HTTP(s) URL, your app will exit, mobile safari opens, and you can then login and know that what you are typing is as secure as the OS/app sandboxing is....take a look at how the Facebook iPhone SDK flow works, its actually quite nice and very easy for users. In reality, if you want to know that you aren't giving your username/password to a malicious third party, as an end user, you have to deal with a little inconvenience...being redirected in your browser to an SSL page that you trust, for example.
  - nupark2 15y ago
    If the "third party" is actually a malicious native application, they can just simulate the launch of Safari, and most users probably won't even notice. In this threat model, OAuth is practically a security no-op and a huge usability negative.
    - chrismoos 15y ago
      Yeah they could simulate the launch, good point. I guess you'd have to hit the home button to know you are leaving the app. Sucks :(
- BlazingFrog 15y ago
  Thanks for the clarification.
- mtogo 15y ago
  You're wrong. If the app developer is actually malicious this is true, but there are some non-malicious applications i just don't trust. Look at Sony, they're not malicious (e.g. they wouldn't record my password when they're not supposed to) but i don't trust them with my passwords (for obvious reasons).

gridspy 15y ago

You can't trust that the webview (controlled by the app) isn't intercepting your credentials.

tolmasky 15y ago

The point is that this is an illusion. If the native app puts up an in app browser (which is a very common strategy), then they have access to everything you type. They can query the page for that same username and password, they can simulate clicks, they can do whatever they want. And additionally, for all you know, its not even the real page you are seeing. OAuth security only makes sense on the web.

zmmmmm 15y ago
Well, there are different layers of trust. I trust the intent of many app developers, I just don't trust their competence to store my credentials securely. So OAuth still requires me to trust their intent, but does solve the problem of competence (as long as I trust them to implement OAuth properly which can also be an issue).
- mnutt 15y ago
  And that's exactly what xAuth is. It just drops the pretense that oAuth inside a developer-controlled webview is trusted, authenticates directly using email/password, and then stores a token like oAuth.
  - zmmmmm 15y ago
    When implemented using a contained web view I agree, it's not terribly useful and arguably even harmful. However if the user is directed through the real browser then they can clearly see where they are logging in and doing the authorisation. This is partly just a problem with iOS and it's limited ability to flow and pass data between apps than OAuth per se.
- ceejayoz 15y ago
  OAuth is storing credentials, it's just an access token rather than a password. The end result is the same - they have access to your account until you revoke it, either by canceling the token (OAuth) or changing password (non-OAuth). Clients using xAuth don't store username/password, anyways. They just use it once to request a token, every future request is just like normal OAuth.
  - zmmmmm 15y ago
    > it's just an access token rather than a password. The end result is the same No, its dramatically different. If someone has my password then they have full authority over my account right up to and including changing the password itself. If they have an OAuth token they have whatever limited rights I granted to the token (could be read only, or limited to a subset of data, or automatically expiring after 24 hours). The analogy that is often used is the special set of valet keys that come with some cars. They allow someone to drive the car - but no faster than 20mph, cannot use stereo, etc. etc.
chrismoos 15y ago
An in-app browser isn't the only way to provide OAuth, on most platforms you can invoke a URL and the browser application will open on the phone. For example, on iPhone you can invoke an HTTP(s) URL, your app will exit, mobile safari opens, and you can then login and know that what you are typing is as secure as the OS/app sandboxing is....take a look at how the Facebook iPhone SDK flow works, its actually quite nice and very easy for users. In reality, if you want to know that you aren't giving your username/password to a malicious third party, as an end user, you have to deal with a little inconvenience...being redirected in your browser to an SSL page that you trust, for example.
- nupark2 15y ago
  If the "third party" is actually a malicious native application, they can just simulate the launch of Safari, and most users probably won't even notice. In this threat model, OAuth is practically a security no-op and a huge usability negative.
  - chrismoos 15y ago
    Yeah they could simulate the launch, good point. I guess you'd have to hit the home button to know you are leaving the app. Sucks :(
BlazingFrog 15y ago
Thanks for the clarification.
mtogo 15y ago
You're wrong. If the app developer is actually malicious this is true, but there are some non-malicious applications i just don't trust. Look at Sony, they're not malicious (e.g. they wouldn't record my password when they're not supposed to) but i don't trust them with my passwords (for obvious reasons).