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.
Related
What is the difference between using Google OAuth and signing in users at the frontend of the application, and signing in users at the backend side of the application?
Example: Signing in users and getting the ID and a auth object in React or letting Node/Express handle everything, the prosess, redirecting and store it in a database.
Is there any advantages for one or the other methods, which are most common and are there any "rules"?
What is the difference between using Google OAuth and signing in users
at the frontend of the application, and signing in users at the
backend side of the application?
So to clarify to everyone reading this, signing in users at the backend side of the application is another way of saying OAuth for servers and signing in users at the frontend of the application is OAuth for JavaScript browser applications such as React.
Signing in users via OAuth for servers and browsers results in a 'token' that a server/browser can use to make requests on behalf of the user. We are asking the user to provide us access to their information via an outside service provider such as an email address, identification of some sort and it will be inside that token as well as some possible permissions that allow us to take actions on behalf of that user.
Is there any advantages for one or the other methods, which are most
common and are there any "rules"?
Server-side OAuth is usually used when we have an app that needs to access user data when they are not logged in. So if you are attempting to build an application that needs to access the users email every ten minutes and possibly delete emails on the users' behalf, you would want to be able to access their email account every 10 minutes regardless of whether they are logged into our application. So for this use case we want to make use of Oauth for server.
Otherwise, if we are not trying to do anything on behalf of the user except sign them into our app, then we can just go with OAuth for browser.
Those two things are very different. Without knowing the specifics of what you're trying to accomplish, you should know as a general rule that front-end-only authentication and authorization leaves you extremely vulnerable.
If someone knows JavaScript well, or is using editing plugins, or any of a million different things, they can bypass much front-end authorization. Or they could just watch to see what calls your app makes to the back end, then simulate those calls from something like Postman, bypassing your web front end entirely.
If you're not securing your backend, you're not secure. Typically systems do both.
It is just a different ways of registering users to our website.
Signing in users at the frontend using OAuth can be very handy as it enables our users to not go through our boring forms in our website. Using OAuth is just one click away from registering users in our website. Beneficial to both the clients and developer.We are provided with the general information about clients by the provider(google,facebook) just clicking on one button.
Signing in users at the backend side is the traditional way of registering our clients. Here we force our client to fill the forms in our website(which may be painfull if it is a long form) and all the filled data is stored in our database.
So they are both different ways to register clients to our websites. Both are used very often. It depends on usecase and needs. Oauth can be used if you want to attract more clients by registering them just by one click.
I'm working on a PhoneGap project using Ionic. It's basically a chat app, so I need the user to be able to register, login and send messages using a backend API on my server. Naturally this needs to be secure, so I'm wondering what the best way to securely communicate with an API endpoint is, when using a AngularJS and PhoneGap.
Ideally, it should not require a server cert, as currently I don't have the funds to purchase one. In previous projects, I used a method where each account was assigned an ID, and a hash consisting of a secret + their ID, which had to be included with each request to ensure that the user couldn't forge requests from another ID, however I don't know how secure this method is.
Any tips, suggestions or read material would be really appreciated. I understand this question sounds subjective, so if possible please answer based on facts, security disclosures and any documentation on methods.
I know the solution to all your needs and it is called Firebase.
How your requirements will be met by firebase:
1. You are using Ionic to build your hybrid app(you are cool!) and that means AngularJS.. Firebase has the perfect library called AngularFire, that uses AngularJS to interact with the firebase servers.
You are building a chat app, awesome! Firebase has real time syncing between your app and database. That is a lot of work saved for you by Firebase (Claps).
You need to register users, Firebase has super easy user register management(both OAuth and manual registration)
Security! It is super important and Firebase has you covered even here. Implementing user level security is super simple using some simple json format security rules. I will quote this from the site "The safety and security of your data is our top priority. Firebase requires 2048-bit SSL encryption for all data transfer and allows you to restrict reading and writing via granular access controls and custom authentication.
All data is replicated and backed up to multiple secure locations."
It is free(upto some level. Do some research about it, I am not sure).
Your basic id + hash security measure is not bad at the same time not perfect or dependable. Firebase has you covered here through simple login and read/write rules and as well as some closed sourced security.
I'm building a PHP web application, something like "Auction", I want to let the user to sign in using their facebook accounts.
I started using javascript SDK, I've built the first page in which I asked the user to login using facebook, after the authentication is made, the page refreshes and according to some cookies I stored after the authentication, the page layout and elements change.
I want to save the login status in such a way the server knows if the user is authenticated or not, I know I can same the appropriate cookies to give the server these information, so do I need the PHP SDK in the future? Is it better if the retrieving of user info done in PHP at server side? what advantages I get from using the PHP SDK rather than using the javascript?
I'm sill in the very beginning of the development process, and I'm not sure if I'm going the right way to use the javascript SDK alone! any help concerning this dilemma will be appreciated.
thanks
I'm writing an app using Phonegap.
I'd like to give some perks to the user for posting about the app on their wall (or something of the sort) if they wish to do so.
There's a neat Cordova plugin which covers Facebook's functionality pretty thoroughly and more importantly it appears that it does so as natively as it can manage.
If a plugin like that is not available however, what is a high-level overview for having a user:
authorize with FB
post something canned on FB
ascertain that they have in fact posted what was given to them
I believe there's a way to do these things using Facebook's JavaScript SDK, but I've never seen an app ask me for my username and password (that wasn't the actual Facebook app) and I don't imagine Facebook would be happy with that, so what's the best way to go about that?
Additionally, if I want for a user to log in using Facebook in my app, (think Tinder) what is the data that I should be saving? Facebook login token and device ID? What are the best practices when it comes to using facebook and phone data to identify and store user account information server-side?
Facebook Login for Android -
The Facebook SDK for Android provides methods to implement Facebook Login for your app. The SDK provides Facebook Login support for the these common scenarios:
Your app uses only Facebook Login to authorize people using your app.
Your app provides two login options: Facebook Login and your own
login mechanism.
Your app uses your own login initially and Facebook Login is an
option to switch on certain social features.
For more - login-with-facebook.
Manually Build a Login Flow -
The easiest and quickest way to implement Facebook Login is with our official SDKs for JavaScript, iOS, and Android and we recommend you follow our separate guides for these platforms.
However, if you need to implement browser-based login for an app without using our SDKs, such as in a webview for a native desktop app (for example Windows 8), or a login flow using entirely server-side code, you can build a Login flow for yourself by using browser redirects.
This guide will take you through each step of the login flow and show you how to implement each one without using our SDKs:
Checking login status
Logging people in
Confirming identity
Storing access tokens and login status
Logging people out
Make direct HTTP requests to Graph API endpoints to retrieve
and post data.
For more check - manually-build-a-login-flow.
Pros:
No plugin dependency and no uncertainties when new versions of
Cordova or the Facebook SDK are released.
Works for all platforms, including platforms for which a version of
the plugin doesn’t exist.
Works for both browser-based apps and Cordova apps.
Cons:
Not full-fledged, less out-of-the box features.
Integration not as tight. For example, no native dialogs, etc.
The logic is integrated together and is available on github as OpenFB.
Sample Example -
Login using Facebook:
openFB.login(scope, successHandler, errorHandler);
Get the user’s list of friends:
openFB.api({path: '/me/friends', success: successHandler, error: errorHandler});
Post on the user’s feed:
openFB.api(
{
method: 'POST',
path: '/me/feed',
params: {
message: 'Testing the Facebook Graph API'
},
success: successHandler,
error: errorHandler
});
Either you have to use Facebook connect plugin to post something from cordova app, or the other way that I use to post something about my app review is using the URL way. Facebook has feed dialog / share url system to post in facebook. Simply calling it with native browser and correct parameters does the job, facebook takes care about the authorization and posting , I don't need to handle that.
https://www.facebook.com/dialog/share?
app_id=145634995501895
&display=popup
&href=https%3A%2F%2Fdevelopers.facebook.com%2Fdocs%2F
&redirect_uri=https://developers.facebook.com/tools/explorer
Found here Don't know will it work in inAppBrowser or not, I just call the native browser.
And AFAIK to post from within the app, it has to be the plugin.
OpenFB is even better than the Apache Cordova Plugin. The plugin isn't well maintained. Sometimes it takes months to update to the latest version of Facebook OpenGraph. OpenFB is constantly updated.
You would just use the JavaScript SDK to do this. See https://developers.facebook.com/docs/facebook-login/login-flow-for-web/v2.0
You have an option to use standard components or make your own buttons. You can also let users auto-authenticate after granting permissions initially or always press the button etc. The FB docs are easy to follow though.
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.