Appauth-android: Should AppAuth be used for Customer Facing Applications, or just for the Enterprise SSO?
Hi,
We use an OpenID IDP application to service authentication of customers to a number of public facing websites, albeit the customer only thinks of it as one.
We are looking at developing a native IOS and Android mobile app to integrate seamlessly into this IDP and have been recommended by the supplier to use AppAuth.
However the client and myself are concerned about the UI clunkiness with regard to this approach, giving the user the appearance of leaving the app doesn't fit well.
Is there any guidelines, best practices to assist in making this approach more seamless, or transparent?
Perhaps using AppAuth is not the best tool in the box for our use case, if not what other option should we be considering?
saltyzip
>All comments
There are certainly trade-offs to using a custom tab based authentication flow. You lose some ability to customize the look-and-feel of the flow, but you gain some other important benefits: single sign-on for the user, and the ability to form-fill using data saved by the browser.
Alternatives to a web-based flow are limited unless the IDP you are integrating with provides some SDK to perform the flow. IDPs which do provide an SDK usually just wrap a WebView, which generally has terrible security properties - the client app can inject JavaScript into the frame and keylog the user to steal passwords and private information. Few IDPs have the reach to justify having the user install an IDP-specific app to implement the flow more securely using on-device, native primitives. Google do this in Google Sign-in SDK, but only because Play Services is available on the vast majority of Android devices. Facebook use a native flow with the Facebook app as a proxy when available, but otherwise fall back to wrapping a WebView, with all the security caveats implied.
Without a native SDK, your only option is to use a web browser, and custom tabs at least provide an "in-app" interaction - the browser becomes part of your app's back stack, with some styling options to make it fit better with your app, but retaining the security properties of a standalone browser. We at Google use the equivalent of custom tabs on iOS (SFSafariViewController) to implement authentication for our apps. I have seen AppAuth adopted for both enterprise and consumer authentication use cases, particularly where the app wishes to maintain flow consistency across multiple IDPs.
If all you are integrating with is Google and Facebook, native SDKs are probably fine and may give you a better experience. If you are integrating with other options, I would recommend using AppAuth, or building your own web entry point for authentication.
iainmcgin
on 28 Feb 2017
Related issues
shahfaizal
路
7Comments
LaluGanesh
路
3Comments
Write4Dinesh
路
3Comments
shalfknight
路
7Comments
tomjackman
路
7Comments
Most helpful comment
There are certainly trade-offs to using a custom tab based authentication flow. You lose some ability to customize the look-and-feel of the flow, but you gain some other important benefits: single sign-on for the user, and the ability to form-fill using data saved by the browser.
Alternatives to a web-based flow are limited unless the IDP you are integrating with provides some SDK to perform the flow. IDPs which do provide an SDK usually just wrap a WebView, which generally has terrible security properties - the client app can inject JavaScript into the frame and keylog the user to steal passwords and private information. Few IDPs have the reach to justify having the user install an IDP-specific app to implement the flow more securely using on-device, native primitives. Google do this in Google Sign-in SDK, but only because Play Services is available on the vast majority of Android devices. Facebook use a native flow with the Facebook app as a proxy when available, but otherwise fall back to wrapping a WebView, with all the security caveats implied.
Without a native SDK, your only option is to use a web browser, and custom tabs at least provide an "in-app" interaction - the browser becomes part of your app's back stack, with some styling options to make it fit better with your app, but retaining the security properties of a standalone browser. We at Google use the equivalent of custom tabs on iOS (SFSafariViewController) to implement authentication for our apps. I have seen AppAuth adopted for both enterprise and consumer authentication use cases, particularly where the app wishes to maintain flow consistency across multiple IDPs.
If all you are integrating with is Google and Facebook, native SDKs are probably fine and may give you a better experience. If you are integrating with other options, I would recommend using AppAuth, or building your own web entry point for authentication.