I have two Spring Boot REST applications. One of the applications calls other with Spring RestTemplate. Lets call these applications server and client app.
Server app is sending XSRF-TOKEN token as cookie, this is done for the UI part. However there's no way (None that I know of) for the server to distinguish between the request coming from browser and a request coming from the client app. So I can not selectively send the CSRF token from the server to browser only.
Is there a built in mechanism in Spring which allows RestTemplate to detect CSRF cookie/header and replay the request?
If not how can I do the same manually? Should I wait for the CSRF exception to occur and then read the cookie fro the response and replay it?
If it were to be done once then it would be OK, however to wait for the exception for every RestTemplate call doesn't seem right.
I may try to store the token once and set in from the next time, however how would it deal with the multiple server app scenario (Which I have to implement next). As CSRF token of one server app would be invalid for the other, so I won't be able to store a single token, but I would have to store a map of tokens which would have an entry for every new server app URL.
This all seems too complicated, I would rather have Spring handle it.
Any clues are appreciated.
Thanks
For now I have implemented a REST service without protection in the server app which can be called to get CSRF cookies. I had to allow session to be created always so that CSRF cookie doesn't change in one session and so that I could avoid the error Could not verify the provided CSRF token because your session was not found.
Client app calls CSRF rest service to get the cookies and then sends it with the next service call.
It seems a much to call the CSRF token service for each REST call via RestTemplate however it saves me from implementing complicated logic of storing the session. CSRF token service just delivers the cookies so it's network call doesn't take much time compared to the actual service call.
I was also thinking of using a persistent storage (SQL Database or Redis) to store the CSRF token for the server app and then let the client app directly read it from the persistent storage.
However I couldn't figure out how to associate the Session + Server app + CSRF token together to identify token needed by client. As client doesn't have the session initially, so it can't uniquely find CSRF token for it's token from the database. This method is complicated further by the fact that RestTemplate doesn't store the session for the next call.
Related
for example: if i have Asp.net web Api Application and this application get a Token from Client To send Notification for this Client with this Token and every Client have a different Token.
How can I save this Token for each individual Client To every Client use his Special Token more Times from different Computer or From different Browser??
Schould I use cookies or Session or is there something else??
It is worth noting that the Token is sent from the client and used by the server
The WebAPi is a Stateless Project that mean you do not need to manage the state for every client!
For example, if you use JWT token, once the token created by API, client must send the token for every request.
BUT
If you need to save a token for more use!
Four options come to mind :
1-use your primary db(ex:SQL Server) to save the token!and retrieve every time you need!(Not a good idea)
2-save your token to Redis!
3-create a static class with Singleton lifetime, then with dictionary you can save the token for every client to memory!
4-Use In-memory Database link
We are trying to implement an application where UI is in angular and backend is in Spring boot.
We need to implement openId and oauth2 in our application.
Backend api's needs to be more secure.
I am just confusing which oauth flow to be used either authorization grant flow and password grant flow.
Can any one suggest me which one need to use in this scenario and why?
Storing tokens in the front end is not recommended. It also distributes token handling logic across FE and BE because BE will have to validate tokens on each request anyway.
Therefore to avoid handling and refreshing tokens in the frontend and to simplify the overall architecture, you can implement authorization code flow in Spring Boot. This will also reduce the risk of XSS exposure in the FE.
You could implement a dedicated endpoint that initiates the flow and receives code from identity server. It then exchanges this code for id token and stores it. Then it creates an HttpOnly, strict SameOrigin session cookie for the front end. From that point onwards all calls to the API inside your Spring Boot will automatically carry this cookie without any additional code on the FE.
To eliminate token storage on the BE, you could even put token inside the cookie. However, the token may be quite large and may need to be broken into chunks. This would not affect FE in any way.
You will need to check token expiry on each API call inside the BE and refresh token in the backend as well. This will keep user session seamless. If token can not be refreshed due to revocation or refresh token expiry, the API would have to return 401 and the FE would need to initiate re-login.
I have an Angular4 SPA + Parse Server. Currently, I'm implementing authentication with Parse.User.logIn(...) and Parse.User.logOut(...) directly on web page. The thing that I am worried about is storing session token received from logIn() method in Angular app. Whatever is stored on client side (even local storage or session storage) is prone to XSS attacks.
The only workaround I see is to implement custom login and logout methods in cloud code. On successful login cloud code could store session token in a cookie (secure, httpOnly) and would on every subsequent request parse token from cookie and set it in request as header "X-Parse-Session-Token", and then Parse Server logic would take over.
I guess this would work but I'm wondering how are you guys solving this problem. Where are you storing the token on web page?
I have stumbled upon a problem with Spring Security and Angular.
On my BE (Spring Boot application), there are defined OAuth2 providers, such as Google, GitHub and Facebook.
My BE works fine with this providers, since I can authenticate on the desired providers.
The problem is when I try to send the principal object to the FE (Angular 6 application).
I get undefined value when i try to subscribe the value from the rest endpoint.
I assume this is due to the Spring Servlet creating a new thread for the login request.
I am doing my login request from the Angular app.
I did watch dozens of tutorials and rad so many articles, but I just can't find the answer. If it's possible for you to share some code on how it is done, or give me a link, since for sure I am making a silly mistake and can't seem to find the answer here.
Thanks for understanding, have a good day.
:)
I am assuming that you are using the Authorization Code flow from your BE to authenticate the user that interacts with your FE Angular application (you in your example). Otherwise, you would be trying to authenticate the BE Client with the Client flow and you wouldn't need to return the "principal object" to the FE application. If my assumptions are correct... read on.
The Authorization Code flow goes as follows:
1) The user somehow selects an Authentication provider (ex: Google) and that selection is returned to some endpoint in the BE as a non-authenticated request..
2) The BE Client receives this request, preferably intercepted by a filter and, since the request is not authenticatedd, redirects the browser to the selected auth provider's authorization endpoint.
3) The user then proceed to authenticate against that provider which, upon succesfull authentication, returns a response that redirects the browser to a BE Client endpoint. That redirect holds a parameter that provides a code that the BE Client will use to get an idToken representing the user. At this point, it is important to note that the browser has not been returned any response for this redirect.
4) The BE Client then proceeds to send a regular HTTP request to the provider's token endpoint along with the received authorization code. The provider then returns the idToken an HTTP response directly to the BE Client. All this is happening while the browser is still waiting for the response to the last redirect.
5) The BE Client then process the idToken (verification, validation, user details, session etc) and only then, will finally send the response to the browser patiently waiting since the code redirect. That response may provide a header or a cookie with a sessionId or token (your choice) that the FE application will be able to read or use for the given purpose.
This flow is relatively easy to implement and requires minimal SS configuration. You must keep the BE Client auth endpoint with permitAll() otherwise, you would not be able to trigger this flow. Also, make sure that, once the FE app. has received the header/cookie, all subsequent calls shall be processed as "authenticated calls". Finally, make sure to document yourself on the perils of stateless sessions as well as cookie security and always use HTTPS.
Jake.
I'm trying to implement Spring OAuth. I'm new to it and I'm trying to understand how it works.
My Questions:
OAuth generates token after authentication and this token must be used for every request the user makes. We need to append this access_token to each REST API call for accessing the resources. Did I sound correct?
Do we need to store this token on client side (using cookies)? or is there anyway so that we do not need to store this token at client side and can be handled on the server side?
If we have to store the token on client side what's the best way to do it? I have gone through this link
If endpoint on your server is protected by oauth, then yes, you have to pass token with each request - probably in "Authorization: Bearer {token}" header. In spring its solved by using different restTemplate - OAuth2RestTemplate which automatically fetch it and add to request.
You just store just JSESSIONID in a cookie. Then spring read session from store ( disc where tomcat is installed / redis if you use spring session project/ etc )
Access token should be relatively short living. There should also be revoke endpoint available so you can invalidate specific token when there are reasons to believe it was compromised.
3.a) there is another issue with storing some data on client side. Its about storing clientId, clientSecret on mobile native apps. Android apps code can be reverse engineered quite easily, so anyone can then try to use your oauth app to get token. In those situations its recomennded to use different grant type "password" - check https://aaronparecki.com/2012/07/29/2/oauth2-simplified#other-app-types