In order for my application to connect to Facebook, they click on a connect to Facebook button. This button with authorize the user, and when they are authorized, i am able to get their access token by calling facebook.getAccessToken().
But is there a way for the application to remember their credentials so that they don't have to login every time they want to connect to Facebook (without storing their access token in some sort of database)?
You can find a good example of doing that in the FB SDK examples using SharedPreferences: https://github.com/facebook/facebook-android-sdk/tree/master/examples/simple/src/com/facebook/android
You can store the access token there, since it expires after an hour or what and the user needs to authenticate again.
If you are asking for offline permission, you can save the token and reuse it (until they either remove your app from their permissions list, or (I think) change their password).
See https://developers.facebook.com/docs/authentication/permissions/ for information on the permissions available (search for offline_access).
Related
When using OAuth we are using a third party to take care of the authentication of a user.
E.g. when using Facebook we “register” our app with Facebook and when a user of our app tries to login instead of providing to the app his credentials he logs in using his Facebook account.
What I don’t understand is why does the app trust the user? All the app knows is that the user is trusted from Facebook as he has an account there. How can we trust that the user should really access the app?
In this case the "user" you are providing services to is the Facebook/Google/Instagram/etc. account. From your perspective, you do not care who the person typing the credentials in is.
Normally, all you know is that the person who logs into your app knows the user name and the password for the account. In the external validation case, you know what the person has this specific login for fb/google/inst and knows the password associated with it.
Please keep in mind than in most cases (local or external validation), you do not know the person associated with the account (unless you have some method of personal validation, like credit card or sending a traditional letter with some auth). All you know is that the person who logged in knows the credentials.
Technically, each of those accounts (fb, google, inst) is a separate "user", and your local credentials login is a different one yet.
The whole concept is about user convenience really, plus some additional benefits like having the user data stored and maintained by someone else, additional security and so on.
That said, it is still totally fine if you stick to the "local" credentials method, just make sure it is secure :-)
EDIT:
A simple example:
Your app has two login options - a simple login with password and login with Google.
You also have a user, John Smith.
John opens your app, which requires login and has some sensitive data connected with each account.
Scenario 1. John selects standard, "local" login option and logs in using his credentials JohnSmith1111 and password 12345. John is now able to display the data associated with the account JohnSmith1111.
Scenario 2. John selects log in with Google. He is redirected to the login page, authenticates there and returns to your app. Your app is notified that the user google_john_smith has successfully authenticated. John is now able to display the data associated with the account google_john_smith.
The point is that the account validated using those login options is not the same! There is no "trust" issue here.
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.
Is there anyway to store an access token to be used later?
IE:
user1 logs in to my app then logs in with Facebook Dialog Auth
app stores facebook access token
user1 logs out of my app
user2 logs in to my app then logs in with Facebook Dialog Auth
user2 logs out of my app
user1 logs back into my app and continues to use facebook with access token stored originally stored from the first login?
===
I should clarify a bit...
I'm trying to figure out to have multiple facebook accounts tied into my app. So that when different users login, they can access their individual facebook accounts.
Access tokens expire, over time. So you should check if it is valid when the user logs back in and handle expired access tokens when encountered in the way mentioned here.
If you are looking to use offline_access to extend the expiration date, that is soon going away. Now, you will have to renew the access token as mentioned here.
The offline_access permission was deprecated and removed December 5th, 2012
I am using the Facebook SDK to connect my native Android app to Facebook. I am able to show the login page and make users login into my application through their facebook account. But according to: https://developers.facebook.com/docs/mobile/android/build/#sso
I have to watch out for two activities, such as revoke of access and password change. The response parameter will return the following results:
User revoked access to your app:
{"error":{"type":"OAuthException","message":"Error validating access token: User 1053947411 has not authorized application 157111564357680."}}
OR when password changed:
{"error":{"type":"OAuthException","message":"Error validating access token: The session is invalid because the user logged out."}}
Now, my question is, how do I handle or catch the following errors? Thanks.
There's an official guide for that: Handling Invalid and Expired Access Tokens.
For android it states:
Android native applications
You may detect access token errors by inspecting the response
parameter of the onComplete method. In this case, you will again need
to call facebook.authorize() to re-authenticate the user and generate
a fresh access token.
Hello I am using the facebook sdk for android on my android phone and using single sign on. It works fine when I logged into the facebook application, my application also signed in.
For logout I encountered a confusion.
The way I implemented was restore the access token and expired date from the user preferences of the application and check the validity of the session. If expired the application calls the facebook.authorized function and once authorized the access token and expired date will update again.
There are few things I find a bit confusion when dealing with the logout.
1) When I logged out from facebook application, my application still can get through and request the user details. Although, my saved access token on my application has no relationship with the facebook application, I thought it will at least giving me an error when requesting the data. But it hasn't given me the error.
Does it suppose to be actting like that. Signing out from facebook apps will not affect the access token I have stored on my application.
2) When I logged out from my application and not the facebook application, the facebook application won't automatically logout.
The Facebook access token and your app access token are separate and distinct, so it is entirely possible that one can be valid and allow access while the other is not valid and will require re-authorisation.
If the Facebook app is logged in but your app is not, then the Facebook SDK will use the existing Facebook app login to obtain a new access token for your app without authenticating, but this is still not linked to the Facebook app login token in any way.
If the Facebook app is not installed, or not logged in, then the Facebook SDK will take you to the Facebook website to do the initial authentication, but this does not log the Facebook app in because there is no connection between your access token and the Facebook access token.
So, in summary - your understanding is correct. There's no interaction between the two apps except for when your app tries to authenticate a user, then the Facebook app will act as a proxy, allowing you to gain access without authenticating so long as Facebook is logged in. After that, there is no further interaction and what you've observed is expected and intended behaviour.
I have the same problem. I'm thinking about creating a "isLogged" var and store it so that when someone logout and restart the app it will not even verify if the user is logged bypassing facebook's session verify.