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.
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 want to design a SPA which will have Frontend (React) and Backend-Rest API (Node.js, Express, Mongo DB). I am planning to have Single Sign-On in my application where users would be authenticating using MS-Azure AD, where a call would go to Azure AD from Frontend and in return I will get a token for that User which will be stored locally. After that, I want to call my rest API, for multiple GET, POST, PUT operations in the context of current user logged in on UI. Planning to deploy both frontend and backend on different servers so here I have two questions about securing my REST API.
CORS Implementation
User-Authentication on BE
Given the above requirements is it enough to have just CORS implemented or Do I need to again authenticate the User on BE?
Can somebody provide some best practice or experiences? Is there a lack in my “architecture”?
While CORS is definitely a consideration, it isn't Authentication (AuthN) or Authorization (AuthZ) which you need.
Depending on the number of users your application will have, how the back end will scale you might want to look at OAuth2.0 or stick with simpler session based auth but you will need something.
CORS on your back end will limit if a browser running an app on a domain other than yours to call your web services (it wont stop API requests from other tools).
AuthN - Your not logged in - go get logged in and come back to
me.
AuthZ - Controls what your users can and cant do. You might want to
enforce this at the resource level but you absolutely need to within
your business logic.
Further reading https://auth0.com/docs/authorization/concepts/authz-and-authn
Philippe from Pramgmatic web security has a free online course to get you started: https://pragmaticwebsecurity.com/courses/introduction-oauth-oidc.html Its very well paced and should give you some foundational knowledge. (It might let you write off OAuth for this use case but give it a go)
CORS will not perform any user authentication. You need CORS only when your client code is served from another domain than the backend you are talking too. If it is the same server to host static client files and backends REST endpoint, you don't need CORS. If you are unsure, then don't consider CORS at all and see if it works.
But you need authentication to know which user is which.
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?
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.
I'm planning on making an android application that sends user data to a web server and stores it temporarily in a database. Now I've never worked with databases or web servers before, but after reading a bunch of tutorials and a few days of hacking away I managed to get a node.js server with mongodb up and running on the openshift platform.
Right now anyone can interact with the database just by sending a GET request or even just pulling up the url in a browser. Is there a way to prevent that by happening or would I have to maybe encrypt the data myself before storing it?
You describe a typical web application using REST APIs. To secure it, do two things:
Deploy your REST APIs (or the entire site) using HTTPS instead of HTTP. This provides end to end encryption so your sensitive data cannot be viewed while in transit
Add an authentication and authorization mechanism, so that only authenticated endpoints can access your REST APIs.