Microsoft.Owin.Security.Facebook vs Facebook SDK for Javascript - javascript

In a .NET 4.5 Application, what are the benefits of using OWIN middleware Microsoft.Owin.Security.Facebook instead of the javaScript SDK provided by Facebook?
Looking at the example of how to setup OAuth2 Sign-on in MVC6 here http://www.asp.net/mvc/overview/security/create-an-aspnet-mvc-5-app-with-facebook-and-google-oauth2-and-openid-sign-on , it doesn't appeal much to me.
If the user is on the website for the first time, the example on the link above redirects the user to the Register page and populate the email field with the value provided by Facebook. Is it all it does?
Because it's quite straight forward to just use the JavaScript SDK for Facebook and achieve the same result with a few lines of JavaScript.
Am I missing something? Why do people use Microsoft.Owin.Security.* libraries?
Thanks

Yes It depends on what you develop. Server side or SPA !
If you want to host your your application with Owin and use EF ,Identity,Claims. You will need Microsoft.Owin.Security.*
But for a simple SPA the javascript SDK will do !

Related

Facebook Login - JavaScript or PHP SDK

I am at the stage where I am thinking of integrating a social login method into my site. Of course my first one will be the facebook login before moving onwards.
Basically my question is : Which language is best for this type of OAuth connection, and which is going to let me do everything I want?
This will encompass all OAuth connections in general eventually, but specifically Facebook for now.
From what I have read of the documentation, the JavaScript SDK allows you to login, and connect to the open graph API - which in turn will allow me to post / upload etc etc. This is also available in PHP.
From experience which is the more durable route to go?
PHP or JAVASCRIPT
The best and recommend way to authorize users is the JavaScript SDK (FB.login). No redirect needed (better usability), very easy to handle, no PHP needed (the new PHP SDK needs PHP 5.4+). Use PHP only for stuff that involves usage of the App Secret or Extended Access Tokens. And for cron jobs, obviously. You can even just forget about the PHP SDK and use your own CURL calls.
Btw, security is no problem, you should just activate "appsecret_proof" in the App Settings.
More information about appsecret_proof:
https://developers.facebook.com/docs/graph-api/securing-requests
http://www.devils-heaven.com/facebook-php-sdk-4-0-tutorial/
One more reason (and one of the most important ones) is the possibility to refresh Access Tokens (=User Sessions) easily without page refresh by using FB.getLoginStatus.
And another reason is that you need to upgrade to new PHP SDK versions on your own. The JavaScript SDK does not need any upgrades, in the lase few years you only had to change one or two parameters in some cases, the SDK gets downloaded from the Facebook servers.
Also, if you add Social Plugins, you need the JavaScript SDK anyway.
TL;DR PHP/both
I'd really recommend PHP. You'll want to store the login in database. If you do it via JS, you'll need to make an Ajax call to the server, which is not really that secure.
Having said that, they are targeted for different uses. JS is for frontend more, while PHP is for backend (db storage, checks, actual site login, etc). Using JS will let you generate the buttons on the fly, while using PHP you'll need to do some more coding.
Somehting else, the php library will get updated from time to time and you'll need to keep up after testing. JS also, but it's easier, since the code usually works.
If you only want one, use PHP. You can control what the code does and JS will not break your site since it's written by you. However, I'd recommend using both since you will probably want more than just simple login
Edit:
As facebook states, use PHP SDK: Usually this means you're developing with PHP for a Facebook Canvas app, building your own website, or adding server-side functionality to an app that already uses the Facebook SDK for JavaScript.
https://developers.facebook.com/docs/reference/php/4.0.0
The best route would be to use both, together. Some users might have javascript disabled or you might do something within your javascript code that will not work on some browsers. So as a fallback method you can use php api.
Going with only php would be solid and will work regardless of what the users client is, but you can make the user experience better with javascript.
Still, in most cases you'll end up having to use both.
I have just spent the afternoon playing with the JavaScript SDK for facebook and I have to admit I think this is going to be the best option for what I need.
If anyone else is reading this, it may not be perfect for you - but with the way my application has been built I think it is a perfect fit. Here is why :
My standard login system uses JavaScript to grab my form data, then validate, which then passes the validated data via AJAX to a PHP validation script. Which in turn returns a JSON response to the original AJAX call. If my call comes back with "ok" : true then we are good to go basically.
The way the facebook JavaScript SDK works is almost a perfect little jigsaw puzzle to bolt onto the system I am using. All I require is a little bit of profile data, to then keep a record of this user on my system. THIS is provided by facebook, then validated by myself.
However, other social network logins may not be as nice and simple to use as the facebook API, so I could end up changing my mind on the overall system. For now just using facebook, I think the JavaScript SDK is absolutely spot on, as it just gets the information for you to run through your own validation on site. As I said this is a perfect fit for my system however it may not be for yours.

Dojo Framework Application with Windows Authentication

I'm trying to develop a web application using the JS DOJO Framework libraries, I don't really have a problem there, the thing is that it is required that the web application uses windows authentication for the users to log in, and some parts or sections (dojo controls and menus) of the developed application should be available in function of the user role.
I would like to know what is the best strategy to authenticate the user?, and what is the best way in the JS side to get and validate the user roles and info of the current user to change the UI?.
I will vbe be using IIS 7.5
On the pure JS side of thing this should not be possible as granting the browser that kind of information is a security threat.
If you estrictly need a windows authentication, your best bet would be something like a plugin for the browser(IE) or flash(not sure about this one).
basiclally your plugin would request the user credentials from the client and pass that on to JS and submit it to your server, after that just keep the credentials in server sesion.

Google API OAuth2 access with mobile web application?

I'm writing a mobile application using JavaScript and HTML and I'll pack it using PhoneGap, so at the end it will be a native one.
One feature of this App will be the "Import from Google Docs" one. I'll set a Google account up for the App and put some documents in it so they will be available from the application itself. This seemed pretty straightforward, until I hit a wall with OAuth2.
What I cannot figure out is how to provide my application with a way to authenticate itself using a pre-authenticated token (I think this is the use of the "secret key" in the OAuth workflow). The problem seems to be that on the Google API guides I read, when speaking of JavaScript integration they always refer to a web application which - as part of the OAuth flow - will eventually ask THE USER to authenticate with HER Google account (and not my application's one) and never use the "secret key" (we will leave the problem of embedding a secret key into an application for later).
What am I missing here? Does anyone have done something similar and care to explain it a bit?
I recently presented OAuth at BlackBerry Jam Americas. You can view the recording of this presentation here which I think may help answer some questions about the differences between OAuth and OAuth2, and how to implement them in a PhoneGap (or WebWorks) application:
http://hosting.desire2learncapture.com/RIM/1/watch/63.aspx?q=social
Also, my colleague Chad recently published some sample code that you can use in your own app development. We have published sample BlackBerry WebWorks applications here that demonstrate how to integrate OAuth with Twitter, FaceBook and Foursquare:
https://github.com/blackberry/BB10-WebWorks-Samples
Good luck!

How to integrate facebook account with asp.net web site?

Hi I have integrated Facebook with asp.net web site through open id But now it is not working . I think Facebook change process of authentication.
So there is any way to integrate Facebook account with asp.net web site . Please suggest me usable link or samples.
I highly recommend the Facebook C# sdk which provides support for the full breadth of the API and is frequently updated. It also has quite a good bit of documentation (which I won't re-print here, since it would be specific to the library and if the link moved or the library went away, wouldn't have any value)
If all you want to integrate is auth, I would still recommend using the library if for no other reason an it handles the signing part for you, and gives you room to do more in the future.
Facebook doesn't use OpenID, they use OAuth 2.
Oldish, but I think still accurate for Asp.Net
http://osnapz.wordpress.com/2010/04/23/using-asp-net-with-facebooks-graph-api-and-oauth-2-0-authentication/
Here's another for MVC3
http://www.codeproject.com/KB/aspnet/net_mvc_facebook_oauth.aspx
Try this Gigya they provide free services through you can put social authentication to your website. But in free service their little backlink comes but for premium users there is no backlink.

Facebook JS SDK does not need app secret to authenticate : How secure is it?

When I use Facebook's JS SDK to authenticate my app (using FB.init method) all I need is my App ID. It does not require my app secret and/or app key.
However when I used PHP SDK, it required my app secret (atleast the example I used to learn used the app ID and app secret both).
Is it secure and recommended to use the JS SDK for authentication ? How really does the authentication flow happen with the JS SDK ?
Thanks,
Vineet
I'm looking into how secure the authentication is also - I think things have changed since you asked this q, so perhaps this information was not correct when you asked.
The new version of the JS SDK uses OAuth 2.0. This is well documented - check out the OAuth 2.0 site for details.
Regarding the issue of whether the SDK needs the app secret - I'm having a little bit of confusion relating to this. On the app server side, the libraries indicate that the JS SDK signs the cookies using the app secret (see the function get_user_from_cookie in the facebook-python sdk) - however, it's completely unclear to me how the JS SDK can know the app secret. I'm guessing that it can obtain it dynamically from FB when it talks to FB directly in the authentication process, but I'm not sure.
(Edit: I think that the JS SDK gets the cookie signed with the app secret directly from FB - the JS SDK never knows the app secret).
Not fully answering your q, but perhaps shedding a little more light on how this works.
Another issue to be wary of is not to use the FB user object you get from the client for anything on the server side. This is because it would be really easy for someone make a script which instead of calling fb.api '/me' would send a "fake" JSON user object with another users ID to your app. If you're doing any kind of server side processing of the user then you really need to do some kind of server side authentication as well I think.
It's NOT safe, this is why you have the "Verify Fields" and "Not Verifying the Signature" paragraphs in the Advanced Registration document:
When you request facebook data, we
verify the form fields before
packaging them up in the
signed_request. This lets you assume
that all the data is genuine and saves
you from having to verify things. The
one problem that could arise, is a
smart attacker could change the form
fields and submit them to you, thereby
giving you unverified data.
Read that document for more information, I've also wrote a tutorial (an introduction about the plugin) and showed how to handle the fields attribute coming from client-side.

Categories