We have oauth2-proxy setup with the cookie storage option for state, which successfully redirects the user to the IDP and back when their access token expires and needs refreshing.
If the token needs refreshing, but the call made is a POST with form data, once the refresh token has been acquired, and the user redirected back to the app, the form data is lost.
oauth2-proxy seems to store the original URL requested and its method in the 'state' query param which is passed around to the IDP and back whilst redirecting the user, which is what I guess oauth2-proxy uses to then recreate the original request.
Is it expected that the POST payload is lost if the call was a POST? Is that only stored if you use the Redis option? Or is a refresh timeout of 30 minutes too low and usually it's expected to be much higher to avoid this issue?
Any advice appreciated
Related
I am currently trying to design a new web-application for a rest-api service I have running. In basic I am trying to realize the login/logoff system. For authorization-management the API provides three endpoints:
/login, which takes username and password via a POST request and returns a token embedded in a json answer. This token is not a JWT, but its some arbitrary unique string. It is valid for X hours and everytime it used it is reset to be X hours valid again. The validity is check on the server in each request.
/logout, which makes the token invalid on the server.
/validate, which takes a token as json in POST request and checks if it is valid. If not it returns a 401.
Now I realized a login procedure following https://www.digitalocean.com/community/tutorials/how-to-add-login-authentication-to-react-applications . The application finally should used the react-router to provide the different pages. My problem is not how to integrate the validation of the token on each page change and if a 401 is returned, switch to the login page again.
PS: The server is written in C++ and accesses a custom database.
As Suggested By You That You Want To Integrate Validation, So You Need To Create A Component Over The Current Route Component.
It would serve as the private Route and as soon as you get a 401 Response From Your Server You Would Redirect To The Login Page By Updating the Token as empty depenedending upon the storage you are using i.e. session storage or localstorage.
This way whenever your token expires the next request responds with 401 and you are logged out.
Further I am Linking An Example Gist For Creating Private Routes And Logging Out
https://gist.github.com/EduVencovsky/f8f6c275f42f7352571c92a59309e31d
how to keep the user always logged in, in a react application.
I can't refresh the token using an expired token, can I ?
my idea is to make the token expiration to null and refresh it in every request for security
so if user don't use the app for a while, token will never expires, and in every request the token will be refreshed for the security
it's not secure to do this. because now the token will still valid as long as no new requests from the user. tokens that never expire extend the time-frame for attacks such as cross-site request forgery (CSRF), session hijacking and session fixation. also if you want to change this behavior you will need to change it from backend side not react.js side
I might be misreading your question, but at least just on "how to keep user logged in"
You can do this with localStorage, ofcourse there is security concern.
Basic idea: user logins, the user object returns from database, you only need to store the jwt_encoded information that makes a user "looks like is logged in" in the localStorage. By that I mean, you aren't going to return the user's password & email everytime, and on refresh page, log the user in with those credentials... If you are building a todolist app, just store the todolist tasks & username to the localStorage after the user logs in for the first time. And then if the user refreshes the page, just display the information from the localStorage.
It might be a little bit more tricky because UI is dynamic and you have to change your localStorage to change your UI, but on backend calls that update our user object, we can simply return the new user object and set that as the new user in localStorage.
Best to check this article for code, https://blog.bitsrc.io/build-a-login-auth-app-with-the-mern-stack-part-3-react-components-88190f8db718. The author starts talking it about half way through. I only provided theoretical stuff.
Edit: I really was falling asleep. For the "it might be a little bit tricky part" I was being quite dumb. If you saved the user id in the localstorage, you can just make api calls to retrieve the user information with that id whenever you need it, in short, you only need to store user id in localStorage.
I have a very general question concerning a JWT Session.
Whenever I fetch something from the database I need to sent the token along to autentificate. In case the token is expired, I need to check if the token is still valid. How do I manage this in a simple fashion? So that the user is directed to a login page whenever the token is invalid?
Do I always have to dispatch my intended action (e. g. a GET req. to fetch news articles) and dispatch a SECOND action everytime which deletes the token from SessionStorage if it is not valid and redirects the user to the login screen? This seems like a bad solutions because it somplicates literally every action?
So my basic question is, how do I manage a JWT session in a good way?
JWT token usually comes with the expiration time, store it in local storage and refresh it when needed.
sample code : https://auth0.com/docs/quickstart/spa/vanillajs/05-token-renewal
I'm using JWT for authentication in my Angular.js application, with Express.js on the server side.
Basically, when user logs in, a new token is created (using https://github.com/auth0/node-jsonwebtoken) and send back to the client. If token is valid also on the client side (angular.js part, using https://github.com/auth0/angular-jwt), a new user is created and the token gets stored in a cookie.
So, each request to certain path on the server is protected by a token validation. However, my token has an expiration time. Now let's say for the sake of argument that expiration time is 30 seconds; user can actively use my application for 30 seconds and after that, he gets logged out. That's not exactly user friendly.
So what I did was that with each request to the server, I create a NEW token and send it back in the head of response. When I receive the response in my Angular.js client-side, I read the token and overwrite the token in the cookie. That way, as long as client is active (or rather, makes requests to the server side), the token gets refreshed.
Now I'd like to know the following:
Is such an approach correct? The downside is, that token gets created at each request and send back in each head of response. Cookies get overwritten quite often (performance issues?)
What would be the correct approach?
Is it OK that the token expires if there are no requests to the server? Client might still be using the application, however, if he's only writing on client side something (or reading), the token does not get refreshed.
Thanks for your time and responses!
Yes, that is a valid approach. It is the same approach many take,
including the popular Angular module ng-token-auth. You might
consider saving the tokens to local storage, with a fall back to
cookie storage if the browser doesn't support it (see
http://caniuse.com/#feat=namevalue-storage for coverage).
I would do what you describe.
One solution is to use $interval to basically ping the API. All you need to do is send in a token a get a new one back (i.e., in headers like you are now). Keep track of how many "pings" you've sent. You can reset the number of "pings" upon certain actions like on ui-router's $stateChangeSuccess (i.e., navigating to a new view) or anything you like, including submitting a form or other non-ping requests. When the number of "pings" reaches your threshold, warn the user that their session is expiring, and after a delay, erase the stored token and log them out. Check your ping responses for authentication errors from the API, indicating that the user might need to be logged out and/or redirected.
Perhaps you just gave 30 seconds as an example token lifespan. I would recommend getting closer to the browsing session timeout that you want. As points of reference, consider that the Ruby gem devise_token_auth defaults to 2 weeks and that .NET defaults to 10 hours. Your needs may vary.
The problem is also addressed by using refresh tokens. Your access token has a short life and is verified by signature. The refresh token has a longer life and is used to get new access tokens.
When the refresh token is used to get a new access token, that is a good time to do extra checks: has the refresh token been revoked? Is this user account still valid?
Both tokens can be stored in secure cookies and supplied on every request. Doing this allows your server to transparently use the refresh token when needed and set new access tokens in cookie responses.
This is the approach we've taken for Express-Stormpath and is documented in our Authentication section of the documentation. If you'd like to offload your authentication layer, I'd suggest Stormpath. (Disclaimer: I work there, and wrote that module).
I fetch the API tokens for the current user when he signs in.
This token needs to be persistent throughout the entire session.
I started by updating the default headers after the token was generated, but that update disappears when refreshing the page.
$http.defaults.headers.common.Authorization = "Bearer #{token}"
I tried to store it using $cookieStore.put('API-TOKEN', token), but that didn't work as it was saved with the /user path. Making it only available from the /user scope.
Storing it in a Session fabricator also failed as that where emptied on every page refresh.
My next attempt will be to store it using sessionStorage. Perhaps with the help from http://ngmodules.org/modules/ngStorage .
Which method is the preferred way?
Cheers,
Martin