Flexible Authentication
Just Factors, No Restrictions
Last updated
Just Factors, No Restrictions
Last updated
Quasr offers like many other solution the option to configure , though what's different is that it doesn't allow customers to fix the user login and sign-up experience (at least not from server side) as to what you find with other solutions. The motivation is in fact to provide users best experience and re-focus our customers to the more important aspects of security-grading the factors they allow users to use (which more often is dictated by solution providers). Let us dive into more detail.
An "ID-First" approach refers to a login flow where not all authentication methods are offered to all users at once but in an initial step the user first provides an identifier such as a username by which the authentication server (Quasr) then determines what available authentication methods this user actually has enrolled in.
For example, if this user does not actually has set up a password or has not set up an authenticator app, it would not make much sense that a login UI would offer this to the user in the first place. Our APIs and its design is optimized for this approach.
A user with username "blackwidow" logs in with the username, the system then detects that this user only has various socials (Google, Slack, Facebook, LinkedIn, GitHub & Apple), Authenticator App (Time-Based One-Time Password) and an Email One-Time Password set up, and hence only offers these as subsequent options.
However, when user "ninja" logs in, the system detects that this user has only two social logins (Google and Facebook), and a Time-Based One-Time Password (TOTP); on the other hand, this user does not have an Email One-Time Password set up - so this option is not shown to the user.
A good login page following the ID-First approach should therefore adjust dynamically to the current user and authentication factors that are available.
At Quasr we do believe in a passwordless future as we feel passwords are impractical for users and have various security challenges. Nonetheless we do offer a password factor as we understand our customers may still need it for the time being. Though we want to challenge our customers to think and plan for a passwordless future. Hence users can enroll in various factors allowing passwords to be phased out over time without implications.
The total score a user has within a session plays a vital role in what the user can do next. Based on the score they could obtain (or not!) certain permissions for your applications, for example a higher score may be needed to access sensitive data. You can configure 'threshold scores' for API access as well as legal consenting.
Now to go back to our comment about fixing the login or sign-up experience. Notice that no where we mentioned that a username needs to necessarily come first ... the reasoning is that you provide authentication factors to your users - and they can choose from them as they see fit. This provides most flexibility and better user experience to your end users without sacrificing your security, as all factors are graded by you you still control what's needed to get access.
It's crucial you configure scores correctly and set thresholds accordingly. Be mindful that scores stand for a factor by itself and should always be additive, say you give a score of 1 to OTP it means that in whatever context passing OTP results in a score increase of 1.
When a user enrolls with a factor we call this an enrollment. Say a user picks a username using the they will now have a username enrollment representing this chosen username. The Quasr platforms allows users to have multiple enrollments even for a single factor, say multiple usernames or multiple passwords or even socials. This greatly improves user experience, and it avoids account lock-out by providing users multiple options.
Every you configure will be available for all of your users to use, what's new is that you need to provide a security grade for each on of them. No worries if you're not comfortable doing this we provide industry-best defaults. Though still it's important to understand these scores and how they contribute to the overall workings of the platform.
Each user has a score and by successfully passing an authentication factor their score will grow by the score attached to this factor. Say I pass a plus email , and their scores are respectively 1 and 2 it now means my score is 3. The scores for each factor can be decided by you - as you do better understand your own business and other components that make part of the complete solution.