AuthTkt relies on the browsers goodwill, what you are looking for is a way for you to expire an authentication session server side:
https://usingnamespace.gitlab.io/pyramid_authsanity/faq.html#why-tickets Explains why you want to have the ability to expire sessions ahead of time. I don’t agree with storing authentication session information in the session because they have two very different concerns/lifetimes. Sessions should store temporary data that may be useful across a user switching from one page to another, but should not store long-term information. Whereas authentication is usually longer lived, and has different concerns regarding the ability to expire/verify it is still valid. Storing the authentication in the session can be handy, and if you are already storing that somewhere server side and you can attribute a session not just to a session id but also to a user to force a logout, then it would work just fine. AuthTkt can’t be merged with the CookieSessionFactory stuff because AuthTkt as a policy is meant to work together with Apache’s AuthTkt module or any other code using AuthTkt. It is a lot like using JWT. It allows a single server (the authentication server) to sign and provide the user with a “token” they can use to authenticate against a different server/endpoint with that “token” and that other server doesn’t have to do any checking other than verifying the signature that yes the user is authenticated. However this has the flaw, as you saw that you can’t expire the authentication server side, you have to trust that the client listened when you asked them to remove the “token” and no longer use it to connect to a server. Besides JWT being an incredibly complex standard that every so often you read about yet another library that implemented it poorly (and thus leading to security issues) it has the same flaws as AuthTkt. pyramid_authsanity is my auth policy that tries to fix some of these issues. It can use the existing session, or another cookie, or even authorization header, and does server side checking that the ticket in the token has not expired or been removed. This allows for example a single user logged in from 3 different locations to easily de-authenticate the two other locations by clicking a button to remove some entries from the database. Using SessionAuthenticationFactory with a server side session implementation is slightly more secure, however the default session implementation which stores sessions in cookies (and thus has no server side state at all) has the same issues as AuthTkt in that expiration of the cookie is something the client has to abide by. Bert > On Jun 20, 2017, at 11:01 , Mike Orr <[email protected]> wrote: > > Originally I used SessionAuthenticationPolicy because the code was > straightforward and what I was doing before. I mentioned the > seemingly-duplicate code between '*CookieSessionFactory' and > AuthTktAuthenticationPolicy and whether it could be merged, because it > was long and complicated (and hard for me to understand, all that > cookie signing and setting stuf). Somebody recommended > AuthTktSessionFactory anyway saying it's not necessarily a great idea > to put your authentication in your session. I'm not sure I fully agree > with that, but I switched to AuthTktSessionFactory anyway. > > Now I'm wondering, how does AuthTktAuthenticationPolicy enforce > logouts? With SessionAuthenticationPolicy it deletes the userid in the > server-side session, and if the server wants to reject somebody with > prejudice or clear all sessions it can delete the session backend > object. But with AuthTktSessionFactory as I understand it, it merely > sends a header to the client expiring the cookie. What if the client > ignores that directive? Would the person still have authenticated > status? Does the server keep a record somewhere of which tokens are > still valid? (Akin to storing the ID in the session.) If not, how does > it know whether to reject the cookie because it previously invalidated > the token? Does this mean SessionAuthenticationFactory is actually > more secure than AuthTktAuthenticationFactory? > > -- > Mike Orr <[email protected]> > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/pylons-discuss/CAH9f%3Duqt%3D_i-eus-VHWeSEO%3DNasWkfTiSr0YgvnjWQZv6_quDA%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/7077D82D-51C1-45B8-B9B8-3BA4E81D24F7%400x58.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME cryptographic signature
