Web Application Security Architecture

Question

I have a REST API server with Java Spring that connects to a PostgreSQL database and a Spring Java web server that serves content from the REST API to the client using JavaScript (now browsers, but in the future also mobile applications).

I read a number of articles on how to protect the REST API, but so far I have not been able to make a final decision. I don’t want to have basic authorization, because it doesn’t make sense, since I will need to store credentials in JavaScript, which can be easily accessed and read by someone by accessing the web page and the developer console. I would not want to show any credentials to the end user, so I cannot store them on the client side.

I read a lot about JWT and almost decided to implement it, but I heard that it has some flaws, and since then it has not been so sure if it were the option that I would like to choose. I know that there is oAuth 1.0 or oAuth 2.0, but I don’t know if I want to have something so complicated. I would also like to store hashed user credentials in my own database so that it does not depend on any other credential providers such as social media or Google.

Now I am creating another layer on my web server as a proxy, hoping that it will allow me to authenticate the user at this proxy level with Spring Security and have some kind of cookie or cookies or something to authenticate, but I I’m not so sure that he will follow this path and increase the response time, add complexity and require me to write controller methods for these endpoints. Now my architecture has the following meanings:

Client (browser) → Web server → REST API server → db

I also refused all external connections and allowed access only to localhost for the REST API at the tomcat level, so I would have to implement the security level only on the web server, which would provide free transit of information between the web server and the REST API, since it is in anyway unavailable.

The web server and REST API are on the same server as the Tomcat instances.

I'm also not sure if this architecture will allow me to authenticate mobile application clients through a web server.

I would be very grateful for any advice that you would have for me in this matter. I'm not so experienced in security, so I lost a bit of what I have to do. Does this architecture make any sense or should I just request the REST API directly from any type of client, be it a web page or a mobile application from different IP addresses and only a secure Rest API? And if I want to protect some subpages of my web page or parts of a mobile application, should it be a completely different level?

Thank you for your help.

Answer 1

You have already passed OAuth, JWT tokens, etc. If you do not want to use them, you can create your own token based authentication system (say ' TokenHandler ').

How does this TokenHandler work?

TokenHandler will look like a gateway server, and each of your REST API requests will be routed through this server application. So you will see your confusion about calling a mobile and web application using authToken in header . The main responsibility of this application is to accept the token and check it on the basis of the database, where all the token data is stored. This database will have information about the timestamp when the last token was used for verification in order to decide on the verification rule.

How will the token be generated? The token can be any random 64-digit alphanumeric string and will be generated and updated in the database during each input activity. Login webservice returns this token in the response body.

What can be the rules for verification? It may depend on your business logic. I preferred to keep the active session window for 15 minutes. If you get access to the web service, you will get an active window for another 15 minutes. If you have not received access to any service for 15 consecutive minutes, and then from the 16th minute, you need to log in again in order to gain access to further calls. This part is subject to change as required.

How will the client side deal with this? The client side will store this token and transmit this token with each call to the request. The token handler will check and redirect the request to the application server. Thus, your single token handler can be used to authenticate servers to multiple application servers. This can be achieved using the application endpoint identifier.

I want to discuss if you have any questions or suggestions.

Answer 2

Use the API gateway architecture template for your use case - http://microservices.io/patterns/apigateway.html .

The API gateway (the web server in your question) can act as a single entry point for all desktop / mobile clients. You can use session cookies or jwts to authenticate clients on the gateway.

As for authentication between the gateway and microservices and between microservices, I would suggest mutual ssl - https://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication . If you use spring boot this may help - http://www.opencodez.com/java/implement-2-way-authentication-using-ssl.htm

The problem with the IP whitelist is that it is not very suitable for the cloud architecture, since the IP addresses can change each time the server reboots. Even if you use dedicated IP addresses, you have to be careful to ensure SSL / TLS connectivity, otherwise attackers can sniff your traffic easily.