The common pattern for user registration, sign in, reset and removal of an account written out

auth-standard-requirements.md

Auth Stnadard Requirements

Problem statement

To tackle the common application pattern for authenticating, registering, resetting credentials, verifying, and unregistering from an application, the common patterns exists but many implementations make it hard to use the best solutions of different frameworks. While almost each application has this requirement, no standard has been defined.

Possible reasons why it's difficult

• Too many backend solutions for storing and updating credentials (DB, LDAP/AD, API, SSO, SAML, …)
• Added complexity when authorisation is required
• Added complexity when MFA is required
• Frameworks provide their own tools for integration, but are not interchangeable

Common components used

• a username: can take the form of a number, a string of characters, an email address
• a password or passphrase: random characters known only to the user (if generated randomly)
• an email address or phone number: for validation purposes

Common scenarios used

Registration of a new user

1. Registers for an account with username, password, password validation, some personal details, and an email address or phone number for validation purposes
2. Receives a confirmation email or text message with a verification code or link
3. Enters the validation code or clicks the validation link
4. Registration process is completed

Authentication of an existing user

1. Signs in with known username and password/passphrase
2. If successful, authentication is completed
3. If unsuccessful, login screen is returned with an error message
4. Authentication process is completed

Reset of an account

1. User provides username
2. Message informs user that if account is known, an email or a text message will be sent with instructions to reset their account (for both valid and invalid accounts)
3. The code has to be entered or the link in the mail has to be followed
4. The user provides a new password/passphrase (with second credential field for validation)
5. Reset process is completed

Deactivation of an account

1. User provides a username
2. Message informs user that if account is known, an email or a text message will be sent with instructions to deactivate their account (for both valid and invalid accounts)
3. The code has to be entered or the link in the email has to be followed
4. The user has to explicitly confirm again to deactivate or remove the account
5. Deactivation process is completed

Deactivation of an account, second point: instructions to reset their account? should this be deactivate instead of reset?

From what I've learned working on the Symfony security system, in modern security it is no longer safe to assume the traditional username+password authentication (MFA aside). Applications go great lengths to go passwordless with things like login links and WebAuthn. Hence, even the username is not safe (e.g. in the context of purely token based authentication between services).

Deactivation of an account, second point: instructions to reset their account? should this be deactivate instead of reset?

Correct, thank you for pointing it out to me @ttomdewit 👍

From what I've learned working on the Symfony security system, in modern security it is no longer safe to assume the traditional username+password authentication (MFA aside). Applications go great lengths to go passwordless with things like login links and WebAuthn. Hence, even the username is not safe (e.g. in the context of purely token based authentication between services).

You're absolutely right @wouterj, but in all honesty if we look at the total number of web applications that require authentication, this password less approach will be less than 1%. For all 99% remaining web applications, given that PHP is responsible for about 70% of them, a common standard would help a lot, don't you agree?

I'm not saying I am against the password less approach, but until there's more than a 50% adoption of this I will work on the traditional approach with traditional credentials, but feel free to add the scenario in. I wasn't fortunate to be working on such systems, so I have no idea how the workflow would look like.

I'm not saying I am against the password less approach, but until there's more than a 50% adoption of this I will work on the traditional approach with traditional credentials, but feel free to add the scenario in. I wasn't fortunate to be working on such systems, so I have no idea how the workflow would look like.

Hi,

I have been working for almost 2 years on a Webauthn implementation in PHP and what I can say is that there is no real difficulty in switching from traditional credenrtials to this new authentication method. Also, I observe that lots of websites are preparing for the change. (step 1 below)

We all know that a username / password is not enough and apps have been adding MFA for a long time. For a smooth transition, the idea is very simple

Step 1:

• Allow existing users to associate FIDO authenticators with their account. They have already done this for SMS codes, one-time access codes, push notifications, etc. The only difference is that they can add multiple authenticators (smartphone, computer with Windows Hello, MacOS, Yubikey, Fieitian ...)
• New user to add an authenticator when creating their account

Step 2:

• for users with authenticators, log them using Webauthn instead of username / password.
• for other users: depends on the application policy. You can either force them to add authenticators or consider their account is unsafe (with limited operations)

Step 3: When users have enabled Webauthn and you haven't noticed any issues, get rid of passwords and other dangerous MFA methods (especially SMS). No need to wait for all users.

Bonus: when users register their authenticators using specific options, you can register them without a username, i.e. directly using the authenticator and some means of identity verification (e.g. biometric such as the fingerprint or facial recognition)

In case of loss of an authenticator, the user can use another one and delete the lost one. Otherwise, a "send me a link by email / push" to add a new login is always possible.

@wouterj: the Webauthn implementation I mentioned has a SF bundle that is using the old security method. I will implement the new one and I am wondering if you could take time reviewing it.