Is there a way for storing the tgt token in session storage while redirection to client browser?
Is there any config using which we can achieve this?
Related
What I am trying to achieve
Let's say there is a web app that allows users to log in with Google.
The newest google identity services provide jwt tokens on successful Logins.
Instead of local or session storage, I decided I will be storing the jwt in client-side memory, and keep a refresh_token in a httpOnly secure cookie
Example:
After successful login, the web app will hit the backend /authenticate which will decode the jwt token, and it will keep add that to a map(refresh_token → jwt) and it will respond with that refresh_token
The web client will then save that refresh_token in a httpOnly cookie and it will instantiate a socket connection (using that refresh_token in the handshake)
the actual jwt remains in memory, and it is not prone to attacks
When a user refreshes the page, that refresh_token will be used to defer the current jwt token, or fetch a new jwt if expired.
The socket connection will always have a refresh_token in the handshake, which is mapped onto a valid jwt token that will be checked on each socket message
Question:
If an attacker manages to grab that refresh_token, they can request a new jwt token from my server, as if they were users, supposing they know there is an endpoint on my server for that... What is the benefit of storing the jwt in-memory and the refresh_token in a httpOnly cookie?
I understand that this makes the attack process more difficult than just storing the jwt in a httpOnly cookie, but at the end of the day the refresh_token is also useful, it's just useless to the outer world.
Are there another ways of doing logout without redirecting my Frontend to oidc/logout page (it works fine,but isn't it insecure sending idToken and my IDP url to frontend),i have separate front and back end. Like in Keycloak which invalidates session by sending refreshToken? If not,what is a right way of doing logout in my application?
We are sending the ID_Token in POST request directly to the IS Server thus it should not have any security concerns. Using ID_Token as id_token_hint while doing a logout is coming from OIDC specification[1]. This will prevent attackers from logging out users from their accounts because only the real RP can present the valid ID Token.
If you want an alternate way to logout you can make use of session management API[2]. But it is recommended to use the logout endpoint.
[1]https://openid.net/specs/openid-connect-session-1_0.html#RPLogout
[2]https://is.docs.wso2.com/en/5.9.0/develop/session-mgt-rest-api/
I am maintaining this application which is set up with:
an AngularJS front end
a Spring back end (with Spring Security, configured as per the Keycloak documentation) running on Tomcat
Keycloak as single sign-on solution using OpenID Connect.
The Implicit Flow is implemented like this:
The user navigates to the web app in their browser
The AngularJS web app checks if a (non-expired) JWT token is present in the Session Storage
If not, it redirects to Keycloak to request a token
Keycloak authenticates the user and redirects back to the webapp with the token
The web app stores the token in the Session Storage
Any request the web app makes to the back end API, it inserts the header Authorization: Bearer <token>
So far, so good. However, I noticed that logging out does not work as expected:
The user clicks the logout button in the web app
The web app deletes the token from the Session Storage
The web app redirects to the Keycloak logout endpoint
The user accesses the back end API directly and succeeds!
The reason is that a JSESSIONID cookie is stored and this also authorizes the user to access the API.
My questions:
Why is a JSESSIONID cookie being created? Is it default behaviour of Spring Security? Or did I misconfigure something?
How should I fix the logout issue? Make sure a JSESSIONID cookie is never created? Or implement a logout endpoint in the backend that deletes the session cookie?
NB: I am aware of
the risks of storing credentials in Session Storage;
the Implicit Flow being deprecated.
I have a dotnet core 2.2 MVC web application which uses a web api to perform some database queries. I have implemented JWT token based authetication for web api. Tokens are generated at the api and the web application has received the access token, expiry and refresh token. I need to store this token details at my client , so that I can either use it to access web api(before expiry) or generate new token using the refresh token if the token expires.
Any help on this would be appreciated.
You have various options (secure http-only cookie, localstorage, session storage, etc.).
In the most simple scenario, you can store it in a cookie so that it is sent along with each request :
The cookie should always have the HttpOnly flag to prevent XSS attacks in the browser.
The cookie should also use the Secure flag in production, to ensure that the cookie is only sent over HTTPS.
Protect your forms against CSRF attacks (by using ASP.NET Core’s AntiForgery features, for example).
Previous answers don't provide clear explanation about the reasons of using those solutions.
Typical systems look like on the picture below and there are two common Client Application architectures used in WEB:
Singe Page Application running in browser
Server side MVC application
In case of SPA the tokens are stored in browser (session storage or local storage) and are cleared automatically by either browser or the app itself when expire. FYI, obtaining refresh token is not possible in SPA because of security reasons.
In case of MVC app (your case) the things get more complicated. You have two options: either store it in http-only cookie or some external session store. Aspnet core supports both cases but each has caveats. A good article here. In short, if your are concerned about cookie size then use Distributed Session Storage which adds more complexity to the system architecture. Otherwise cookies is the easiest solution and is enabled by default in aspnet core, you just need to set options.StoreTokens = true and options.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme.
There are multiple ways to store the tokens. Usually applications doesn't store access token anywhere, but they do store refresh token in a permanent storage.
Let's take a look at what you need to store at web and api end.
First, user will request to login in web application with credentials, web app will pass this request to the api project - which interacts with DB.
Now, api will generate access tokens and refresh token and the save refresh token to that DB. Web api then need to store access token and refresh token in temporary storage like cookie or session.
When access token is expired; you need to make a call for a new tokens, which will update the previous refresh token in the DB.
TL;DR
Refresh token - in DB
Access token and refresh token - web temporary storage
Make the call from ui to web application server(controller) controller which in turn makes call to get the token from api.
get the token from api response and store it in cookie.
you controller should look something like this
var option = new CookieOptions
{
Expires = DateTime.Now.AddMinutes(response.ExpiresIn)
};
if (!string.IsNullOrEmpty(domain))
{
option.Domain = domain;
}
Response.Cookies.Append({cookiename}, response.AccessToken, option);
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