4

I am designing a web application using Spring MVC with REST controllers and Angular JS pages which communicate with these REST controllers.

I've implemented a token based security/ authorization mechanism that is working. (This one is based off the JHipster token based security.)

This token has an expiration time (at this moment it's 30 minutes - the default).

I was wondering what the best practices are to make this webapp as secure as possible while keeping user friendliness as high as possible.

At this moment, if a user (re)loads the page the token in the cookie gets checked if it's still valid. If it is, then the token will be renewed (so a new token is generated which is valid for --time--).

If a user doesn't visit the page for longer than --time-- and he revisits after, he will get logged out because his token isn't valid anymore.

What's the best practice for keeping the user logged in for as long as possible while still keeping everything secure?

Also, if the user would be idle for, let's say 30 minutes (in my case the token validity), and he DOESN'T reload the page and then does an action (which does a REST call under the hood) it won't get authorized (there will be a 401 error which shows the security is working). Would it be a good idea to monitor the validity in the background with javascript and if the token is almost expired, ask for a password and renew the token or even logout the user? Only solution as it is now would be to reload page and login again...

Any insights on what the best practices are will be much appreciated!

  • Hmm I'm not all too familiar I mostly just use StackOverflow but I can see why because this is more of a general topic (not depending on a certain technology)... Can I move this myself? – E. V. d. B. May 15 '15 at 2:08
3

To some extent it may depend on the design of your web app and the level of security your app requires (based on a risk assessment). In short, there is no one answer suitable for all situations. The key to a good user experience is ensuring your security level is in-line with the actual requirements. Too stringent security requirements with too short a timeout will lead to frustration for the user and too little will expose them to excessive risk.

Understanding how your app is used is very important. Nothing frustrates a user more than being forced to re-authenticate multiple times in what they consider a single session. For example, I have some apps which I keep open for a long time, but I might only actively use the app a few times a day. I don't want to re-authenticate after every 30 minutes of idle time, but I'm happy to re-authenticate once a day. Other apps, such as my banking app, I want to ask me for re-authentication if the session has been idle for just a short period.

I think the most important objective is to make the re-authentication process as painless as possible. Forcing someone to re-enter their credentials and then sending them back to the home page is rarely a good solution. What you want is a process which briefly interrupts the users workflow, but once re-authenticated, puts them back into their workflow at the point where it was interrupted by the authentication process.

This can be a little tricky with traditional based applications where much of the workflow state is maintained on the server - especially if you use session timeouts. However, it sounds like your application is using a lot of javascript and so I suspect you maintain local state.

One solution is to have your rest API verify your token/session and if a decision is made that you need to re-authenticate, pass back json data which essentially tells your app to re-authenticate than then re-submit the request. Javascript on your client can then use this information to pop up a modal window to collect authentication data, submit it to your authentication service to get a new token and then re-submit the original request with the new token.

for a more traditional application, the general solution is to use server redirects. When you try to access a REST API and your token has expired, redirect the browser to the login page, but have the login page also accept a 'next' url. Once the user is authenticated, the login service will use the next parameter to redirect the browser back tot he original REST API call. The challenge with this can be ensuring you maintain all necessary state information.

Another addition which is sometimes acceptable is to have your authentication service configured so that if it gets an authentication request which includes a token which is still valid, it does not require the user to re-authenticate. Instead, it just issues a new token. This will allow your application to renew the token without user interaction in the background. Your REST API's can be configured to redirect to the authentication service if the token is going to expire within the next X seconds/minutes. The advantage of doing this is that if someone has a very long session, they are not forced to re-enter their credentials simply because the value you set for token expiration has expired.

Most of the time, the applications I work on do not have high security requirements. For these applications, I tend to use a long expiration value for the tokens and a reasonable session expiration timeout based on idle time. This way, the user is not forced to re-authenticate simply because of an arbitrary expiration time for the authentication token, but they are required to re-authenticate if the session has been idle for a specified amount of time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.