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?
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.
Related
Suppose I am enrolled with fingerprint in device so can we save something to google smart lock like adaptive token and next time when user reinstall the app and try to login app we can fetch adaptive token and do login using fingerprint?
You cannot use biometric verification to install anything on the device. You can use it only to verify that the person is authorization to use the device (or at least can unlock it). You need to kind of login binding to do that e.g. Firebase Auth, there you can store everything you need to restore your app state.
I have followed the following guide to get Sign in with Apple functioning on Android using Firebase: https://firebase.google.com/docs/auth/android/apple
When a user first logs into my app with Sign in with Apple they will be required to enter their login details and authorize my app. However, it seems that if the app is closed and reopened they will also be required to reenter those details each time.
Other Auth providers I have integrated have supported a silent authorization method, checking if the user has already authorized the app on this device or have given access to a refresh token which can be stored and used later. How can I access either of these through Firebase's implementation?
Firebase Auth allows an authorized session to persist on the Firebase side of things, without holding on to or reauthenticating with the other third party Auth providers. The key words to Google are "auth state persistence". Here's a link: https://firebase.google.com/docs/auth/unity/start
When the app successfully logins in via Facebook it begins to save the credentials. This should ask the user if they want to save it with SmartLock or not, but it's being saved automatically.
Inside the save callback I get a success with no resolution. It should not be a success, and it should contain a resolution to allow prompting the user to save.
Is there any reason why this is, or any way to get the functionality I want?
-Thank you
Password-less "credentials" can be saved without needing to prompt the user (i.e., credential built with .setAccountType in place of .setPassword) if the identifier on the credential matches a Google Account on the device.
And in general, when the user returns on another device, user can be immediately signed back in if they are using an account for the app that matches one on the device, since such credentials will come with a token you can use for auth. For example, gmail user whose account is active on a device (and could otherwise receive email, such as for a password reset flow), can be signed in to apps without need extra UI or to trigger a Facebook flow unnecessarily to get a different token.
In the past, the API required prompts to save any information, but we found in user research testing that minimizing the dialogs users encounter reduces confusion, streamlines the user experience, and promotes security best practices (such as using tokens from authoritative issuers when relying on email-based identifiers).
I'm trying to integrate an existing login system for a mobile application with some social media sign-in solutions. I successfully managed to integrate both facebook and google+ sign in with my app and I get to the point where the users are signed in and I can get their social information.
But now I was left wondering which would be the best approach in order to integrate users that decided to use a social media account with my native login system. Should I use their email accounts as login and maybe generate a password on the server side? Or maybe use an oauth token instead of a password?
I need to keep track of my users, even the ones that did not formally filled a registration form. So what should I place instead of email + password?
This can be tricky - the majority case is easy, but you need to think about the edges. I find it easer to consider email/password as just another authentication mechanism. You want
A user record with the core data about that user (perhaps name, email address, app specific profile data etc.)
A series of records for their connected auth methods, e.g. Google+, Facebook, user/pass.
The connected auth methods can store the relevant information for those methods - e.g. for Google it would likely be Google user Id and perhaps refresh token if using offline access. This makes it easy for you to offer connecting multiple social accounts.
Password may be a special case that you want to store against the original user record. In that case, if someone signs-up using a social login, then you can either generate a random password, or leave it null. Either way, as long as you request the email address for the user, you can always let them go through a Forgot Password flow (where you generate and email them a password) if they want to access their account but no longer have their 3p login.
What you don't want to do if avoidable is to force the users to give you a new password just after they sign in. However, it you are allowing multiple login methods to be associated with one account, you might want to allow associating them. So, your flow might be:
User signs in (with 3p or email/pass)
If you have a record for that login method (e.g. matching Google or Facebook user id, matching email/pass combination), sign the user in, and you are done.
If you have no matching record for that sign in method:
See if you have a matching email address with an existing user account. If you do, some sites automatically merge the new login method to this account. If privacy/security is more of a concern you might want to confirm the user wants to login to that account, or make them go through a 1-time validation (e.g. "it looks like you've signed in with a password before, please enter your password now to link your account and your Google account" etc.). Then link the accounts and continue as if signed in.
See if you have an account which may be that person. E.g, perhaps you have an account with a matching name. In that case, you might want to hint the user to connect their accounts (e.g. a prompt somewhere that says "have you connected before with Facebook? Click here to link these accounts" which then takes the user through a sign in process for the login method you suspect they might have).
If they look totally new, create a new user record, and treat them as newly signed up.
Its significantly easier if you can treat email address as a unique field. That means if someone signs in with a 3p account associated with an email address you already have a user for you might have to force them to link their account before continuing. If they didn't want to and you required an email address, you could prompt them to enter one manually and then validate it as normal by sending them an email and having them confirm it.
ChrLipp's links are good, also take a look at the guide for using FB and G+ together on the Google Developers site: https://developers.google.com/+/best-practices/facebook
How did you implement the social media sign-in's? For example Facebook: did you use Login for Android? In this case the docs say under Checking login status:
Apps using our SDKs can check whether someone has already logged in using built-in functions. All other apps must create their own way of storing when a person has logged in, and when that indicator is not there, proceed on the assumption that they are logged out.
And if you follow the link to Storing access tokens and login status you can read:
The token should be stored so it's available to all parts of the app when it makes API calls. ... If you're building a ... mobile app, then you should use the datastore available to your app. Also, the app should store the token in a database along with the user_id to identify it.
Have an enumeration (NativeLogin, Facebook, GooglePlus) and depending on this enumeration the following information:
NativeLogin
UserName, Password
Facebook and GooglePlus
Facebook or GooglePlus ID and their User Access Token
In all cases you should store the email adress you get in an additional field.
I'm using the new Google+ Sign-in api. Once a user clicks sign in they can choose which google account to use, and then proceed to authorize the app. How can I get the account which they picked?
Reason being is I have been using regular google auth for my app and the users account is tied to the email address. With this Google+, I'm not sure how to get the account email without asking the user to selected the account again.
You can retrieve the user's profile information by using the PlusClient.loadPerson() method, which can include their email address if they choose to make it public. To reliably get their email address, you would use either the PlusClient.getAccountName() or use the userinfo REST endpoint after requesting the userinfo.email scope.
The code examples in the documentation walk through each of the above cases.