8

When deling with access token OAuth 2.0 In a nutshell what's the difference from using:

AccountManager.getAuthToken ("oauth2:https...userinfo.profile"),

and using Google Plays:

GoogleAuthUtil.getToken(mActivity, mEmail, mScope)

As I understand it they both produce a challenge screen for the user, the Google Plays screen is user friendlier. The access token can have same scope right?! Both call have to be asynchronously. InvalidateToken looks like it has to be checked for in both calls, and more?

enter image description here enter image description here

Erik
  • 5,039
  • 10
  • 63
  • 119

1 Answers1

24

I didn't know about using Google Play services for OAuth 2.0 authentication, but after taking a quick look at it, it looks pretty interesting and I think it's something I could prefer to use over the AccountManager.getAuthToken.

Major differences

AccountManager.getAuthToken

Pro:

  • Can be used for all Android 2.0 devices and newer.
  • Is built in to Android and doesn't require any separate SDK.
  • Can be used for all types of accounts that has an authenticator, not only Google.

Con:

  • Returns a token that may have expired so you always have to invalidate the token and request it again to make sure you have a valid token.
  • Requires the permissions GET_ACCOUNTS and USE_CREDENTIALS.
  • Challenge screen is not user friendly for Android 2.*

GoogleAuthUtil.getToken

Pro:

Con:

  • Require Android 2.2 and that the device have Google Play
  • Require that you download and include the Google Play services SDK in your app.
  • You need to register your app in the Google API Console
  • Can "only" be used for Google services that uses OAuth 2.0

Challenge screen comparison

AccountManager.getAuthToken Challenge screen on Gingerbread and Ice Cream Sandwich

getAuthToken challenge screen for Gingerbread getAuthToken challenge screen for Ice cream sandwich

GoogleAuthUtil.getToken Challenge screen

getToken challenge screen getToken challenge screen, more details

Summary

Since the GoogleAuthUtil approach has a much user friendlier challenge screen and requires less permissions at install time I would definitely use this approach instead of the AccountManager.getAuthToken approach whenever I can. Since you always get a valid token and don't have to hassle with invalidating the token it should make the code simpler as well.

Community
  • 1
  • 1
nibarius
  • 4,007
  • 2
  • 38
  • 56
  • Im only reading about GoogleAuthUtil.getToken will try a sample now, nice summery you did that sums up my findings and the invalidating and random exceptions thrown by the AccountManager is terrible. I think the OAuth 2.0 support for AccountManager.getAuthToken was "experimental" and this is the real deal maybe, – Erik Jan 17 '13 at 17:42
  • Tackar så mycket, hoppas några fler slänger in sina 5-cent i denna diskussion. Check this out by [Tim Bray](http://android-developers.blogspot.se/2013/01/verifying-back-end-calls-from-android.html) – Erik Jan 17 '13 at 17:50
  • 2
    nibarius has it right. If at all possible, the GoogleAuthUtil approach is the one to take, it’s where we’re investing all our eng efforts. – Tim Bray Jan 17 '13 at 21:57
  • 1
    I've updated the answer with screenshots and restructured it to be easier to read. @Erik I hope you don't mind that I used your screenshots. – nibarius Jan 18 '13 at 09:44
  • @nibarius which is better? **GoogleAccountCredential.usingOAuth2(...)** vs **GoogleAuthUtil.getToken(...)** you can answer here https://stackoverflow.com/questions/22142641/access-to-google-api-googleaccountcredential-usingoauth2-vs-googleauthutil-get – LOG_TAG Mar 11 '14 at 11:09
  • 1
    @LOG_TAG thanks for the pointer, I gave an answer in that question. – nibarius Mar 11 '14 at 19:59
  • GoogleAuthUtil.getToken doesn't always return a valid token. When my app is authorized but I revoke the access in https://security.google.com/settings/security/permissions the call still returns a token but not a valid one (can be checked at https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=token). There seems to be some caching involved... – Emanuel Moecklin Oct 16 '15 at 02:16