Proxy Auth for Native App Hosts
Session Topic: Proxy Auth for Native App Hosts (W3B)
Convener: John Webb
Notes-taker(s): John Webb
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:
- Main topic: Smartphones and other devices that have apps that utilize webservices currently require tedious authentication steps even when the user is already logged in elsewhere on the device (either in the OS shell or another app). How can we reduce the number of repeat authentication steps for these services? There is a much better user experience to be had, and possibly some savings in terms of development effort/risk.
- Three main options put out as starting point: - Third party cloud service that aggregates your services and proxies those requests for authentication/authorization - Platform level account manager which handles the auth exchange with the remote service and ensures user consent is handled properly (android model) - Switch to the native app for that device for that service and have it proxy the app-specific auth exchange (facebook on iOS model)
- Discussion:
- George described how AOL delivers long term tokens to the device with a shared secret - Google described the android account manager and how it has a plugin model that allows IDP's to support centralized auth in android - George has concerns that scope is provided by the client app via the account manager in native UI because it means that the plugin and the service need an API with fairly strong credentials that can control user consent -- risky - General concerns also about issuing a long lived token to an insecure device like a smartphone -- Counter-argument is that the long lived tokens can be revoked from the server side and also it may be even more secure in this model because specific client apps can use short lived tokens and re-request them transparently - Dirk described an additional security step whereby the OS can pass some metadata about the client app that requested authorization up through the account manager's conversation - extra assurance that the client app is who he says he is - Talked about the general notion of token exchange or token leverage whereby the user can get a token for a service based on having an existing token - Having a relying party alternative seems to be preferred in all cases, but agreement that we need to support this style as well - Dirk talked about how Android has some "blessed" apps which don't need to ask the user for consent, which is a potential cause for server confusion. Their solution had something to do with having the client token returned with the consent screen, but I didn't catch the whole thing
Questions:
- 1 - Is this mechanism of an account manager a viable model for all "native app hosts"? What about "web platforms?"
- 2 - Is there some standard that needs to be developed around this mechanism of having an endpoint for twiddling consent bits?
PAGE
