Well, it is a little more of a security risk than the session id: once a session stops or is expired, nothing can be done under that id anymore - any replay attempts beyond that time would fail.
Another difference is that the decryption operation on the authentication cookie would incur a somewhat undesirable performance hit on on every request. The final difference that I can think of is the most important one IMO: if you automatically log-in a user via a saved authentication cookie, you're essentially acting on the end-user's behalf, implicitly trusting who they are: your software has no way of knowing if the end user has actually _proven_ their identity, for example, if a user gets up and walks away and someone else uses their computer (or via replay attacks). Also see the Shiro's Subject API, particularly the isAuthenticated() and isRemembered() JavaDoc for a better explanation of why the distinction is important for most applications: http://incubator.apache.org/shiro/static/current/apidocs/org/apache/shiro/subject/Subject.html It is also important to note that Shiro can perform authorization checks (roles/permissions, etc) for a remembered (unauthenticated user) - its just that the isAuthenticated() check is even more strict and should typically be used to protect things like user account information, financial data, etc. Cheers, Les On Mon, Aug 23, 2010 at 6:30 PM, Mike K <[email protected]> wrote: > > All good points. But isn't keeping this data on the client in an encrypted > form just as safe as a session id? Given strong encryption, the only > vulnerability I can see would be a replay attack, to which session is also > vulnerable. > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/Permission-checking-on-client-side-tp5450587p5455037.html > Sent from the Shiro User mailing list archive at Nabble.com. >
