Thanks for the realization about the first installed app being able to hijack the redirection endpoint.
But I can’t agree with the idea of going completely username+password on mobile devices.
Yes, embedded web views are evil, and we should promote an ecosystem where any app doing such a thing is distrusted by users. And yes another app can hijack the tokens intended to go to your app.
But there is a big difference between just considering apps trusted enough to give passwords to and them hijacking tokens.
When we go handing passwords over to every mobile app. These apps which may or may not be malicious now have absolute control over the account, even enough information to take it over entirely.
But that’s not the same as what an app can hijack with the custom protocol handler and a user safely using the browser. In that case all the app gets to hijack is an access token. The malicious app certainly can cause some mischief. But what they have is scope restricted, sometimes logged by authentication, and can’t be used to take over the full account.
Great talk Eran.
Quick question though. When you show the Encrypted tokens slide do you refer to MAC protocol that doesn’t require HTTPS or the same rules are also valid for any kind of Bearer Token (e.g. JWT) that kind of require HTTPS?
It doesn’t matter. It is an encrypted state protected from the client.
The way I see it is that we have three choices on mobile:
1. Trust the application enough to give full username/password. For me, as a user, this is by far the most usable approach, but far from the most secure one. Any attempt at authorization for the app to only perform certain actions after this can be easily ignored by the application itself, and this WILL be exploited, perhaps not intentionally even. I can foresee an application posting timeline updates to Facebook without my consent, or sending spam to my friends. When the application has my master credentials it can do whatever it wants in theory.
2. Install a third-party and trusted application to handle authentication/authorization and generate access tokens. BankId does this today in Norway. With some help from Intents the application is launched when needed, and can authorize purchases and generate access tokens that can be validated to see if a purchase was completed successfully. This would require each IdP to create an application to perform these authorizations, or have a common application such as the BankId example that can do these tasks and that is trusted. This could be built into mobile OSes as well. This is probably a secure approach, but more complicated for the user.
3. Make the user generate an access token and input that to the application. This is basically the way OAuth works today. Finding a way to do this natively without giving up the users credentials is the most challenging part, and frankly I cannot think of a way to do that as of now without involving option 2.
So far, option 3 is the simplest way to do this. We do not want any third-party mobile application to access a user’s credentials. For native application from the same company we can do this, but for developing third-party applications on i.e. Facebook’s API this is not a solution, and not very secure. The user simply has no control over what data the application can access, and we already see several large companies (Zynga *cough*) that desperately wants access to as much data as possible for commercial purposes. The extended permissions will be exploited by both malicious and legit companies.
The Resource Owner flow from the OAuth 2.0 specification seems to be useful for official provider native apps, if implemented with SSL do you think the MAC draft (http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01) will eventually make OAuth 2.0 safe enough?
I think the MAC draft is dead. I’ve moved on to working on Hawk instead.
Thanks for the education. What users want is an unobtrusive, non-webview, simple, one-time (per day), semi-permanent login system. I think this should be inherently two-tiered, with secure mode invoked when needed.
Sometimes it’s easy to get too caught up in the problem and lose sight of what the user wants. Put what the user wants on a piece of card on the end of a stick and hang over the developers head all the time. That way it’s less tempting to make something more complicated than it needs to be.
Writing software by committee is a soul destroying process and I am happy for you that you broke free from it. I bet you still have nightmares about it and wake up going “It was only a dream – phew!” 🙂
Comments are closed.