Color mode

The Authentication Workflow

The authentication workflow consists of a multi-steps process to login (authenticate) a user such that the user can later access specific pages and APIs. The authentication workflow could involve registration steps but it is not necessary (How to enable/disable registration?).

Login/Authentication

There are 3 ways to authenticate a user on your site.

Method	MFA support	server-side revokation
Cookie	yes	per user
JWT (what is it?)	yes	all users at once
API Key	no	per user

The Cookie and JWT workflow follow the same sequence of pages presented to the user. If you prefer to call the auth APIs directly, you will have to design pages and the associated business logic to gather the information required yourself.

Identifying a user: Username, email and phone

The authentication workflow starts by identifying a user through a unique username, e-mail address or phone number. This can be done through an activate, login, or recover credentials pages.

The next steps in the authentication workflow depend on the identified user. Theses steps can either:

Show login disabled - Login can be disabled for a class of users (How to enable/disable login?)
Redirect to Single Sign-On (SSO) - specific e-mail domains can be marked such that authentication is delegated to a third-party. This is typically the case in B2B (If you need setup SAML identity providers for your site, please contact us).
Continue with multi-factor authentication (MFA)

Single Sign-On and Social Login

Single Sign-On (SSO) and Social Login, both, delegate authentication to a third-party identity provider. The key difference is that a user whose e-mail domain is identified to require a SSO workflow must authenticate through the third-party SSO provider. Social Login is a convienient workflow for users that prefer to authenticate through a third party (ex: GMail). It does not prevent users to register a full-blown account with your Website and use djaoapp multi-factor authentication workflow instead.

Multi-factor authentication

Your site provides three authentication out-of-box that can be combined into a multi-factor authentication workflow.

Password

Passwords are in the something you know category. This means that as long as your password is not easily guessable and you can remember it, it is very difficult to steal. As something solely stored in your head, passwords also have the advantage to support self-incrimination defenses in most places.

OTP verification

Your site supports Time-based One-Time Password (T-OTP) on a per-user basis. These are 6 digits code that are randomly generated at regular intervals from an initial seed. When enabling OTP, a user is presented with an initial seed as a QR code. The user will typically scan this QR code with a OTP authenticator app (ex: Google Authenticator). After which, when asked about the OTP by your site, they can read it in their authenticator app.

Because there is no communication prior to authentication through the OTP code between a user and your site, OTP are usually considered very secure. Of course, you should be careful not to loose your phone (if that is where the authenticator app resides).

Email verification

Your site can send a one-time link or a one-time code to a user that is later used to verify the user has access to that e-mail address.

Back links are convinient to a user (just click it) but with the amount of phishing e-mail sent around, many enterprise security teams will stress the "do not click a link in an e-mail" cybersecurity policy. Furthermore many enterprises e-mail servers will also be configured to lower scores on e-mail with links in them. As a result, sending one-time codes instead of one-time links is also available.

Phone verification

Phone verification works the same as e-mail verification. One-time backlinks are convienient if a user access your site on a smart phone. Codes are otherwise more convienient when a user logs into your site on a Desktop computer.

NOTES

Due to additional cost to send SMS to a phone, please contact us to enable phone verification on your site.

Nefarious bots considerations

Public pages are very much suject to bots automation, more so registration and login pages are prime targets for nefarious bots.

Both registration and login pages on your site support a specific rate limiting algorithm to prevent fake accounts creation and password brute force attacks respectively.

Register

It is possible to implement a variety of registration pages on your site, from frictionless registration, requiring just a full name and an e-mail (or phone number), to a ten fields form containing a password, full street address and/or your own custom fields.

Onboarding after authentication

At this point the user is authenticated. These steps are thus not technically part of the authentication workflow. None-the-less they are common enough, especially on registration, that they will be mentionned here.

Signing terms of use

Accepting the terms of use for the Website can be done through a custom field on the registration page, but it can also be done as a separate step in the authentication workflow.

In cases you update the terms of use and want current users to accept the new terms before continuing, you can do so by updating the date after which terms of use must be signed and add a "Agreed to Terms of Use" rule on the pages requiring signature of the new agreement.

Connecting to a profile

User and profile accounts are separate concepts. This enables you to implement:

a single login for multiple organization profiles
a parent having access to their personal and their children profiles

As a result, a key step of onboarding is to either create a new profile or connect to an existing profile.

For B2C Websites that primarly deal with individuals, it is possible to bypass this step by creating an implicit profile from a registered user. This can be done:

At registration, by requiring a physical address (i.e. add the street_address, locality, region, postal_code, and/or country in your registration form).
Through the is_personal field in a pricing plan, and a subscribed to plan access rule.