-
Notifications
You must be signed in to change notification settings - Fork 22.9k
Authentication overview page #41536
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Authentication overview page #41536
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,42 @@ | ||
| --- | ||
| title: Authentication | ||
| slug: Web/Security/Authentication | ||
| page-type: guide | ||
| sidebar: security | ||
| --- | ||
|
|
||
| Authentication is the process of verifying that an entity — such as a user of a website — is who they claim to be. You'll most likely need to think about authentication if you want users to sign into your website. | ||
|
|
||
| If users can log into your website, there are typically things logged-in users can do, or data they can access, that you don't want to make generally available. For example, logged-in users might be able to: | ||
|
|
||
| - Make use of a service they have paid for | ||
| - Spend money | ||
| - Access private personal or corporate information | ||
| - Interact socially with others in the persona associated with the account | ||
|
|
||
| All these abilities, and more, make user account access an important target for attackers. If an attacker is able to sign into your site by pretending to be a legitimate user, the attacker could access and exploit, for example, the user's private data, financial credentials, or confidental corporate secrets. They could also impersonate the user on your site, causing reputational and potentially financial damage. | ||
|
|
||
| In this set of guides we'll looks at the main techniques available for authenticating users on the web, and good practices for them. | ||
wbamberg marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| ## Authentication methods | ||
|
|
||
| In this set of guides we'll describe the following authentication systems. Each system might be deployed on its own or might be combined with others, either to give users a choice about which one they want to use, or to implement a {{glossary("multi-factor authentication")}} system. | ||
|
|
||
| - [Passwords](/en-US/docs/Web/Security/Authentication/Passwords) | ||
| - : A password is a relatively long-lasting secret presented by the user to the website when they need to log in. The website compares the password with a securely stored transformation of it, and logs the user in if they match. Passwords have many well-known security weaknesses, and in this article we'll explain the best practices to minimise them. | ||
wbamberg marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| - [One-time passwords (OTP)](/en-US/docs/Web/Security/Authentication/OTP) | ||
| - : A one-time password is a code generated by the website that is specific to a single login attempt. The website either sends the code to the user in a separate channel, such as an email, or the user's device independently generates the code. The user then enters the code on the site to log in. | ||
| - [Federated identity](/en-US/docs/Web/Security/Authentication/Federated_identity) | ||
| - : In most authentication systems there are two parties: the user, and the website they are trying to log into. In a federated system there is a third party, which is called an _identity provider_. When the user wants to sign into the website, the website asks the identity provider to identify the user, and if the identification is successful, logs the user in. | ||
| - [Passkeys](/en-US/docs/Web/Security/Authentication/Passkeys) | ||
| - : Passkeys enable websites to authenticate users without the user having to enter any passwords or other secret codes on the site itself. | ||
|
|
||
| In a system that uses passkeys, the user's device stores a {{glossary("Public-key cryptography", "cryptographic key pair")}} representing the user's registration on a particular site. When the user tries to log into the site, the site sends the device a challenge. The device {{glossary("digital signature", "signs")}} the challenge with the private key and sends the result to the website, which can verify the signature and log the user in. | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So basically the device just stores the private key most probably in a TPM or secure enclave - but it also depends if it is a synced passkey or hardware bounded passkey.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, I don't want to go into too much detail here, this is longer and more detailed than I would like (compared to the other ones, for instance). This is just to give a very quick idea of what kind of thing this auth method is, to contextualize it a bit. I support the main things to mention in this case are: (1) the user never has to enter any secret on the website, (2) it's based on the Web Authentication API, and (3) it uses public key cryptography to sign an assertion that the user is the person they claim to be, and the website is able to verify this signature. The most important thing I suppose is that it doesn't simplify so much that it gives an inaccurate picture. |
||
|
|
||
| Passkeys are implemented using the [Web Authentication API](/en-US/docs/Web/API/Web_Authentication_API). | ||
|
|
||
| ## Session management | ||
|
|
||
| After a website has authenticated a user, the website will typically want to keep this user signed in without the need to reauthenticate, either for a limited time or even indefinitely until the user signs out. Websites typically accomplish this by setting a cookie that contains a secret session identifier, or using a {{glossary("digital signature", "cryptographically signed")}} object such as a {{glossary("JWT", JSON Web Token(JWT)"")}}. | ||
|
|
||
| In our [session management](/en-US/docs/Web/Security/Authentication/Session_management) guide, we outline session management best practices. | ||
Uh oh!
There was an error while loading. Please reload this page.