Stack Overflow is a community of 4.7 million programmers, just like you, helping each other.

Join them; it only takes a minute:

Sign up
Join the Stack Overflow community to:
  1. Ask programming questions
  2. Answer and help your peers
  3. Get recognized for your expertise

We are creating a service (backend + iOS-app for now) where a user can log in. We have completed our own custom token-based login system with registration. We are now trying to implement the function where they can select to "Log in via Facebook" or "Twitter" etc. (I.E not using our custom registration with username and password)

We have successfully implemented the client-function, but all we receive from the 3rd party service (Facebook) is a token, and the user's basic information.

To use our service, it is (of course) required to have a proper CustomUser-object (our own) registered on our server, which generally would be created on our custom registration. When logging in through 3rd party service, how should we create a CustomUser-object for that externally authenticated user?

When the user is authenticated by a 3rd-party service through our application, how and what do we send to our own server to register (or authenticate)? We receive an auth-token (which will eventually expire), and the app (client) has access to the user's basic information on the 3rd party. We were thinking of sending the basic information, such as the user's user_id and email along with the token, up to our own server and create a new user-object for it if it didn't exist before. However, we realized that this wouldn't be very secure at all. When the user logs in to our service the next time, using the same 3rd party authentication, we only have the users user_id and email to match. The token might be a new token. Which means that anyone intercepting any 3rd-party login-calls to our server will see that the only information needed to log in to an existing customUser based on a 3rd-party authentication is the user_id and an email. Which are very public on most such 3rd-party services, such as Facebook.

We've been trying to read up on OAuth and authorization/authentication using these 3rd-party services, but every single documentation we've seen is painfully focused on the 3rd-party authentication and doesn't touch the subject of our own authentication of the 3rd-party authentication..

Are we going about this all wrong?

share|improve this question

Actually, the assertion you made about email and user_id is not totally true, at least for Facebook.

... Which are very public on most such 3rd-party services, such as Facebook.

When somebody logs in through Facebook Oauth service, you'll get back an "app_scoped_user_id" which is a unique ID that Facebook creates for the user and your App. Each user will have a different "app scope user id" for each App he uses and nobody except you (the App) will know that "app scope user id".

App scope user id docs

So I'd say using the "app scope user id" as identifier of your users is secure and the best way to do it.

Not sure how it works with other services like Twitter but I'm pretty sure you can do something similar. Even if the user_id is public, it should be always unique and you can use it to identify your own users.

I hope it helps.

share|improve this answer
    
I'm not so sure.. if I go to facebook.com/[received userID], then I get to the correct facebook-page. I think I'm receiving the actual userID, not a scoped one. Anyway, if it is possible, it's not helping me with the security. It would just mean that anyone could enter an email and test all probable scoped userID's from facebook. We are trying something now, receiving the token from facebook, and connecting to facebook from our server - running their command debug_token, which in turn will tell us who the token belongs to. I believe that's enough. – Sti Apr 15 '15 at 18:34

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.