Authentication internals

The main idea behind our authentication system is to handle everything upfront, not using any redirects and not leaving anything to become effective upon the next http request. This simplifies debugging, provides a better user experience, and avoids any obfuscation of the real complexity of the system.

Architecture:

• Anything affecting security or usability, such as timeouts, is as much as possible handled in the framework rather than relying on sane behavior of underlying systems.
• Session related inputs (login attempts, cookies, nonces, etc) are handled in the central login checking function, thus they are allowed on any page. This allows dynamically deciding what page a user will go to after authentication, without needing any redirects.
• In keeping things are RESTful as possible, all data with a bigger scope than a request is stored in the database, the built in PHP session system is not used.
• OWASP guidelines are followed wherever possible, with the notable exception of not being "secure by default" in cases where that would contradict the unintrusive nature of the framework.

Rate Limiting and Timeouts

• Usernames with too many (limit configurable) recent failed login attempts can not be used for login. The same error is shown regardless of if the username corresponds to a real account.
• IPs which have recently submitted at least one failed login attempt for too many separate usernames and/or at least one failed session attachment attempt for too many separate session IDs (combined limit configurable) will be temporarily blocked and not be able to have a session or login at all.
• Configurable session timeouts, both idle and absolute, configurable separately for whether "remember me" was checked on login. Anonymous sessions have "remember" enabled.
• Enabling "remember me" on login does not change anything about the nature of the session, only which timeout values are used.
• Configurable "session reissue time" where the ID of a session changes periodically over the lifetime of the session.
• Any session level data in the database should be attached by cascading foreign key to the sessions table so they will tolerate changes in the ID of existing sessions.

Anonymous Sessions

• Any request where a valid user login is not active shall have an anonymous session instead, barring database errors, or the requestor's IP being blocked in the session system.
• When a user logs in, their existing anonymous session if any is maintained and converted into a non-anonymous session, and the session ID changes.

Other notbale features

• Accounts can be manually disabled wherein login is not allowed and the user is told why, but only if they would otherwise have successfully logged in.
• Login from multiple locations is allowed; applications should use DataTable to provide a way for users to manage all sessions for their account.
• Logout feature is provided for logged in users; terminates the session and they immediately get a new anonymous session.
• Login not allowed for accounts until email address has been verified via nonce.