My collegues and I want to build a chat application (ReactJS <-> NodeJS), and we have been looking for the best framework to do so. FeathersJS seems undoubtedly the most stable and feature-rich socket.io wrapper.
However, as we want to allow our application to scale up, we have decided to split this chat feature in a different node process than our main node backend.
The chat functionalities still requires authentication and authorization however, and we would like to avoid duplicating authentication for the two services. Hence what we have come with as a solution is to query the main node backend with the session cookie to authenticate the user before letting them use the chat service.
Does FeathersJS establishes long-lasting socket connections or would it establish a socket connection for every message sent/received? In the first case we could proceed with our architecture, whereas on the second we'd have to review due to the high load this would produce on the main backend.
Thanks!
There are several ways of splitting up services each with their own advantages and drawbacks. One generally important thing for Feathers is that there are no sessions, just JSON web tokens. JWTs are stateless and can be read by any server that shares the same secret so there does not have to be a central session store. The two main options I can think of are:
Have a main application that handles authorization and managing all connected clients but instead of having services that talk to the database they connect to separate simple individual API servers in the internal network. This is the easier setup and the advantage is that the internal API servers can be super simple and don't need authentication at all (since the main application is allowed to do everything and will make queries according to the authenticated users restrictions). The disadvantage is that the main application is still the bottleneck (but with a decreased load since it basically acts as a proxy to internal APIs).
Every client connects to every API server they need using a JWT. The JWT is created by a separate authentication (or user) API. This is the more scalable solution since the only bottleneck is retrieving the most up-to-date user information from a common users service (which might not even always be necessary). The disadvantage is that it is more complex to manage on the client side and authentication (at least for JWT) will have to be configured on every server. Due to the statelessness of JWT however, there does not need to be any shared sessions.
Related
I have currently developed a backend app that has some important functionalities. I want to consume my backend endpoints from my frontend but I want to be sure that only my fronted calls the backend endpoint and no other. Currently anyone that access my web-app can take advantage of the functionalities (I do not require any user registration or authentication).
How can I be safe that my backend is not being called form other possible malicious attackers that may try to steal the functionalities of my backend?
I have read some other posts regarding solutions how to secure a backend app that do not require user authentication but none has a precise and secure way for that. Some say enabling CORS but during my experience I can say that CORS can be manipulated easily with the help of a simple browser plugin. (not speaking about mobile apps that do not consider it at all)
I would really appreciate if I would have some opinions in case of a web-frontend-app, mobile app and other backend systems that would try to call my API and how can I stop them.
Typical front-end authentication would be best (OpenID, ...).
If you want something different, you could check on your backend whether a specific header with a specific token is sent in the query. If it is not then you send back a 401 HTTP code.
This requires that your customers somehow get that token (through some registration process, probably) and then keep it long-term (it can be stored in LocalStorage but can be lost when cleaning up the browser)
OWASP Authentication is a good source of information.
I'm new to whole authentication/authorization part in web development. Specifically JWT. So I came across a medium post explaining the fundamentals of JWT. There was a diagram which showed how the web server and authentication server had no direct communication, AFTER a JWT token had been issued by the authentication server.
So, my 3 questions are:
What's the difference between the authentication server and the web server?
Is the authentication server, the database server?
And, since you are going to take user data(e.g password/username) from the
client(browser/user), to which server do you write the code to? authentication or web?
Because NodeJS/Express allows you to write the app server code right?
1 - An auth server is usually part of a microservice architecture, if you do not have to scale you can have a simple authentification middleware in your web server.
2 - The auth server is a server usually part of a microservice architecture which role is to authentificate requests and act as a gateway to the rest of the microservices.
3 - Depends if you want to scale or not. If you want to separate auth and the rest of the apis, there are multiple ways to scale.
Hope it helps =)
What's the difference between the authentication server and the web server?
These are two separate servers. Two different programs, potentially running on two (or more) different machines. With different purposes and responsibilities.
Is the authentication server, the database server?
No. For all you know the auth server may not use db at all. For example it can store all the data directly in files, or even in memory. Although, in practice there will be some db behind it. Auth server is just a server with a special purpose: user authentication (as the name suggests).
And, since you are going to take user data(e.g password/username) from the client(browser/user), to which server do you write the code to? authentication or web? Because NodeJS/Express allows you to write the app server code right?
Write code? Both? Depends on whether you implement the auth server by yourself or not. I'm not sure I get that question.
The point is that user credentials should be send to the auth server and the auth server is responsible for validation, secure storage and token issuing. So that other servers (in particular the one you call "web") don't have to worry about it.
Our application is a Single Page App built with Angular and ASP.NET Core.
We have to integrate another web app which we will integrate in an iframe in our app. This app has to send data back to our application after the user finished his work.
I need to make sure, i can relate the data coming from this application to an authenticated user starting the operation in our app in a secure way.
Those were the options i thought in realizing the interface:
Generate a unique token in our application which knows about the related user and gets passed to the other application. The other application transmits this token along with it's other data back to our application and we can check this token on our backend to find out if it's a legitimate request and also relate it to a user.
Store cookies after authenticating the user in our app, so the other app could just post the data to our endpoint and the cookies make sure, the call takes place in the authenticated user's context. Also we would probably have to allow CORS from this site to make this work.
Use a non-http-based middleware (message broker) to connect the systems in a way, which keeps data transfer out of the browser.
Transmit the Bearer token from our application to the other application, so the other application can make an authenticated call to our application backend.
CORS would have to be activated as well for the other app's origin.
However i'm a bit concerned about the security implications this could have.
Which way would you suggest? Or would you suggest a completely other way of achieving the goal?
Thank you very much for any advise!
Number 2 and 4 will both have potential security issues. Passing authentication contexts between different applications should be avoided, instead each application should be authenticated independently.
Number 3 would add complexity to your architecture while bringing little to no benefit for your use case - message brokers are not trivial to configure and operate. I would also question why two apps need to be integrated in the client via and iFrame but then are somehow able to share a message broker.
Number 1 for me is the cleanest option from your ideas. Consider however, you will need to pass this token somehow in the client which may open security holes. Think about the negative implications of what could happen, should a nefarious 3rd party get access to this token.
In your place I would question why an iFrame. Would it be possible for your app to provide the UI and instead communicate with this other application over an API?
As with many applications, my service's authentication logic lives in the application code. Now however, I need to expand my authentication to incorporate 3rd party identity providers for single sign on.
I want to retain the old authentication behavior (database lookup) but also want to add support for 3rd party identity providers.
With this increase in complexity, does it make sense to separate the authentication logic to its own service? In this model the application server will redirect unauthenticated users to the authentication server. After authentication is successful, the authentication server will redirect back to the application server.
Is this approach sound?
If you have available servers and infrastructure budget, let your web application perform the authentication, using a community maintained library.
Generally its no recommended to build one by yourself.
Store your users in a database table.
Authentication using other sites problems:
Your visitor may not want to have an account with 3rd party site.
It results in giving too much information to the 3rd party site (who share much of it with other sites which use their authentication mechanism).
It is generally a good idea to separate your authentication logic and have a different service perform that task. This is also true for other 'cross cutting' concerns such as authorization and SSL offloading. It gives you a simpler development environment and in general an app that is easier to reason about (for example, you don't have to worry about authentication while in development mode and you can develop the services independently which goes a long way in terms of productivity and velocity).
In order to compose the authentication service with your application, it is better to have a third component that orchestrates and routes the calls accordingly (as opposed to having autentication related code in your application).
I am starting to plan a web-app and Backbone.js will be a perfect fit for the client side. I have been planning on using node for the backend but this is open for the time being.
I need a way to secure the front-end app's connection to a database. I have had discussions with others on Quora but I think the thought process was too abstracted from the core problem.
I would prefer to be accessing the data by RESTful end-points, but I need to ensure only my app can talk to the API. I will have full control over both the front-end and back-end of the application. There is a possibility of other apps being built around the database (in a year or two), however they will be developed by me (i.e. not a public API) and these will probably use separate OAuth end-points.
Some notes on the app (may or may not be useful):
The app is planned to be offered in a SaaS model where companies subscribe and are allowed multiple users.
The data for each company needs to be secure and only accessible to members of that company.
All traffic (front-end and app to API) will be sent through SSL.
Any advice on the best way to do this will be greatly appreciated.
We have the exact same setup as you - SaaS model, multiple apps (mobile, web, etc) and when I followed your link, Miguel has the exact solution we use.
Token that is time stamped and sent to the client on auth. We store that hash token in a User Model and then every subsequent request we validate that token.
You can extend Backbone.Model with a BaseModel that appends the token to every server request by overriding Backbone.Sync
See here about how they extended a baseview and you can apply the same thing to a basemodel.