The three levels of authentication

Aside from the chance to get rich and famous, I wrote Designing Mobile Interfaces basically because I think it's a good thing to share knowledge. Much of the writing on this blog is the same way. But often, I forget when something is useful. Yesterday evening, someone copied me on a long email which was: a thing I wrote a couple months ago about some of the key IA principles behind authentication, authorization and so on. The deal is, I wrote it in like half an hour, off the top of my head. Because it's the tenth time I've had to write such a thing, since so many people do it wrong. So, this is a perfect example of something to sanitize, and share. Instead of overly-editing to be chatty, it's pretty requirements-like. Ask if something is confusing or too briefly defined. Or, tell me if you just straight-up disagree. These assume a website. Application authentication can be similar, but is not addressed here. There are three levels of authentication, not two:

1. Anonymous
2. Identified (or Recognized)
3. Authenticated

And it is important that you never call the middle one "cookied," "zipped-in," "cart remembered" or anything either very specific, or based on the technology solution. The middle tier is as important as the other two. Each level of authentication has multiple characteristics:

• Presentation Authorization – A certain set of information (general, specific, or personalized) is displayed on the screen or can be printed. There is no direct method to change this level (such as hidden content with a link).
• Transactional Authorization – A certain set of transactions (general, access-controlling, or liability-inducing)
• Management Authorization – Most users can only manage their profile. Some can manage multiple profiles. Some (e.g. customer care) can perform certain functions over multiple profiles. These are further subdivided into having degrees of Presentation or Transactional Authorization for each of the other profiles they can view and/or manage. Even if not in scope at the moment, you must consider it during the design of the system

Anonymous:

A customer visiting your site, who has never visited before or is visiting on a computer without a cookie (such as a friend's or at the library) will not be identified, and receives only general content. There are other schemes aside from cookies, but they are most common, so assume that for planning purposes. Links to various types of personal information or authenticated-customer services are displayed, and if selected will either:

• Allow use, but will not save information. The kitchen planner today works like this, and intercepts for authentication on save or exit.
• Inform the user they are only for customers, providing significant amounts of introductory content and a link to authenticate or register.
• Intercept with an authentication dialogue, demanding credentials (or enticing to register) or allowing the request to be abandoned.

Depending on the type of information or capabilities of the service.

Identified:

The customer has visited the site before while authenticated, and the client computer can accept cookies. On this visit, Lowe's.com recognizes the cookie, matches it to a user profile, and presents complete customer information (minus the usual masking of values that should not be sent over the internet, such as passwords and credit card numbers). The customer can perform simple transactions that do not induce access control changes or liability, and are not too destructive (without recovery). They may not change access-controlling or liability-inducing information. They may have limits on changes to personal information. For example, items will be able to be added to or removed from the Home Profile, but deleting the whole Home may not be allowed. The following is a sample set of transactional features that are not available to the Identified session:

• Purchases
• Change password, or recovery information
• Change or add mailing address
• Change or add contact information
• Change or add payment methods

The method of restricting transactional access to payment information and authentication credentials may be most seamless to the UX if view access is also not provided, but this is not inherent in the rules.

Authenticated:

The customer has provided a username and password combination which is successfully recognized by the system. There are two methods to provide this:

• The customer entered the site as an anonymous user, and either deliberately signs on, or attempts to access an unavailable transaction (such as checking out with purchases). They enter both a username and passcode.
• The customer has entered the site and been automatically identified. When attempting to access an unavailable transaction (such as checking out) they are intercepted, and provide their passcode only. The username is pre-populated (or not displayed, but a proxy such as the customer nickname and avatar are displayed) during the request for additional credentials.

This may have happened due to an earlier transaction, and the session may continue to be active. Authentication does not have to be directly related to the service requiring this level of access control. The customer then has complete authorization to view and transact with all portions of their profile as long as the session does not expire.

Access-controlling:

Any feature that, if maliciously modified within one session, could prevent access by the owner, and/or redirect information about access away from the owner. Changing of credentials or contact information, basically.

Liability-inducing:

Any feature that, if maliciously modified, could result in unauthorized financial transactions, or one that includes information that could lead to valid transactions being intercepted or otherwise repurposed.

Cross-Channel:

The same identifiers should be used in all channels. All websites, all applications, in store, at home. Rules may vary between the access points. For example, the mobile application (and website) should (probably) sign on with the same credentials, then retain the customer entirely authenticated, relying on the device's security.

Identification Management:

A cookie or similar key is placed on the customer's client machine. This is checked at each authenticated visit, and if no cookie is found a new one is created. No special first-use case must be developed. Since this key is on the client, and sent in plaintext, it must be secure. Do not place any intelligence in the key. It should not be the customer's name, location, customer ID, Keyfob ID, MEID, time created, store, card number, SSN or any other characteristic. It should not even be a random or encoded value using any customer-identifying information as the seed. All too often, these are cracked, with bad PR if you are lucky. It should be an entirely arbitrary key value, and nothing else. Make this key value as short as possible, to reduce bandwidth. Remember to not pad values for expected total sizes of the data store. The first users to register can have a key with the minimum secure/intepretable length, and then additional characters are added as the service grows. The key is sent to an authentication management service when the customer enters the site, and is looked up in a table to associate the key to a customer. That customer then has that authorization level.

User Management of Identification:

It is usually best to simply set the cookie for all users. Those who do not like them will disable cookies across the board, or for our domain. If there are concerns, then a method can be provided for the user to manage this:

• A checkbox on the authentication dialogue (set to saving the cookie by default).
• A setting in the user's profile.
• Help documentation should be provided with as much information as possible, and links to privacy and security policies

Note that explicit signout is another way for customers to "Manage" their cookies, by clearing them at each session. However, this is a manual, one-time process.

Timeout:

Identified sessions do not time out in a manner visible to the customer. They may continue using the site in the Identified state forever. When an Authenticated customer session times out, it seamlessly falls back to the Identified state. There is generally no need for notices, warnings or the presentation of the authentication dialogue. When the user next needs an Authentication-required feature, they transact this as usual, from the Identified state. Due to the seamless switching, this can increase security and be beneficial to server balancing. Sessions can be much shorter, as short as 5-10 minutes, without serious problems. Some cases may need to have special exemptions. Checkout, for example, may need to be extended or exempted if the process routinely takes customers more than the otherwise-recommended timeout period.

Explicit Signout:

When the customer explicitly signs off, they will return to the Anonymous state. This state should be persistent, and the cookie cleared.

Failed Authentication:

If an already-identified customer fails to correctly enter their second credential (the passcode) enough times, they may either be locked out entirely, or revert back to the Identified state, and only be locked out of re-authenticating. This decision will have to be made by the team, and Security. Any lockout should send a message out of channel to alert the customer of a possible attempt to break into their profile. Usually, this will just be an email, but the system should be built so it can send to SMS or use other channels as those notification capabilities are built.