If a website exposes APIs for private user data that are accessed via rich-client applications (desktop apps, J2ME mobile apps, etc.), then it can be hard for that website to become a relying party for federated login. The reason for this is that most desktop apps have a hardcoded user interface that asks for E-mail/Password to authenticate users. The same is true for websites which expose APIs, but which authenticate users via some second fatctor auth solution such as USB tokens, phone, InfoCard, etc. While the website with the API might be able to easily changes its login flow by updating code on its servers, it can be much harder to update the code on all the rich-client applications, especially if some of them were built by 3rd party developers.
Google has been evaluating the user experience of federated login in rich-client apps to determine what method can be used, assuming the website owner and client app developer are willing to modify their code. This document describes a prototype that we built and tested with our user research team.
One of the options we considered, but did not pursue, was to force all users of the the desktop app to use the OAuth protocol to authorize the app to access the user's data. Roughly that flow would take eight steps as listed below:
Therefore Google decided to try to find an approach that avoided using OAuth when possible, but fell back to it when necessary. The approach we took was to have the client app display the same style login box that Google suggests that websites should use. If the user enters an E-mail and password in that login box, it is sent via a proprietary Google ClientLogin API back to the webserver to see if it can be validated. If the webserver can validate the credentials, then the desktop app can immediately access the user's data. If it cannot validate the password, then the webserver can either return an error indicating that the user should try again, or it can return an error indicating that the user must be sent through the OAuth flow. Similarly, if the user enters an E-mail into the login box, but chooses "help me sign in" then they are always sent through the OAuth flow.
To help improve the OAuth user experience, we made two further optimizations:
Goal 1: Evaluate whether users were surprised by the non-traditional login box
Result: None of the 11 participants detected it was a non-traditional login box. That is in line with the previous studies we did. This is a strong indicator that we could change our desktop apps to use this login box and it would have no detrimental impact on normal usage
Goal 2: Get feedback on browser/OAuth flow for users whose domains were SAML enabled.
Result: 10 of the 11 participants completed the flow and found it easy, but identified some UI optimizations we could make (the first participant ran into bugs that we fixed for the others). The addition of the auto-detection of the approval process was important and without that we would need to significantly improve the UI. However even in the case without that auto-detection, it is important to note that for users from SAML enabled domains, we do not have any other reasonable alternatives to offer them anyways.
A copy of the prototype application is available here:
videos of using this prototype application with multiple federated login technologies and multiple strong authentication technologies.
To test it, launch the application, and try to login with a regular Gmail account by entering your E-mail address and password (see screenshots below). The app will now display a sample of contacts from your personal address book. Hit close to go back to the login screen.
You can now test the application with a domain that is hosted on Google Apps For Your Domain, including domains that are running their own SAML IDP (and even with SAML IDPs that use a second factor auth such as tokens or InfoCard). To do this, enter the E-mail address in that domain and choose "help me sign in" (as shown in the first screenshot below). If you don't have an account on AppsForYourDomain, then enter an @gmail.com address and choose "No, help me sign in" and you will also be sent through the OAuth flow.
Note: The user/employees may mistakenly type their password in this login box (like in the second screenshot below). However it will work even if they make this mistake. The app first sends the E-mail to the Google servers to find out if the domain is SAML enabled, and if so, it forces the user through the OAuth flow, otherwise it sends the E-mail/password to Google directly to be validated. This prototype version only has a hardcoded list of SAML domains (try email@example.com as an example), but if you want to force the system to do the OAuth flow for your domain, then choose "help me sign in." A later version of this prototype might even be able to check a registry setting to see if the enterprise had hardcoded their domain name, and in that case the desktop application could skip the login screen and start the OAuth flow immediately.
Note: The login page below is for a domain that is not SAML enabled. A SAML enabled domain would show its own login page, and might prompt the user for a second form of authentication such as a token/certificate/Infocard.
The next page they will see is the OAuth approval page (screenshot below) to confirm they want the app to have access to their contact list. The current page refers to some fake domain, however the final version would display the name of the application instead.
Note: The server cannot verify the identity of the application, but it can display a description of the application. If that description does not match the application the user has installed, then some users will correctly click the Deny Access options.
Once the user gives their approval, the browser will try to redirect to a destination page, and then the desktop app should automatically jump to the foreground and display their corporate address book (screenshot below)
Note: On firefox, you will see a destination page that tells you to manually switch to the desktop app and click the "continue" button
Product Manager, Google Security