I'm developing a new web site that will be a single paged app with some dialog/modal windows. I want to use backbone for frontend. This will call backend using ajax/websockets
and render the resulting json using templates.
As a backend I'll use nodejs express app, that will return the json needed for client, it'll be some kind of api. This will not use server side views.
Client will use facebook, twitter, etc. for authentication and maybe custom registration form.
Client static resources, such as css, js, and html files will be handled by nginx (CDN later).
Questions that I have now:
How can I determine that a given user has the right to do some action in api(i.e. delete a building, create new building)? This is authorization question, I thought of giving user a role when they login and based on it determine their rights. Will this work?
Similar to the above question, will this role based security be enough to secure the api? Or I need to add something like tokens or request signing?
Is this architecture acceptable or I'm over engineering and complicating it?
Passport is an option for the authentication piece of the puzzle. I'm the developer, so feel free to ask me any questions if you use it.
I thought of giving user a role when they login and based on it determine their rights. Will this work?
Yes this will work. You can check for a certain role on the user after it's been fetched from the server. You can then display different UI elements depending on this role.
Will this role based security be enough to secure the api? Or I need to add something like tokens or request signing?
It wont be enough. Anyone could hop into the console and set something like user.admin = true. In your API you'll need to validate a user token from the request, making sure that the related user has the appropriate permissions.
Is this architecture acceptable or I'm over engineering and complicating it?
At the least you should have an API validation layer. That would make a decent enough start, and wouldn't be over-engineering.
For the authentication part of your question i would use everyauth which is an authentication middleware for connect/express. It supports almost every oauth-social-network-thingie.
For role management you could give node-roles a try. I didn't use it myself but it should help you out, because it checks the role on the server side. Of course that is only useful if your API is implemented in node.js. If that's not the case, you have to "proxy" the API calls over your node.js app.
I hope I could help you! :)
Related
I have two applications settled up. One is a E-commerce (TrayCommerce) that has itself an Api (Oauth), from which I can get order, clients, products information, etc. The other one is a chatbot (Take Blip).
My goal is to make the chatbot retrieve information from the e-commerce's API so I can send it to final user.
I thought in two ways of doing it:
Hosting a javascript code inside the bot, so I can call the API whenever user requests data. However, I don't know how to implement the authentication flow on this approach and how I would, in the future, set up a system to receive notifications from the API to send information each time it is updated, since I can only host one js file per action.
Creating a NodeJS API, which will be hosted on a third party, and that will return the information I want, in a formatted way, to the chatbot. I don't know if this is over-engineering, because I already have an API from the e-commerce.
I am sorry if it is a dumb question, I am new to web development, but any information would be valuable for me to choose a workflow for this integration.
To be able to answer, the right question to ask yourself is the sensitiveness of the data inside the e-commerce; and the power granted to the generated token in the auth implementation.
Typically, a chatbot (assuming a web one) is a piece of Javascript held in the client (browser). This piece of code is perfectly readable by the user, thus you have to assume the generated token could be used to perform a request that you didn't intended him to perform.
So as a simple answer :
If — and only if — the implemented OAuth mecanism lets you limit the scope of authorization to the customer, then you can make the customer authenticate directly with TrayCommerce and the appropriate scopes (and use his token to perform on the API). Said differently, if typically TrayCommerce lets you register your Chatbot as a "client" (this is an OAuth keyword), and generate Auth journeys with appropriate 3-parties flows, granting only something like "orders:view:self" for customers, it's OK.
If the TrayCommerce API is more like a "management API"; with auth implemented in a way that you (yourself, not the customer) have to authenticate on it; then this auth mecanism is not suitable for your use-case. You then have to make an API like you described, that would act like a proxy to TrayCommerce. With considerations (see below).
In the case of you making a "Proxy API" to TrayCommerce; you are basically hiding the TrayCommerce Authentication on your server-side, and shifting that responsibility from TrayCommerce to yourself. In such a case, you have to implement your own authentication (+ authorization) mecanism on this API, to be able not to expose TrayCommerce data to the world.
I'm working on a React-Redux web-app which integrates with AWS Cognito for user authentication/data storage and with the Shopify API so users can buy items through our site.
With both SDKs (Cognito, Shopify), I've run into an issue: Their core functionality attaches data behind the scenes to localStorage, requiring both SDKs to be run client-side.
But running this code entirely client-side means that the API tokens which both APIs require are completely insecure, such that someone could just grab them from my bundle and then authenticate/fill a cart/see inventory/whatever from anywhere (right?).
I wrote issues on both repos to point this out. Here's the more recent one, on Shopify. I've looked at similar questions on SO, but nothing I found addresses these custom SDKs/ingrained localStorage usage directly, and I'm starting to wonder if I'm missing/misunderstanding something about client-side security, so I figured I should just ask people who know more about this.
What I'm interested in is whether, abstractly, there's a good way to secure a client-side SDK like this. Some thoughts:
Originally, I tried to proxy all requests through the server, but then the localStorage functionality didn't work, and I had to fake it out post-request and add a whole bunch of code that the SDK is designed to take care of. This proved prohibitively difficult/messy, especially with Cognito.
I'm also considering creating a server-side endpoint that simply returns the credentials and blocks requests from outside the domain. In that case, the creds wouldn't be in the bundle, but wouldn't they be eventually scannable by someone on the site once that request for credentials has been made?
Is the idea that these secret keys don't actually need to be secure, because adding to a Shopify cart or registering a user with an application don't need to be secure actions? I'm just worried that I obviously don't know the full scope of actions that a user could take with these credentials, and it feels like an obvious best practice to keep them secret.
Thanks!
Can't you just put the keys and such in a .env file? This way nobody can see what keys you've got stored in there. You can then access your keys through process.env.YOUR_VAR
For Cognito you could store stuff like user pool id, app client id, identity pool id in a .env file.
NPM package for dotenv can be found here: NPM dotenv
Furthermore, what supersecret stuff are you currently storing that you're worried about? By "API tokens", do you mean the OpenId token which you get after authenticating to Cognito?
I can respond to the Cognito portion for this. Your AWS Secret Key and Access Key are not stored in the client. For your React.js app, you only need the Cognito User Pool Id and the App Client Id in your app. Those are the only keys that are exposed to the user.
I cover this in detail in a comprehensive tutorial here - http://serverless-stack.com/chapters/login-with-aws-cognito.html
Circumstances
I develope a WebApp with AngularJS.
I've an restful API on server-side with GET and POST commands.
I want to use the API within my module (means: in JavaScript) to display and edit my data.
I want to protect the API with some kind of authentication (basic auth with an API key for example)
I don't want to protect the API when a user uses the app itself
Actual question
Okay, I guess the last point is a bit unclear.
I want that a user can use the app with his browser without any authentication
But when a third-party app want to access the API it have to use authentication
Since JavaScript is executed on client-side of course I can't write a master key into js or something similar..
Is there any kind of pattern or solution to solve this problem?
More specifications
referring to #EliranMalka and #shaunhusain
On the server-side I do use Tornado with it's builtin template engine. I do use the template engine actually just to write the index page and insert CSS, JS dynamically.
The code for authentication would just something like:
def is_authenticated(request):
if 'api_key' in request.arguments:
return sql('SELECT id FROM keys WHERE key=%S' % request.arguments['api_key']).count == 1
My AngularJS module is doing something similar to:
$http.get('/api/foo?api_key=1234')
.then(function (result) {
$scope.data = result.data
});
As you can see I'm writing my API key into js at the moment. But I wan't to avoid this.
Also, what do you mean exactly by third-party?
not a third-party request would be: Using the App on http:/ /app.example.com with a browser
A third-party request would be from an Android app for example. Something that comes from outside or remote.
A JS request from the browser on the actual page would be not from remote (again: since it's JS it is actually from remote - but I hope it gets more clear now)
Oh and before I forget...
I'm aware of that my plan is a bit weird - but it's just a learning(-web-development)-by-doing project.
Also the API key is not absolutely to avoid abusion, it is rather to log 3rd-party usage.
PS I hope my question was clear for you
Hmm, well I'll try to address the questions but here's a few things.
Question isn't really appropriate in it's current format for stackoverflow.com (should be programming questions, I tried X and Y happened) perhaps closer to a StackExchange question but is still fairly open ended.
Include more information about specifics of the languages (and/or frameworks) your using server side and any code you have that is relevant (authentication code?).
Putting the key into the client code and transmitting it from the client means anyone with a web proxy (check out Charles or Wireshark) can grab the key so just to reiterate you're right there that's not the way to go.
Check out how other organizations allow you to get access to their APIs (for example Google, LinkedIn, Facebook, Twitter) to get a feel for how it works. In all of these cases you are signed into the service to be able to make an API key, in some cases you have to specify which domain the requests with that API key will come from. If you use the same precautions and check the API key sent with a request against a database of registered API users and verify the domain in the request then I'd say you're in pretty good shape.
I'm new with angularjs...
I read the docs, and completed the tutorial; i also tried something else by myself, and things start to make sense to me.
Now i wonder how to make a safe authentication system.
The easy part: no code, i will describe operations my code execute:
I've a classic form: username, and password text input.
The user fills the form, and press ENTER.
An ajax request starts, and the response is a JSON telling me
something like "ok i know you" or "i don't know who you are".
What i need now is to mantain the logged status of the visitor (or not logged) between the different views of my application.
I read on the internet that, to achieve this objective, someone sets a variable ($scope.isLogged = true), someone else uses cookies; but javascript variables, and cookies can be easily edited using firebug, or similiar development tools.
... and finally the question:
So, have you some suggestion to achieve a safe authentication system in an angularjs app?
You cannot authorize anything in angularjs, because the user has full controll of the execution environment (namely, the browser). Each check, case, if - anything you can think of - can be tampered with. There are javascript libraries that use asymmetric keys to perform local encryption to store local data somewhat safely, but they are not what you are looking for, really.
You can, and you should, authorize things on the server - the standard way you would do it in an ordinary application - using session; no special code is necessary, ajax calls use ordinary session cookies. Application does not need to know whether it's authenticated or not. It only needs to check what server thinks.
From the perspective of your angularjs application, being "logged in" or "logged out" is merely a gui hint for the user.
Probably you found a solution, but currently I made up an authenticaiton scheme I'm implementing in my Angular App.
On .run the app is registered with an ActiveSession set to false.
It then checks if the browser has a cookie with a token and a userId.
If YES, check token+userId on server and updates the token on both server and local (token it's a server generated key unique for each user)
If NO shows login form, check credentials and again if they are valid does a server request t get a new token and saves is locally.
The token is used to make a persistent login (remember me for 3 weeks) or when user refreshes the browser page.
Thank you
I asked this question three months ago.
I would like to share what has become my favourite approach when I've to deal with user authentication in a web app built over AngularJS.
Of course fdreger's answer is still a great answer!
You cannot authorize anything in angularjs, because the user has full
controll of the execution environment (namely, the browser).
From the perspective of your angularjs application, being "logged in"
or "logged out" is merely a gui hint for the user.
So, briefly my approach consists in:
1) Bind to each route additional information about the route itself.
$routeProvider.when('/login', {
templateUrl: 'partials/login.html', controller: 'loginCtrl', isFree: true
});
2) Use a service to mantain the data about each user, and their authentication status.
services.factory('User', [function() {
return {
isLogged: false,
username: ''
};
}]);
3) Everytime the user try to access a new route, check if they have the grant to access.
$root.$on('$routeChangeStart', function(event, currRoute, prevRoute){
// prevRoute.isFree tell me if this route is available for all the users, or only for registered user.
// User.isLogged tell me if the user is logged
})
I also wrote about this approach (more in detail) on my blog, users authentication with angularjs.
First of all: Client-side data can always be manipulated or tampered with.
As long as valid session IDs aren't easily guessable and measures like associating session tokens with the client's IP there is no big deal about it.
You could, in theory, also encrypt the cookie, as long as you do so on the server side.
For details on how to encrypt your cookies, see the docs of your server-side (e.g http://expressjs.com/api.html#res.cookie for Express.js)
You need to learn about the server side / database end of it.
User logins need to be stored somewhere - 99.9% of the time this is in a server side database.
Ideally for a really secure system you want a backend (server side) membership system that stores the session in a database table that is related to the member table that holds the encrypted password, but also provides a RESTful interface where you can build your api calls to.
One Script that I've used successfully a lot has been Amember https://www.amember.com/. It's a really cost effective way to go although there are a lot of other script out there, I've had a lot of success with this one.. It's also PHP so you can build your build out an API for your angular http calls really easily.
All of these javascript frameworks are great but the effect is that now too many are focusing too much on the front end of things - learn the database / backend as well! :-)
I'm currently writing a twitter client using javascript, then found out many people reminded javascript developers about not revealing "consumer secret". But they never said why.
So why is it so important to hide my consumer_secret? If anyone want to show my "via My_App" on his app, making the name My_App more famous, why should I worried about anything? After all, you can't get any useful information out of my consumer_secret, the user information is protected by both https and token_secret.
A malicious developer could create a spam application using your consumer secret. If enough spam accounts are using the spam app Twitter may disable the entire consumer key at which point your entire application will no longer work with Twitter.
You can think of the consumer secret as a password -- it identifies your client to the server. Anyone with your consumer secret can pretend to be your app.
So you need to keep it secure, and you don't want to "hide" it; you want to encrypt it. This should happen on the server, never in the javascript app that you send to the user.
You can find a lot of helpful information at Google's support page.