2

I'm logging my users into our app using Google+. The actual G+ signing in happens on the server though. I get back some user data such as email and name. I'm using this to store the users credentials as a google account.

The issue arises when I try to save it. In the callback to save the creds in "Auth.CredentialsApi.save" it returns no resolution and nothing ends up happening. If I remove the Google IdentityProvider from the creds then it saves without a password.

Does anyone know why a resolution is not found when the IndentityProvider is set?

Elforama
  • 512
  • 1
  • 4
  • 16

1 Answers1

2

In Play Services 8+, no resolution (confirmation UI) is required to save a Google Sign-In to the user's Google Account using the Smart Lock API (i.e., the credential's type is set to IdentityProviders.GOOGLE and the email address matches one signed in on the device, and the user has not disabled saving in settings). Note that you cannot set both an account type and password on a credential object when saving with the API -- if a user has a password simply store that for authentication purposes.

An API call with a credential of this type should save automatically and be available immediately, so just check that this credential is available when making a Auth.CredentialsApi.request() using a CredentialRequest built with .setAccountTypes(IdentityProviders.GOOGLE) and that the saved credential is shown on passwords.google.com and has "with Google" in place of a password.

When retrieving this credential, you can use it to know that you've got a user with an existing account and they signed in with Google previously. You then can customize the auth UI for this returning user, or simply trigger a Google Sign-In flow for the user automatically and give them a returning user experience when the app starts using the Auth.GoogleSignInApi.silentSignIn() method in the latest version of the Google Sign-In library. Here's a full code example.

Steven
  • 3,812
  • 23
  • 38
  • A couple unofficial notes on potential future roadmap: we are considering removing need for confirmation UI when saving just the email address with no password when the email matches one on the device (so that app can bootstrap all existing user accounts with a background save), and we may backfill all Google Sign-In grants to facilitate automatic cross-device sign-in (but for now, we recommend saving the Google-type credential explicitly to help users sign back in using the appropriate method when they return). – Steven Jan 04 '16 at 22:12
  • Thanks for the reply, although my issue persists. The app will not save the password if I save it as a Google account, only as a username without an email. Is there any reason as to why this could happen? – Elforama Jan 14 '16 at 22:01
  • If user signed in with Google, shouldn't need a password? Otherwise, just store the username and password for sign-in purposes and use that? Yes, the API won't allow a save with both the account type and password fields set ... let me know if I misunderstand the use case? Could you add snippets of how you construct the credential and call the save API with it to the question? Thanks! – Steven Jan 15 '16 at 13:49
  • I seem to have found the problem. I was signing in using my company managed google account. This would always have Smart Lock fail when trying to save the credentials as GOOGLE. When I switched to some plain gmail test accounts it worked fine. – Elforama Feb 04 '16 at 15:11
  • Hmm, interesting. Let me do some more investigation on this (I've tested with Google Apps for Work accounts before and seen them work, but perhaps there are some restrictions). – Steven Feb 04 '16 at 21:04