Best practices (best for Android): authenticate a user with Facebook or Google login

0 投票
最新提问 用户: (160 分)

I am developing an app with both Facebook and Google option for login, as well as a classic e-mail+password login. I am catching myself wondering about several things regarding signing in with third-party APIs:

1. since one user could sign in with his Facebook account and later on decide to log out and sign in with his Google account, the user should be recognized by his e-mail address. So whenever he signs in with a different account, the e-mail address is searched in the database and if it is found, it attaches this new signin to the previously created account. Just approve this point,please.

2. If the user signs in with Facebook login, you can get an accessToken, userId, user e-mail etc. What is the best practice to authenticate the user so that it is still the most secure way? Should I send his facebook accessToken and e-mail adress directly to the server? Should the server check against Facebook, if the accessToken really exists on Facebook? What is the best and most secure way to generate an application-private access token on the server side? I have heard something about MD5 hash...Should I then use only this newly generated access token in API calls and not use any of the facebook credentials? Or should I use the Facebook credentials and thus save them on the server/client side? I am going to use Java App-engine for the server side of my app.

3. What if the user deletes his account on Facebook? How will the app know about this? If it knows it anyhow, what should it do with the account?

  1. Should I regularly check the access token against Facebook if it is still valid? Why and how and how often?

I am not sure if I am asking at the right place. If I am wrong, please, redirect me the way I should go, maybe some links on these best practices? So far, I haven麓t found anything that would answer ALL my questions. It is both coding and security related, I guess. Thanks for all of your tips and tricks.

发表于 用户: (100 分)
This is totally a long shot but few days ago Google added identity-toolkit into their googlesamples GitHub projects ; github.com/googlesamples/identity-toolkit-android . And identity-toolkit main web page seems to relate loosely to similar problematics you are asking about ; developers.google.com/identity-toolkit . All this is something I know next to nothing about but your question reminded me of this.
发表于 用户: (160 分)
Thanks! Could help answering some of my questions.

2 个回答

0 投票
最新回答 用户: (140 分)
  • 1 & 2

You can do it in multiple ways and is up to you on implementation, you can have your email received from each login hash it and save it as a user in your database. Then for any user that logs in can go through and hash the email returned and check if that hash already exists.

You can also have the user login with a service and then have them finish user creation with username,email password etc. Then when you try to login with a differential service you can have it go through the sign up again with a I already have an account button, as well as linking to an account if you try to create the same account twice.

Save the tokens associated in a third party login token table linked to a user.

I recommend hashing all user private data, gives users more trust with your app

  • 3

I never like to rely on third party accounts and believe the "finish creating your account" process would create better account management. Allowing users to sign in with both third party or username and password.

0 投票
最新回答 用户: (160 分)

After some reading and asking I have come up to this:

1. Yes, if you want your users to sign up with their Facebook or Google account, you call the API, get the e-mail address (it is even easier with Google麓s AccountManager on Android), send it to your server that will save the e-mail address, associate a userID and generate it麓s own access code. The access code will be sent back to your client app to store it for later use. Whenever the user wants to do some operations, the server API will be called with the user麓s e-mail address and access code and you can be sure it really is the user. It is much harder to call the API from outside and guess correctly both the e-mail address and access code so it is somewhat safe.

2. Since the Facebook login is only used to authenticate the user, which means to only verify that the user exists and has an account, we don麓t actually need the FB accessToken. We would need the FB accessToken only for API calls for Facebook server, so for example when we want to retrieve a list of user麓s friends and so on. In this case, you can get the active session that is provided by Facebook SDK and get the accessToken from there.

3. This case is again pretty simple. If you only use Facebook login to authenticate the user, you don麓t care if the user deletes his account in the future. After the first login, you save his email address, possibly a picture and no longer care about his facebook profile. If you use the Facebook login for getting a friends list and so on, you do not keep this type of data in your local storage anyway, so as soon as the user deletes his account, he loses his friendlist as well. Or, you can keep his friendlist and try to update it everytime he uses your app and once he deletes his account, the friendlist stops being updated and it is, again, up to your user not to use the Facebook account. The last idea would rather suit game apps use cases....just an idea, not anything officially accepted as the best.

欢迎来到 Security Q&A ,有什么不懂的可以尽管在这里提问,你将会收到社区其他成员的回答。
...