-
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
base: main
Are you sure you want to change the base?
Authentication overview page #41536
Conversation
Preview URLs Flaws (6)URL:
(comment last updated: 2025-10-15 02:40:27) |
- [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 comment
The 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.
The Public key is send then together with the signed challenge to the site. (this is for registration - of course for login, the public key is already stored on the site I want to login
But I'm not sure if it is necessary to go in such a detail already here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The 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.
This is a top-level page for the new authentication docs, reflecting https://docs.google.com/document/d/1miZbXVjs070J2HH0rsDxqPnUaqNtPP51Uo8d4FU6PTk/edit?tab=t.0#heading=h.kbs51irq6pyz, more or less.
It's basically a landing page: that is, a navigational aid for people to reach the other pages we're going to write, and to put them in context. I expect we might want to expand it as/when we decide we want to add new pages, but at the moment it just assumes 5 subpages: one for each authentication method covered+1 for session management.
Anyway, it's enough for now, to provide some structure for the pages on authentication methods, which we're planning to write next.
@martinakraus , I would be happy for you to take a look at this and the other authentication PRs that will be coming, if you would like to :).