OAUTH, Open ID Mobile UX: How should it work?

Session Topic: Oauth and OpenID on mobile native UIs. How should it work? (W5B)

Convener: George Fletcher

Notes-taker(s): David Robinson

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

What is the best way both from a security and from a user flow point of view for native mobile applications to authenticate and become authorized with access tokens?
 


Details:


Conversation started about how the web flow is fairly well know and understood, even when used on mobile devices, then turned to a discussion of how the AOL mobile applications work, where a user id and password are entered and the application contacts an AOL endpoint in order to get a token which is stored on the device… the user id and password never stored on the device.  But how do user's expect this to work from a screen flow point of view?
 


Discussed what a mobile screen might look like for logging in to services.
There might be a button that you click that causes a web view in your own app to load or alternately a web browser could be started and then you are redirected to a URL where you log in.
 


This screen could have a "default" username/password UI that sends credentials to a well known service provider that you want used for "all" or most of your mobile apps and then have other smaller buttons specific to other IdPs if you don't want to use the "default".
 


Drawing a different picture, you could have a drop down list where you pick an IdP from the list, and then enter a uid/pwd and press a "sign in" button - and that screen contacts the selected IdP.  It was noted this was very similar to the way a wireless hotspot works today in some cases.  The potential drawback of this is that the IdP may not support oauth - there are no guarantees. Also this method only really supports username/password credentials and no second factor support.



Facebook supports the ability to do a native client login.  They pick particular partners that they allow their log-in to go to...but this is not a good general model because it makes it difficult for random application developers to let people log into their app using Facebook, AOL, Google, etc. because the app developer has to go to each one to "negotiate" credentials ahead of time. This method basically attempts to use the OAuth2 Resource Owner Credentials grant type.
 


The "direct" Resource Owner Credentials grant has additional issues. Users are "conditioned" to look for certain chrome and we want to have the ability to do risk based authentication.  We also like to do OTP.. Much of this becomes harder or "impossible" when working with pure native application scenarios that do not include any browser type flows.  Since so much risk based heuristics are in place, we want to leverage this.
We need some assurance that users are not providing credentials to the wrong site in a phishing attack.


It was speculated that there are "3 modes" for a mobile app …

 

1. During installation
 

2. The very first time the app is run
 

3. Other times the app is used
 


There was discussion about whether there are opportunities to take advantage of these "modes" to register the app with an IdP and provide some sort of credentials maybe during these moments that are less obtrusive than others.  In particular it was mentioned that installation time might be a good time...but then counter arguments were that this would require Apple and Google to change their installation processes for all applications.
 


It was also noted that applications can leverage browsers...but web views cannot leverage applications (not sure where that comment was going…)



Is it too awkward to open a browser when a user starts in a native application?  It was thought this was a bit awkward if it can be avoided...but for security the log in UI needs to connect directly to the IdP and not go through the native application.
 


It was mentioned that single sign on (SSO) protocols often "assume" a browser. Based on the need for the IdP to determine if the user is already logged in. There are ways to bootstrap an SSO event from an authentication/authorization token but these aren't standardized.



There was a question about how tokens get into an application when a browser is used to authenticate.


It was mentioned that in smart phones, you can register your own URI schemes and have the browser redirect the user to my application URI passing the token information on the URI, which can then be processed by the application.
 


Google described Android and it's Account Manager.   The account manager handles authentication/authorization for applications on an andriod phone.  The account manager contacts a special end point for the native app and gets redirected to Google's IdP..which then can redirect the user further to a third party IdP if necessary.  The user authenticates and authorizes...and the third party IdP issues a token. This token is flowed back through the Google IdP which then flows back to the original end point that was contacted, which returns a 200 to the account manager..which gets the URI and can strip the token and save it.   It is possible to write "plug-ins" for random IdPs for Google's account manager. This allows other IdPs to register the process needed for Android apps to get OAuth tokens for that IdP.



There was a comment that while account manager makes sense for andriod, this doesn't make sense for all device types or even all mobile platforms. Some platforms like games systems are very constrained and don't really support passing of information between apps during app invocation.
 


Another concern with account manager is that installation on mobile devices does not allow for pre-reqs, so there is not way to guarantee that your plug-in for an IdP is loaded before your application is installed.
 


When Applications are installed, it should be up to the particular application whether it uses a separate browser, an embedded browser or handle the authentication/authorization in some other way.
 


Is it possible to release an IdP SDK for each of the major mobile platform ?
 


Someone suggested that you really should "always" use a web browser...but the conversation was about native applications.
 


There was some discussion on how to render log on screens appropriately on different devices so they display "nicely" and fit on the screen. Some IdPs use the OAuth extention for the 'display' parameter to identify which UI the IdP should display. This needs to be re-introduced and standardized.
 


There was discussion on what grant to use when using oauth on mobile devices.


Someone suggested using the regular authorization grant.


Someone else suggested that implicit grants were the way to go because they do not want to encourage anyone to put secrets on mobile devices.  As a security measure, it was mentioned that callback URLs are custom schemes in some cases ...acting like "magic" URLs and are not regular http URLs. Since native apps have access to the entire HTTP response, it's easy for them to extract the token and other data from the OAuth2 Implicit Grant flow.
 


Someone stated they are going to continue to use web views until the time when the operating systems can inherently deliver centralized account managers.
 


There was some discussion of trying to standardize how mobile log ins work - especially for native applications...then there were questions about where this would be done...not definitive answer...just a discussion at this point.
 


There was some discussion that you don't want to prompt a user "twice" for uid/pwd and then consent.  Once they have installed an app, you may not want to re-ask if they want to grant the application authorization ...because the user just downloaded and installed the application. There was discussions on when/how to suppress the authorization page.  There was discussion that this cannot and must not always be suppressed - so the IdP must be able to get specific information before it suppresses this screen.
 It was also mentioned that cookies are available in a browser environment and these can also be leveraged for certain suppressions of screens. The key here is to mark the cookie has HTTPOnly so that JS in the browser can not get access to the data. Another solution is to use a custom HTTP header. This works because the native app has full access to all parts of the HTTP response.
 


If the authorization code is returned in the header, by design, a web application cannot get to it.



There was mention of the Facebook "account manager" - that it does not need to be running when a Facebook app is called...because the mobile OS will wake up the FB app to do its thing. 
 


Finally, it was mentioned that each app is signed and has a special "signature" - called different things on different devices.  This signature is passed to the account manager by the operating system when the account manager is called by an application wanting to authenticate/authorize. This adds security such that the account manager can match invoking app with it's client_id and detect potential abuses.