I am implementing Google's OpenID Connect (OAuth 2.0) in Tomcat.
The first step is to
which I did and thought I could store it as an attribute in the Tomcat HttpSession object "session".
But after Google redirects to my redirect URI (on the same Tomcat server), Tomcat has created a new session object for this HTTP Get.
I have looked and cannot find an explanation for this behavior. I had expected that the original session object would be accessible on the redirect GET.
The flow is:
GET login.jsp from my Tomcat; store anti-forgery token in session this page has a button to login via Google
Push the button
GET accounts.google.com which returns a 302 with a location to my redirect.jsp
GET redirect.jsp from my Tomcat; display all attributes in session -- there are none
I was expecting the anti-forgery token to be in the session object.
I am considering storing the anti-forgery token in the filesystem, checking the creation date against the time of the redirect and checking the request.getRemoteAddr of the redirect against the original request as an alternative to using session.
I misread your question. Yes you are looking for a place to keep the XSRF token but naturally tomcat is giving you a new session after authentication as expected. There are two options that I know of.
Google or the OAuth protocol provides you the option of placing the token in a "State" field that it will append as a query parameter when it redirects users back to your site and you can then pull the token out of the redirect URL parameters instead of a session. Here's an answer discussing it -> Google OAuth 2.0 redirect_uri with several parameters
Another option is put the token in a cookie and when the user returns pull the value out of the cookie and compare it to what you have in the database or if you dont want to hit the database you can store it as a JWT and just verify it in memory after pulling it out of the cookie.