I'm curious how these systems work technologically. As I understand it you do the following as a user:
Go to your favorite 3rd party site.
Click the "Facebook Connect" button.
Log into Facebook (if not already).
Authorize Application
You are routed back to the 3rd party site logged in.
But, how does the 3rd party site talk to FB about who you are? I can understand how it could get the information it needs when you initially authorize the application, but how would it know afterwards? Here's a scenario:
You go to Facebook and log in.
You then go to your favorite 3rd party site (which you already authorized).
It already knows you are logged in!
A background ping using an IFrame is performed, and if the currently signed in account has already authorized the application, then the access token and user id are returned to the application. With this the application can decide what to do (usually, set a cookie and refresh the page so that the server can re-render the page knowing who you are based on the cookie that was just set). If you're curious, you can look at the Facebook implementation of the client side JS method called FB.getLoginStatus() here: http://github.com/facebook/connect-js/blob/master/src/core/auth.js#L117
It's using a 3-legged authentication system called OAuth.
After you start the process, the 3rd party site connects to Facebook, and if you were already logged into Facebook (live session with cookies) then it will just use that, and ask permission to authorize the 3rd party app.
Once it is authorized, it will get an auth_token, which it can use to access information from your account, unless you revoke it's access.
Check out OpenID. Also this presentation is very interresting: Facebook Connect vs FriendConnect
It all happens through OAuth2 mechanism ,where the third party application already registers with the facebook(or any other website which has oAuth2 implementation) and gets the Id(usually termed as clientId) and secretCode(i.e., clientSecret).
So, when you want to login into the third part app through fb, the service provides (clientId+clientSecret+callbackUrl )---> to facebook.while , the first two were to authorize the third part service and callback URl is URL where facebook responds back with a "accessToken" for that account.
Using this accessToken , the third part service will invoke facebook's graph api's to get the user related info and use them to login the user into their service.
Related
I have a REST service that my mobile app uses to authenticate when the users click on the Facebook or Google icons.
The service accepts the user's id from the provider and checks if it exists on the database and then issues the access_token to be used for the other methods.
The problem is that I just thought that it could be pretty easy for someone to intercept the calls and discover which service authenticates and what the user id is and then call it with to get a token.
How can I avoid this?
I think you just need to separate the authentication and authorization functions. You can let Google (Google Sign-In) handle authentication. If you follow the API they will securely authenticate the user and send you the token which you can validate.
Once you know who they are for sure, your site can safely authorize that user approriately. For example, they might be an existing user, need to make an account, be an administrator. You can make those authorizations on your site based on the user authenticated by Google (in my example).
Twitter, Facebook and others do the same. Also see OpenID Connect.
I'm running a Classic ASP website, that has its own user authentication and login mechanism. For example, In order to remember a logged-in user, ASP creates an encrypted cookie and a 20-minute session for each connected user. If the 20 minute session is elapsed, the server revives the session from the cookie saved previously, and saves some data regarding the user to the database.
I want to to be able to allow users to connect with their Facebook or Google identity, but the mechanism used by Facebook or Google is based mainly on Javascript and on client-side code.
How Facebook or Google login can be used while maintaining server side code in ASP? (So that the ASP server can still manage the session and save data regarding it, for example whenever a session is revived)
For me somehow it seems that it may become less secure to use client-side authentication as the code may be altered easily. Isn't this the case?
If I use client-side javascript and log in with Facebook, how would I update the user data retrieved from facebook back into my database, for example the user's first and last name?
For me it sounds that it should be a "server-to-server" communication (between my ASP server and Facebook's or Google's servers) and what they propose is a "client-to-server" communication ... Any ideas how this can be done?
Any help or explanation would be very much appreciated! Thanks.
I'll try to address your Facebook-related questions one by one. However, I will not give you an implementation or any ASP-specific feedback, but only a rough approach. Additionally, I recommend that you study Facebook's documentation on Facebook Login extensively to further your understanding of the matter.
1. Facebook documents the server-side OAuth 2.0 flow in their Manually Build a Login Flow guide. Basically you redirect the user to a specific FB URL that (in the parameters) tells FB to render the "Login with Facebook" dialog, and which permission scopes to ask for. Once the user approves the Facebook Login for your webapp, they will be redirected back to your web app, e.g. with an OAuth token in the query string, that your webserver can then exchange for a user access token.
Once you obtained a user access token, you could e.g. store it in your web app user's session.
2. I don't know what you mean. Client side apps are fairly secure. Perhaps you can convince yourself about how secure JS apps are when reading about things like CORS.
3. If you only use JavaScript (e.g. Facebook's JS SDK) and you want to store e.g. app-scoped user IDs on your server, you need to expose an endpoint on your server that your JS application can submit that kind of information to.
4. You state
what they propose is a "client-to-server" communication
Who are "they", and where are the proposing this? The resources I linked to in 1. should explain how you can use Facebook login in a pure server-to-server way.
The Facebook Platform Policies section 1.6 clearly states
Your website must offer an explicit "Log Out" option that also logs the user out of Facebook.
The Login Flow for Web without Javascript SDK says on Logging people out
You can log people out of your app by undoing whatever login status indicator you added, for example deleting the session that indicates a person is logged in. You should also remove the stored access token.
On the other hand the Login Flow for Web says about Logging people out
Note: This function call will also log the person out of Facebook. The reason for this is that someone may have logged into your app and into Facebook during the login flow. If this is the case, they might not expect to still be logged into Facebook when they log out of your app. To avoid confusing people and to protect personal security, we enforce this logout behavior.
So in my understanding the Login Flow with JS SDK does what the policy says, it logs the user out of Facebook as well. How do I implement the Login Flow without JS JSDK correctly, such that i do not violate the Facebook Platform Policy? So far i don't see that the Graph API offers a similar functionality.
That should be easy, looking at the PHP SDK’s method getLogoutUrl, that creates an URL of the following scheme:
https://www.facebook.com/logout.php?next=FOO&access_token=USER_ACCESS_TOKEN
For FOO you just place the URL of your website where you want the user to be redirected to after they are successfully logged out of Facebook (don’t forget to properly URL-encode that value), and USER_ACCESS_TOKEN should be self-explanatory. (You need an active user access token to log the user out of Facebook – obviously, because otherwise every site on the web could just redirect me to this address and log me out of Facebook, without me actually wanting that to happen.)
there is an facebook application, you can see it there:
http://www.facebook.com/tdmtravelclub?v=app_197602066931325&app_data=wlbb%3D1
You have to like it and than you can play a game (you don't have to i just explain the functionality of it).
This application isn't forcing you to login (i think the authorization is automated), but they can query the user data (they see if you liked the site).
I lookd for a similar authenthication method for fb apps but i didn't found one.
The only thing you know about a user (who has not authorised your application) within a tab application is if he is a fan or not. Facebook sends this information via the signed request.
PHP SDK Demystified – What is Signed Request?
Authentication within a Page Tab
SO Question including signed request
I want to allow users connect to my website using their facebook account.
First, the user authorizes my application and then I get an access token. Problem is, that I'm supposed on the first time to register the user, and the next time to auto login him based on his facebook email.
How do I create a SECURE way to auto login the user?
I'm using pure javascript, but I can't find any way to create a secure mechanism.
Thanks.
Facebook should handle all that for you - when they come back to your website, they can click the 'login' button(javascript SDK) and facebook should pass you back an access token.
I may, however, have misunderstood the question.