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.
Related
I want to enable my users to associate their user account with a Facebook or Twitter and allow them to login on my server with their Facebook/Twitter account instead of using the classic username/password. Basically the same idea as the login in StackOverflow.
My current approach for Facebook:
The client application will perform OAuth and then use their Facebook id to login on my server. Based on this Facebook id, the server will lookup the associated user account and perform login without asking for username/pasword. However just relying on the Facebook id to login is not very safe, as that is the same as using only a username to login instead of username & password.
So to make sure the Facebook id is authentic, the client application will also provide a FBSR (Facebook Signed Request, see: https://developers.facebook.com/docs/facebook-login/using-login-with-games/#checklogin) with the login request.
The server will check two things with this FBSR:
The Facebook id in the request must be the same as the one hidden in the FBSR
Server will recalculate the signature part via the Facebook secret key. This must match with the signature in the FBSR .
Normally the server should perform a check with the Facebook server with the oauth_token to be 100% sure of the users identity. However I need skip this in order to avoid dependency to Facebook server on our server.
I have 2 questions:
1) Is this above approach good enough? Can it be improved (without server-to-server communication)?
2) I want to do the same with a Twitter account, but the their signed request is different then Facebook. It seems the Twitter user id is embedded in the oauth_token, so my approach may work with a little tweak, but I am not sure whether the user id is always part of the oauth_token and cannot get this confirmed after searching the internet.
I think that your approach is good enough and don't see any way to avoid server-to-server communication with a signed request. Bear in mind that, with Facebook Graph Api Version 2, in order to protect the privacy of the user, Facebook will send out not the real user id, but one generated for apps. It will also be possible to enable anonymous login.
I am not sure of what you're trying to do with Twitter, and why you compare the APIs (they're quite different). The Twitter login, also know as Sign in with Twitter, used for any website or mobile app, should work for you too.
I'm trying to build a Facebook-authenticated native mobile app (Windows Phone) that connects to a web service I am creating in Node.
I'd like for a user to:
Log in to Facebook on the mobile app via a native UI or web window
If logged in successfully, create or access server-side user account data tied to that identity
Use the authenticated session to make subsequent authenticated requestsvto that user's data via the native mobile app
My question is: What's the best approach here?
Should I...
Log in the client to facebook locally in the mobile app and pass the Access Token to the node service, and then somehow map the user to my service data based on their facebook account id? That seems grossly insecure if I just pass that token in the URL.
Log the user in via a mobile browser window inside my app, and then redirect back to my Node service in the same window? How do I then make subsequent authenticated requests natively in my app?
Do something else entirely?
Sorry this is so open ended but this is the first time I have tied these things together and although there's a lot of info on each part I've yet to find something that describes the overall pattern / best practice for this design.
Your question is quite opinion based...but still I will try to help.
First of all, you can pass access token in url, its not insecure if you use https. Even if logged into facebook from your mobile app, than also its going to pass a access token in url only. If you mean having the token in http://something.com/access_token, than its not how its should be done.
If you look into the Oauth 2.0 draft you will understand that its done through setting a header Authorization with the value being the token and token_type. Take a good look at the draft.
As your solution I think its fine if you just use the first method mentioned in the question by sending the access token in header as I mentioned in your app and in turn authenticating that token from facebook on each request.
If you think this is just too long a flow for authenticating every request from facebook, than you can get access token by sending request from your mobile app to server and let the server handle the access token and store it in database which you can authenticate each request.
In any case take a look at Passport module, it has facebook and other auth built-in and should be sufficient for your needs.
I'm writing an API for our product and I'm trying to understand how some basic OAuth works with regards to mobile apps that might leverage our (to be created) api.
Lets imagine that our website currently allows a person to LogIn to our site via Twitter OAuth.
On the callback from Twitter, our server retrieves the twitter OAuth result and if all good, then checks to see
if this user already exists in our DB (eg. lets assume the Email is the unique key). If they don't exist, we
create a new user.
Of course, we then log the user 'in', which means we create a cookie for them, for their browser.
So far - nothing new here. All normal stuff.
Now .. if we want to do this via an iPhone or Windows phone using their native language and the app's use our API, i'm not sure of the point where OAuth ends and our API takes over?
For example, lets pretend it's an iPhone app that takes advantage of our API.
The iPhone app will try to authenticate the user against their Twitter cred's. Ok, fine. But when it callsback, it's back in the phone, right? Not our servers. So then the app needs to try and create a new user? So then the iPhone might try and call /api/CreateAccount. But this means -anyone- can call this api? And how does the website really know they have authenticated? Only because the app says so? What's to stop the person from creating a malicious app and calling our API by flooding it with new account creations? And what about authentication to api resources? Forms Authentication isn't available here. So do people use querystring authentication over SSL for api calls? How does the iphone authenticate with -our- server?
I'm so confused.
Can anyone please explain the differences and common practices people are doing these days when they have a website and an api .. and use OAuth as the authentication mechanism, please?
The naive app would call not CreateAccount, but VerifyAccount with twitter's oauth set of data so you site and API could verify it. The site would respond with a unique userID and your iOS app would use that as it's internal user id. More info.
Can the Stack Overflow community sanity-check this for me?
I am working on a project that involves two components: an iOS app and a mobile website. It's for a product that will interact pretty heavily with Facebook. The website is hosted on Heroku.
From iOS land, my intention is to use the Facebook iOS SDK for authentication and then hit the web API with the user's access token at https://[myappname].herokuapp.com. Since Heroku offers piggyback SSL when using the herokuapp.com domain, and the user won't be seeing this URL anyway, I figure that's fine. And this way the request is encrypted, so the access token should be safe.
From the mobile website, users will log in using Facebook, at which point my understanding is that the access token will be in their cookies, which my server can then access without having to exchange it back and forth with each request. By this reasoning it seems to me I can just stick with regular unencrypted http:// URLs for the website (and therefore use my custom domain name without having to pay a monthly fee for Heroku's SSL Endpoint add-on).
Does this all make sense? I will be the first to admit my understanding of a lot of this stuff is in serious need of an upgrade. But for now I'm just looking for someone who can tell me, "No, you're totally overlooking/misunderstanding XYZ" or "Yeah, this is how it's generally done."
Facebook advises that you should not take a dependency on their cookie format. They have stated that the cookies are "an implementation detail" that they may tweak at any time with no notice given. You should not directly access the token or other user info directly from the cookie. I personally have had some bad experiences trying to get user information directly from the cookies, mostly due to timing -- they were not always there or updated when I expected them to be.
Client-side, you should either get the access token from the Javascript SDK via FB.getLoginStatus or other method that returns the access token, and then post it up to your server. This should really be done using ssl otherwise you are susceptible to network packet sniffing where a black hat could grab the token and be able to use all of the privileges the user granted your app.
There is also a server-side option as well which hits at ssl endpoint on Facebook's servers to return an access token.
References:
"Cookies are an implementation detail": https://developers.facebook.com/blog/post/624/
Authentication docs: https://developers.facebook.com/docs/authentication/
Website login via Facebook works totally fine via HTTP.
I need to post message on a certain FB page as a owner by cron, using php and ZF 1.1.X. For this small issue, I don't want to create a full OAuth stack. Is it possible to communicate with FB API (it's desirable, PHP SDK for FB) without it, such as twitter with his precreated access tokens (Access token, Access token secret)?
As long as you need an active user access_token to retrieve desired data this is not possible to skip OAuth flow.
Without authenticating user you only have application access_token (in old format APP_ID|APP_SECRET, but it's still works) and only limited access to most of Graph API endpoints and Application settings.
Actually there is nothing hard in implementing the user authentication with OAuth flow and it is completely transparent with usage of PHP-SDK.
Just look at the sample code in documentation for server-side authentication
Yes, you need to build an app and then authorize the page via the app while requesting the manage_page permission.
You should make yourself familiar with the Server Side Auth process as well.