Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

how to handle logout #20

Open
mic0331 opened this issue Jul 1, 2013 · 4 comments
Open

how to handle logout #20

mic0331 opened this issue Jul 1, 2013 · 4 comments

Comments

@mic0331
Copy link

mic0331 commented Jul 1, 2013

Hi @alexanderbeletsky

thanks for your tweet about the authentication snippet for backbone ;-)
I finally spent some time integrating your code into a project of mine and find this backbone.basicauth that might be very useful when using your hmac security scheme.

https://github.com/fiznool/backbone.basicauth

So far your security solution is working well but i'm questioning now about the logout phase. How to permanently log out a user? As far as i know basic auth is not offering any solution to permanently log out a user. What do you think ?

My webapp is using cookies authentication so at logout i can destroy the cookie and the user cannot access secure pages anymore BUT on the other hand, my REST api is hosted on a different server and therefore is not using the cookies auth but just the basic auth system. At logout from my app i cannot access the webapp anymore but the REST endpoints are still accessible...
Any idea on how to make a proper basic auth logout via jquery or backbone ?

Also something to consider in your boilerplate, i'm using passeport.js with local strategy. This plugging hugely simplify the code and offer something proven for a big app.

@alexbeletsky
Copy link
Owner

hey @mic0331

  1. Thanks for pointing to backbone.basicauth - looks like nice plug. Anyway, the solution by @Vijar a bit more, since it's very simple and actually delegating setting auth headers to jQuery (which is for me bit more robust).
  2. As for invalidating tokens: this is really good point you mentioned. I'm currently implemented HMAC based auth for one of my projects and had the same question. Unfortunatelly, what I can see - it's not possible to invalidate HMAC based token (except the fact it's expired). So, I set expire period for rather small value (24 hours).

Anyway, I'm going to ask few smart guys about and update ticket with info :)

@alexbeletsky
Copy link
Owner

After a bit while, I don't think it's possible. Some good input from Vinay.

A few points:
Basic auth in itself provides no logout, since it just passes whatever its given unencrypted
By design, cookies are almost always remembered by the browser until told to forget
Basic auth is remembered if you type into the address bar ( http://user:[email protected] ) or in a browser popup
But not remembered if you pass Basic Auth manually per request - in this case, when the app wants to forget the token, it just throws it away in the javascript, and thus logged out. However, one thing to note with HMAC authentication is if the communication is intercepted and the token compromised, then the token can be used with the server until it expires. By wrapping communication in SSL, we >mitigate risk of token compromise and end user impersonation.

So, in short: it all comes down to the client side code using the token in a way that isn't automatically remembered > by the browser, and throwing away the token when not needed anymore.

One could also go more advanced here: Assuming there's a separate web app and API - the web app could generate a 15 minute token and the javascript could request a new token every 12 - 13 minutes from the web app with a CSRF protected request.

Vinay

@Vijar
Copy link
Contributor

Vijar commented Jul 2, 2013

Yeah if we do a refresh interval shorter than the expire interval, it should work. The frontend code will need to "forget" (delete from localStorage) the token on logout though.

The only concern it looks like is to hope that some one isn't able to grab the token before it expires. Even if they do, they only have max 15mins to use it. We do have to make sure the refreshing of the token is robust enough not to be easily faked. Otherwise, assuming someone has a token, they could just keep refreshing the token on the user's behalf.

@alexbeletsky
Copy link
Owner

The only concern it looks like is to hope that some one isn't able to grab the token before it expires. Even if they do, they only have max 15mins to use it. We do have to make sure the refreshing of the token is robust enough not to be easily faked.

I agree, keeping the token-ttl short, using SSL and implementing invisible client refresh of token is the way how to handle the stuff.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants