Comparison with AppAuth SDK - SURFnet/nonweb-sso-android GitHub Wiki

This page compares AppAuth for Android by OpenID with this SDK.

Methods of authorization

AppAuth SDK uses two methods to open the authorization page:

  • It uses Custom Tabs, if they are available. Since it is shipped with Chrome (45 and higher), it should be available on almost all devices.
  • If for any reason Custom Tabs are not available (Android version before Jelly Bean, or Chrome not updated / not installed), the SDK falls back to using the default browser.

In comparison, the nonweb-sso-android SDK uses only the browser for opening the page. Custom tabs support could be added, which would make the flow more smooth and faster as well, but it is just as secure as using the default browser.

Supported devices

I would like to note that the AppAuth SDK does only support devices running API level 16 and higher. As of now (Sept 2016), this covers 97% of all devices, so there might be users which could not install the app because of this limitation. nonweb-sso-android works on all Android versions.

App Links

AppAuth SDK also has support for App Links. This has been added in Android 6.0 (API level 23), which assigns your app to be opened for specific links. These link-app associations are verified by putting a specially formatted file hidden on that website. This ensures that the correct app will be opened.

App Links is a nice feature which solves the problem of callback interception, but due to the high API version, it is only available on 19% of all devices.

Comparison of artifacts

Because the AppAuth SDK has the support:customtabs library as a dependency, it's method count is above 10 000. Luckily almost all of these comes from the support-v4 library, which is already available in 99% of the apps, so if we don't count that, we get a method count under 1000, and an aar size around 100KB, which is fairly small.

The same is the case with nonweb-sso-android. Because we use the annotations library to make add some friendly checks to the code, the support-v4 library is pulled in here as well. If we don't count that, we get a method count of 54 and a jar size of 8KB.

The size of both libraries is small enough to not be a problem when integrating any of the two.

API

The AppAuth SDK gives you a lot of customizability, but you also need to use more code to integrate it. In nonweb-sso-android, the integration can be done by one method call, and the app will use an activity from the library to handle the state changes and callbacks. AppAuth asks you to do this yourself by wiring the calls into your own activity, this way you have more control over what happens, but it takes more time and effort to get it up running.

An extra thing to note is that the AppAuth SDK has built in OpenID support. This means that it can also integrate with OpenID providers such as Facebook, Google, Twitter, allowing users to log in with their 3rd party accounts into your app.

Demo

Both projects include a demo. The AppAuth demo is a bit harder to try, because it requires you to define at least one identity provider before you try it, so it requires some configuring beforehand.

The nonweb-sso-android SDK includes details for an example server and client, so it can be tried out immediately.

Activity

AppAuth is the more popular of the two. It has been around for half a year now, and received more than 50 pull requests since then. Issues are taken care of, and enhancement ideas are listed as well.

nonweb-sso-android is less popular, but issues are taken care of.

Tests and code coverage

AppAuth has unit tests, and code coverage checking for these tests. With around 30 tests, its code coverage is very good.

nonweb-sso-android does not have any tests, but is a lot smaller project too. Since there are no tests, code coverage can't be defined here.

Documentations

The AppAuth SDK has online documentations, and the sources are made available inside the aar file as well.

The nonweb-sso-android project publicizes the javadoc and sources as jar files too, but there are no online browsable javadocs.

Availability of artifacts

AppAuth is made available on Bintray, and can be pulled using a single line in the dependencies clause for Android projects. This makes it very easy to update the version later, and makes the repository smaller as well (dependencies are pulled instead of stored locally).

In comparison, nonweb-sso-android artifacts are made available as downloadable jar files for each release. These have to be downloaded and put inside the project which intends to use them, making version upgrades a more tedious task.

Licensing

Both projects make use of the Apache 2.0 license.

Conclusion

After comparing the individual aspects of the two projects, I would like to draw a conclusion. I would recommend AppAuth if you need to use OpenID Connect, or you would like to have more control on the authorization flow.

I recommend nonweb-sso-android if you have a simple OAuth 2.0 setup, and you just need a library that you drop into your project, and want to do the flow with a single call instead of overriding different activity lifecycle methods, and serializing the states, etc.

There are some improvements that would make this SDK more easy to use:

  • Publish online documentations somewhere (e.g. GitHub pages)
  • Publish artifacts on a publicly accessible Maven repository (JCenter, MavenCentral, Bintray, ...)
  • Add support for Chrome Custom Tabs, and fall back to browser when not available
  • Optionally add unit tests