Understanding Authentication from Your User’s Point of View
Sorry, comments are closed.
Successfully and securely implementing authentication on any website can be a daunting task, even for the most experienced developers. This is why the conversation often focuses on widely accepted standards, protocols and library implementations instead of user requirements. Comfort level and pervasiveness quickly become the primary factor in a choice of technology, but this can complicate the development process when it’s realized the choice does not provide all of the necessary features.
In order to help clear up some of this confusion I’m providing a set of common user stories that are very close to real-world scenarios. If you’re not familiar with agile development practices then you will find it helpful to read Scrum User Stories on the Scrum Methodology website to become more familiar with the format. It’s worth pointing out that I’ve implemented every one of these in production systems, and so I’ve attempted to remove any ambiguity based upon that experience.
It’s also important that you focus intently on the rationale for each of these, which is the so that portion of each user story. Programmatically you may find that several of these need to be completed as a whole in order to meet all of the conditions (often called acceptance criteria in SCRUM terms), which is perfectly fine. However, that process should be approached as an evolution, and not a single conjoined user story.
Private Credentials User Story
As a user, I want to securely login to your website, so that I can maintain a personalized account profile with saved preferences.
This is the simplest of all the user stories, and the one that is most recognized by developers. It often takes the form of username and password credentials stored in a database. However, I made it a point not to mention that since the chief concern of the user is security and a personalized profile. From there an analysis of the problem domain will likely lead down the path of a username and password provided over SSL.
On an intranet the username and password could be replaced with a signed certificate on each user’s computer, however unlikely. The key is to focus on the user experience, and the technology choice will quickly surface. This user story is the one most often combined with one of the others in an environment where multiple domains are involved.
Shared Credentials User Story
As a user, I want to securely login to your website using my Google or Facebook account, so that I don’t have to maintain another username and password.
Shared credentials can be confusing because so many developers insist using Google or Facebook to login constitutes single sign-on, which is simply not the case. The difference would be the requirement to grant permission on every domain, or the requirement to reauthenticate on some domains. You may find upon further review that the rationale behind mentioning Google or Facebook is simply the frustration with a user having to maintain another account.
Another example user story would be one that focuses on the user’s experience on the company intranet. There can be file sharing through Sharepoint, ticket management through JIRA, web mail through Outlook, and project management through Basecamp. Your shared credentials would be your network login, and if single sign-on is not layered over top of the shared credentials then you would be required to login to each of these applications.
Trusted Credentials User Story
As a user, I want to provide your website access to content (resources) I own on another website, but I don’t want to give you my username and password for that website.
When you provide your Facebook account access to your Twitter feed, or allow Instagram to access to your Flickr photos, then this is what you’re accomplishing. It’s multiple sets of credentials that are trusted across domains. The dominant theme here though is the resources on those domains, who owns them, and how they can be accessed securely. This is the antithesis of the previous user story because the user is not interested in sharing credentials – only resources.
The idea of trusting credentials for the purpose of sharing resources is almost exclusively a feature of OAuth. Keep in mind though that OAuth is not a method by which you authenticate. You still authenticate with a username and password. OAuth simply allows you to do so on multiple domains without sharing credentials for the explicit purpose of sharing resources.
Developers get this wrong all the time. If you have a user that has already authenticated via private credentials, and all you want is seamless integration between a client browser and service on separate domains without using session cookies then you need to layer on web tokens or CORs, and not OAuth.
Single Sign-on User Story
As a user, I want to securely login once to all of your websites using a single username and password, so that I don’t need to login multiple times.
The rationale is extremely important with single sign-on because the user does not want to have to login multiple times, and so any barrier to that must be removed. This even includes eliminating the requirement to provide permission for access to each domain. The sticking point here is that session management on each domain is often maintained independently, which can be confusing when timeouts are not synced properly across applications.
Single sign-on is by far the most complex of all the user stories because it’s actually authentication agnostic. Just like OAuth, it’s not truly a method by which you authenticate, but a method by which you can meet additional acceptance criteria related to authentication. Also, in single sign-on it’s common that the credentials are stored with a central identity manager that exists on a domain entirely different from the domains that require authentication.
If you want to know more about how single sign-on can work both in theory and implementation then the Shibboleth wiki has some good documentation. Shibboleth is an open-source implementation provider of single sign-on services using the SAML2 protocol as a means of communication between domains.
Single Sign-on Federation User Story
As a user, I want to securely login once to all of your websites using a single username and password trusted elsewhere, so that I don’t need to create another account.
The only real difference between single sign-on and federated single sign-on is that a user’s credentials can belong on another domain within another organization entirely. You may not even maintain, or have access to those credentials, but you belong to the federation, and so you agree to trust them as authenticated. The only thing released to your website is the user principal (e.g. – username) associated with the credentials, and any roles or permissions. Many universities and libraries belong to federations.
It’s best to start with a fresh outlook when researching authentication mechanisms. Gravitating toward a particular technology without considering how it aligns with the intended goal will waste a lot of effort. Although, there can be extenuating circumstances that force you to include or exclude certain technologies. There’s definitely a lot to consider when implementing authentication, but at the forefront of your mind should be the user, and hopefully this post helps.