Authentication: The Technological-Product View

There is a big difference between authentication and authorization, and this is (pretty much) all about authentication. At first, this all can seem pretty easy to implement, but things are much more complex than “we will use an auth library.” The article demonstrates the complexity of the topic, and provides a checklist, of sorts, documenting all of the decisions you need to make before you even start the search for an auth library.

I also offer a few suggestions for how you approach the decision-making process.

First, let’s make sure we’re on the same page. Authentication means identity verification, and authorization checks whether the authenticated entity (usually the user) has sufficient permissions to perform a given operation.

Take a regular Google Account login, for example. If Google tells the app that it’s me (the user with ID 123 and email example@cookielab.io), I’m authenticated, but any further action must go through an authorization process. Can the user write articles? Can the user publish them? And so on. For now, well save authorization for another day.

I’m not a security expert, so I don’t want to go into these topics. Therefore, I will not even address the method of storing sensitive data (i.e. passwords, personal data) and password hashing. There are more knowledgeable people on the topic - here’s a good place to start.

Your first important decision is to choose an authentication scheme. The most basic is HTTP basic - it’s easy to use on the client side, user management is “in one file”, and settings can be made on virtually any HTTP server without the need to change the application (unless we need to work with authorization). However, it is a variant in which user data (name and password) travels over the network with each HTTP request, and there is a high risk of capture and the identity theft that can come with it.

Another standard option is to send a username and password to an application based on session, and have it send its ID in the Cookie HTTP header. This is a much better solution, however Cookie work well in web browsers. What about mobile apps? Or TV? Or a smart thermostat?

OAuth 2.0 has become the industry standard. However, this it serves primarily as a way to enable users of one system to sign in with another, external or third-party application. In fact, the authentication server itself can be an application just logging in and managing users. The external application can be web application (React.js, Angular) or mobile apps (iOS, Android) from the same organization, another server, or another company.

This is a big topic, and there is a lot more to it, but for my purposes here, this scheme allows multiple authentication methods, multiple clients with different user data accesses, and approvals of these hits by the user. It also revokes access to individual clients and instances of one client, and a large number of extensions for smart devices without a web browser.

I will go deeper into these topics in the future, but I’ll start with an overview of the use cases you should be thinking about during the decision process.

Here are the basic use cases that need to be addressed:

How will the user log in?

  • Username and password
  • One time password/token
  • How does the user get the token/password? How is the user authenticated? (email, SMS, Touch ID, Face ID)
  • Which third parties do you want to support? (Google, Facebook, GitHub)

How does the user change their password?

  • Logged-in user in profile settings
  • Forgotten password
  • How is the user authenticated to request the change?
  • How is the user authenticated to actually change the password?

Do you want to support Single Sign-On (SSO)?

  • If so, which systems are involved?
  • Who manages adding/removing involved systems? How do they do it?

Do you want to support 2FA/MFA?

  • If so, is it required for everyone?
  • When and how does the user set it up?
  • How can the user cancel it?
  • How can a user recover the account when the device/keys are lost?

How can the user logout?

  • How does it work for the current session?
  • How does it work for other sessions (on other devices)?

How long is the expiration of the sessions?

  • Does it expire after web browser tab closing?
  • Is the expiration prolonged after each action in the app?

You also need to manage these users somehow, otherwise there would be no one to log-in.

How will user registration work?

  • Will the user use self-registration?
  • Will the user automatically register after an action (place an order, write a comment)?
  • Do you want to manually register and/or restrict users via already-existing (and logged-in) users?
  • Do you want to manually register users via a system administrator?
  • When and how does the user set the first password if we allow username and password login? It is usually not a good idea to have the admin set the first password if the admin creates the registration.

When does the user give consent (terms and conditions, privacy policy)?

  • How and when does the user give new consent when conditions change and new consent is needed?
  • Can the user use the system without giving consent? To what extent? For how long?
  • How is it different for a user who had given consent before but did not for changed conditions?

Is it necessary to activate an account/validate an email address?

  • Why? What is it good for?
  • If yes, when and how is it done?
  • Can the user use the system without confirmation? To what extent? For how long?
  • How do we authenticate users to activate an account/confirm an email address?
  • How does the user request the activation of the account/confirmation of the email address again if the information has not been received (e.g ended in SPAM folder)?
  • What will happen when the user changes their email address?

How can a user cancel or delete their account?

  • How does it differ if the user asks for deletion under the GDPR?

How do we manage authentication-related emails?

  • Design
  • Copy
  • Localization and timely delivery

Authorization

  • Who defines the authorization rules, where are they, and how are they decided upon?
  • Who manages authorization rules relating to users, where is this stored, and in what format(s)?

There are more use cases where you need to decide whether to use OAuth 2.0 or OpenID (or generally to provide authentication to third parties).

How does registering a new client work?

How does deactivating/deleting a client work?

  • What are the implications for existing users related to the client?
  • What happens to users logged-in to the client?

How are authorization rules for clients managed?

  • Who defines client authorization rules? When and how are they decided?
  • Which rules are automatically approved after client registration?

How does the client request changes in approved client authorization rules?

  • How does it differ between registration and for changes/updates?
  • How does it affect existing users?
  • How do you add/remove rules?

Do you want to support the possibility for each client to have multiple sub-clients (iOS, Android, Web)?

  • If so, what are their limitations?
  • How does it change from the main client?

How and where can the user deny access to previously-approved clients?

How and where does the user revoke individual “sessions” within one client?

How long is the expiration for tokens?

  • Access token
  • Refresh token
  • Authentication code

Do we want to use Json Web Tokens (JWT)?

  • What implications (positive and negative) does it have for the rest of the system?

It is possible that you don’t need to answer some of these use case questions today. But what about next year? Or, in five years? Will the system you’re working on today be “simply” expanded with additional features? Is this actually something you want to develop and manage yourself?

Personally, I prefer to take a working system and configure it to my needs. That doesn’t necessarily mean taking 20 libraries and packages and writing code to link and configure them for all parts. For some projects (especially internal), Google Suite (or a similar alternative) supports a feature that you can manage your users and their authorization rules for your apps.

However, a more versatile solution is needed for use on B2C projects because you (usually) do not want to register all of your users for the project internally. One may be Auth0, or alternatives like Okta, Amazon Cognito, OAuth.io. I haven’t tried it myself yet, but I’m sure I’ll use it when a suitable project comes up. Try it and let me know what you think!

I have to say that any single tool, library, package, or service will not help you with the decision on the use-cases listed above. It will help you with subsequent management, maintenance, and scalability. However, you have to figure out what’s best for your project. Take it as an inspiration to think about. You can also keep track of the updated and versioned checklist on GitHub.

Over the coming months, I will go deeper into related topics likes like authorization, OAuth2.0, and its extensions - and the decision-making process around authentication and authorization. Stay tuned!

Martin Štekl
Senior Backend Developer, GraphQL enthusiast