Reputation: 770
I am designing the backend of large application which is divided into microservices. I am using Spring Cloud with its tools: Eureka, Zuul and etc. I have implemented OAuth2 authorization server which supports four grant types. It is working without problems.
Then I was asked to serve html files and in such manner that if not authorized, backend must redirect to login page and strongly recommended that I don't use sessions. I thought that without session spring cant really know what's going with, in the end it must have token to decide to build security context.
I started researching about this issue. I found that examples from Spring Security and Angular JS tutorial show that routings and redirections are accomplished inside angular with the help of ui-route. I skimmed several projects in github and they also were using angular for redirections.
Is it possible to redirect using backend in totally stateless session?(This sounds so dumb, but it couldn't be expressed otherwise. I want to give this answer to my coworkers that are stating that is possible). If possible, are there any examples?
Upvotes: 4
Views: 1351
Reputation: 3145
If you are using OAuth2 for internal security, I suggest to use oauth in order to access controll all your services, treating the presense of a token as something like a session.
Consider you generated some access token in one of 4 grant types. You now can access any ResourceServerConfigurerAdapter
secured spring cloud resource, by passing that token in a Authorization: Bearer <token>
HTTP header, or as get parameter like /service/endpoint?access_token=<token>
.
If your token is related to a user (you can authorize clients without users!), you can access its details by getting OAuth2Authentication
from securityContext.
Furthermore, if your access tokens are JWTs, which is supported per default in spring cloud security, your neither have to provide a real token store on authorization server, nor you have to request the user endpoints on auth server from resource server to fetch user info, as it is shipped inside the JWT.
With this, everything about your "session" (and its state) is stored inside the access token, which you can easily pass around, and scaled without replication mess.
I don't thing you get your security more stateless than this ;)
Upvotes: 0