Basic Login: Authentication, and Authorisation
...is the first door, it is the act logging in.
- The user enters an identifier like a Username or email, along with an authenticator like a password.
- The application creates a session for them, with some sort of expiry.
...checks to see if the current session is allowed to perform a given action, or access certain data.
The session is checked against some rules like:
- the user is logged in,
- the user has admin privileges,
- the user last authenticated less than 10 minutes ago.
And if that is all good the access/usage is permitted.
But... If it doesn't you have a choice: Reject, or Obtain Extra Authority.
Rejection is simple, stop the user, they are not allowed.
Obtaining extra authority is a little harder, maybe the user logged in twenty minutes ago. Technically they have the privileges needed, you just want to be sure they are still sitting at the computer. So instead the application asks them to log in again, before attempting to authorise them and let them continue on.
Multiple Sources of Authentication
Often it does not make sense to have a single method for authenticating a user:
- Password recovery by sending an email/sms to a known contact point
- Extra security by requiring additional passwords/key/biometric
- Integration with a cross-client identification provider
Each of these can be represented by a kind of authenticator. The procedure would be:
- Attempt to identify if the user is already authenticated. If they are, obtain the relevant details and jump to step 4.
- Direct the user to an appropriate authenticator, eg: request a specific authenticator, or provide a list of options
- The user attempts to authenticate by providing credentials somehow. eg: Perhaps they are redirected to an external site where they can authenticate, and that external site responds forward with an authenticator token.
- Once an authentication has been successful, the kind of authentication, the time, an tokens, etc... are noted down. This will feed forward to the authorisation logic which determines what can be seen and done.
There are a few sticking points here:
- An authenticator may not actually require whoever is using the client to have supplied credentials.
- Several authenticators may contradict each other on what the identity of whoever is using the client really is.
Sometimes an authenticator might acknowledge a user without requiring credentials. This may be okay when permitting access to some relatively benign information like: add to wish list. Conversely providing access to see that wish list could be considered harmful, afterall not everyone should just be able to see a persons wishes. In such a case the authorisation logic should reason that the account holder might not actually be the current user, and challenge them to prove their identity by requiring credentials to be entered.
When the user accesses the application there is a chance that they have multiple accounts with your site each tied to a different authenticator. In these cases the best strategy is to ask the user to login and present credentials, without pointing out which identity services/authenticators were in actual conflict. This provides two benefits:
- The user picks the account the wish to engage with,
- and no other user can infer who else uses the application, or how many accounts they have.
In general it a good idea to not auto-login a user unless they have agreed to that behaviour.