1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
|
---
title: APi de Autenticação da Web
slug: Web/API/API_Autenticacao_Web
tags:
- API
- API de Autenticação da Web
- Landing
- Referencia
translation_of: Web/API/Web_Authentication_API
---
<div>{{draft}}{{SeeCompatTable}}{{securecontext_header}}{{DefaultAPISidebar("Web Authentication API")}}</div>
<p class="summary">A "API de Autenticação da Web" é uma extensão de <a href="/en-US/docs/Web/API/Credential_Management_API">Credential Management API</a> que permite uma autenticação forte com a criptografia de chave pública, permitindo a autenticação sem palavra-passe e/ou autenticação de segundo fator segura sem textos de SMS.</p>
<h2 id="Conceitos_e_utilização_da_autenticação_da_Web">Conceitos e utilização da autenticação da Web</h2>
<p>The Web Authtentication API (also referred to as WebAuthn) uses <a href="https://en.wikipedia.org/wiki/Public-key_cryptography">asymmetric (public-key) cryptography</a> instead of passwords or SMS texts for registering, authenticating, and <a href="https://en.wikipedia.org/wiki/Multi-factor_authentication">second-factor authentication</a> with websites. This resolves significant security problems related to <a href="https://en.wikipedia.org/wiki/Phishing">phishing</a>, <a href="https://en.wikipedia.org/wiki/Data_breach">data breaches</a>, and attacks against SMS texts or other second-factor authentication methods while at the same time significantly increasing ease of use (since users don't have to manage dozens of increasingly complicated passwords).</p>
<p>Many websites already have pages that allow users to register new accounts or sign in to an existing account, and WebAuthn acts as a replacement or suppliment to those on those existing webpages. Similar to the other forms of the <a href="/en-US/docs/Web/API/Credential_Management_API">Credential Management API</a>, the Web Authentication API has two basic methods that correspond to register and login:</p>
<ul>
<li><a href="/en-US/docs/Web/API/CredentialsContainer/create">navigator.credentials.create()</a> - when used with the publicKey option, creates new credentials, either for registering a new account or for associating a new asymmetric key pair credentials with an existing account.</li>
<li><a href="/en-US/docs/Web/API/CredentialsContainer/get">navigator.credentials.get()</a> - when used with the publicKey option, uses an existing set of credentials to authenticate to a service, either logging a user in or as a form of second-factor authentication.</li>
</ul>
<p><strong>Por favor, note:</strong> both create() and get() require a <a href="/en-US/docs/Web/Security/Secure_Contexts">Secure Context</a> (e.g. - the server is connected by https or is the localhost), and will not be available for use if the browser is not operating in a secure context.</p>
<p>In their most basic forms, both create() and get() receive a very large random number called a challenge from the server and they return the challenge signed by the private key back to the server. This proves to the server that a user is in possession of the private key required for authentication without revealing any secrets over the network.</p>
<p>In order to understand how the create() and get() methods fit into the bigger picture, it is important to understand that they sit between two components that are outside the browser:</p>
<ol>
<li><strong>Servidor</strong> - the WebAuthn API is intended to register new credentials on a server (also referred to as a service or a <a href="https://en.wikipedia.org/wiki/Relying_party">relying party</a>) and later use those same credentials on that same server to authenticate a user.</li>
<li><strong>Autenticador</strong> - the credentials are created and stored in a device called an authenticator. This is a new concept in authentication: when authenticating using passwords, the password is stored in a user's brain and no other device is needed; when authenticating using WebAuthn, the password is replaced with a key pair that is stored in an authenticator. The authenticator may be embedded into an operating system, such as Windows Hello, or may be a physical token, such as a USB or Bluetooth Security Key.</li>
</ol>
<h3 id="Registo">Registo</h3>
<p>A typical registration process has six steps, as illustrated in Figure 1 and described further below. This is a simplification of the data required for the registration process that is only intended to provide an overview. The full set of required fields, optional fields, and their meanings for creating a registration request can be found in the {{domxref("PublicKeyCredentialCreationOptions")}} dictionary. Likewise, the full set of response fields can be found in the {{domxref("PublicKeyCredential")}} interface (where {{domxref("PublicKeyCredential.response")}} is the {{domxref("AuthenticatorAttestationResponse")}} interface). Note most JavaScript programmers that are creating an application will only really care about steps 1 and 5 where the create() function is called and subsequently returns; however, steps 2, 3, and 4 are essential to understanding the processing that takes place in the browser and authenticator and what the resulting data means.</p>
<p><img alt="WebAuthn registration component and dataflow diagram" src="https://mdn.mozillademos.org/files/15801/MDN%20Webauthn%20Registration%20(r3).png" style="height: 546px; width: 1118px;"></p>
<p><em>Figura 1 - a diagram showing the sequence of actions for a WebAuthn registration and the essential data associated with each action.</em></p>
<p>Os passos de registo são:</p>
<ol start="0">
<li><strong>Registo de Pedidos da Aplicação</strong> - The application makes the initial registration request. The protocol and format of this request is outside of the scope of WebAuthn.</li>
<li><strong>Servidor Envia Desafio, Informação do Utilziador, e Envio de Informação de Confiança </strong>- The server sends a challenge, user information, and relying party information to the JavaScript program. The protocol for communicating with the server is not specified and is outside of the scope of WebAuthn. Typically, server communications would be <a href="/en-US/docs/Glossary/REST">REST</a> over https (probably using <a href="/en-US/docs/User:maybe/webidl_mdn/XMLHttpRequest_API">XMLHttpRequest</a> or <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a>), but they could also be <a href="/en-US/docs/Glossary/SOAP">SOAP</a>, <a href="https://tools.ietf.org/html/rfc2549">RFC 2549</a> or nearly any other protocol provided that the protocol is secure. The parameters received from the server will be passed to the <a href="/en-US/docs/Web/API/CredentialsContainer/create">create()</a> call, typically with little or no modification and returns a <a href="/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise">Promise</a> that will resolve to a {{domxref("PublicKeyCredential")}} containing an {{domxref("AuthenticatorAttestationResponse")}}. <strong>Note that it is absolutely critical that the challenge be a large buffer of random information (e.g. - more than 100 bytes) and it MUST be generated on the server in order to ensure the security of the registration process.</strong></li>
<li><strong>Navegador Chama o authenticatorMakeCredential() no Autenticador</strong> - Internally, the browser will validate the parameters and fill in any defaults, which become the {{domxref("AuthenticatorResponse.clientDataJSON")}}. One of the most important parameters is the origin, which recorded as part of the clientData so that the origin can be verified by the server later. The parameters to the create() call are passed to the authenticator, along with a SHA-256 hash of the clientDataJSON (only a hash is sent because the link to the authenticator may be a low-bandwidth NFC or Bluetooth link and the authenticator is just going to sign over the hash to ensure that it isn't tampered with).</li>
<li><strong>Autenticador Cria Novo Par de Chave e Certificação </strong>- Before doing anything, the authenticator will typically ask for some form of user verficiation. This could be entering a PIN, using a fingerprint, doing an iris scan, etc. to prove that the user is present and consenting of the registration. After the user verification, the authenticator will create a new asymmetric key pair and safely store the private key for future reference. The public key will become part of the attestation, which the authtenticator will sign over with a private key that was burned into the authenticator during its manufacturing process and that has a certificate chain that can be validated back to a root of trust.</li>
<li><strong>Autenticador Devolve os Dados para o Navegador </strong>- The new public key, a globally unique credential id, and other attestation data are returned to the browser where they become the attestationObject.</li>
<li><strong>Navegador Cria os Dados Finais, a Aplicação envia a resposta para o Servidor</strong> - The create() Promise resolves to an {{domxref("PublicKeyCredential")}}, which has a {{domxref("PublicKeyCredential.rawId")}} that is the globally unique credential id along with a response that is the {{domxref("AuthenticatorAttestationResponse")}} containing the {{domxref("AuthenticatorResponse.clientDataJSON")}} and {{domxref("AuthenticatorAttestationResponse.attestationObject")}}. The {{domxref("PublicKeyCredential")}} is sent back to the server using any desired formatting and protocol (note that the ArrayBuffer properties need to be be base64 encoded or similar).</li>
<li><strong>Servidor Valida e Finaliza o Registo</strong> - Finally, the server is required to perform a series of checks to ensure that the registration was complete and not tampered with. These include:
<ol>
<li>Verifying that the challenge is the same as the challenge that was sent</li>
<li>Ensuring that the origin was the origin expected</li>
<li>Validating that the signature over the clientDataHash and the attestation using the certificate chain for that specific model of authenticator</li>
</ol>
A complete list of validation steps <a href="https://w3c.github.io/webauthn/#registering-a-new-credential">can be found in the WebAuthn specification</a>. Assuming that the checks pan out, the server will store the new public key associated with the user's account for future use -- that is, whenever the user desires to use the public key for authentication.</li>
</ol>
<h3 id="Autenticação">Autenticação</h3>
<p>After a user has registered with WebAuthn, they can subsequently authenticate (a.k.a. - login or sign-in) with the service. The authentication flow looks similar to the registration flow, and the illustration of actions in Figure 2 may be recognizable as being similar to the illustration of registration actions in Figure 1. The primary differences between registration and authentication are that: 1) authentication doesn't require user or relying party information; and 2) authentication creates an assertion using the previously generated key pair for the service rather than creating an attestation with the key pair that was burned into the authenticator during manufacturing. Again, the discription of authentication below is a broad overview rather than getting into all the options and features of WebAuthn. The specific options for authenticating can be found in the {{domxref("PublicKeyCredentialRequestOptions")}} dictionary, and the resulting data can be found in the {{domxref("PublicKeyCredential")}} interface (where {{domxref("PublicKeyCredential.response")}} is the {{domxref("AuthenticatorAssertionResponse")}} interface) .</p>
<p><img alt="WebAuthn authentication component and dataflow diagram" src="https://mdn.mozillademos.org/files/15802/MDN%20Webauthn%20Authentication%20(r1).png" style="height: 527px; width: 1067px;"></p>
<p><em>Figure 2 - similar to Figure 1, a diagram showing the sequence of actions for a WebAuthn authentication and the essential data associated with each action.</em></p>
<ol start="0">
<li><strong>Auyenticação dos Pedidos da Aplicação</strong> - The application makes the initial authentication request. The protocol and format of this request is outside of the scope of WebAuthn.</li>
<li><strong>Servidor Envia Desafio </strong>- The server sends a challenge JavaScript program. The protocol for communicating with the server is not specified and is outside of the scope of WebAuthn. Typically, server communications would be <a href="/en-US/docs/Glossary/REST">REST</a> over https (probably using <a href="/en-US/docs/User:maybe/webidl_mdn/XMLHttpRequest_API">XMLHttpRequest</a> or <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a>), but they could also be <a href="/en-US/docs/Glossary/SOAP">SOAP</a>, <a href="https://tools.ietf.org/html/rfc2549">RFC 2549</a> or nearly any other protocol provided that the protocol is secure. The parameters received from the server will be passed to the <a href="/en-US/docs/Web/API/CredentialsContainer/get">get()</a> call, typically with little or no modification. <strong>Note that it is absolutely critical that the challenge be a large buffer of random information (e.g. - more than 100 bytes) and it MUST be generated on the server in order to ensure the security of the authentication process.</strong></li>
<li><strong>Navegador Chama o authenticatorGetCredential() no Autenticador</strong> - Internally, the browser will validate the parameters and fill in any defaults, which become the {{domxref("AuthenticatorResponse.clientDataJSON")}}. One of the most important parameters is the origin, which recorded as part of the clientData so that the origin can be verified by the server later. The parameters to the create() call are passed to the authenticator, along with a SHA-256 hash of the clientDataJSON (only a hash is sent because the link to the authenticator may be a low-bandwidth NFC or Bluetooth link and the authenticator is just going to sign over the hash to ensure that it isn't tampered with).</li>
<li><strong>Autenticador Cria uma Certificação </strong> - The authenticator finds a credential for this service that matches the Relying Party ID and prompts a user to consent to the authentication. Assuming both of those steps are successful, the authenticator will create a new assertion by signing over the clientDataHash and authenticatorData with the private key generated for this account during the registration call.</li>
<li><strong>Autenticador Devolve os Dados para o Navegador</strong> - The authenticator returns the authenticatorData and assertion signature back to the browser.</li>
<li><strong>Navegador Cria os Dados Finais, a Aplicação envia a resposta para o Servidor </strong>- The browser resolves the <a href="/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise">Promise</a> to a {{domxref("PublicKeyCredential")}} with a {{domxref("PublicKeyCredential.response")}} that contains the {{domxref("AuthenticatorAssertionResponse")}}. It is up to the JavaScript application to transmit this data back to the server using any protocol and format of its choice.</li>
<li><strong>Servidor Valida e Finaliza a Autenticação </strong>- Upon receiving the result of the authentication request, the server performs validation of the response such as:
<ol>
<li>Using the public key that was stored during the registration request to validate the signature by the authenticator.</li>
<li>Ensuring that the challenge that was signed by the authenticator matches the challenge that was generated by the server.</li>
<li>Checking that the Relying Party ID is the one expected for this service.</li>
</ol>
A full list of the <a href="https://w3c.github.io/webauthn/#verifying-assertion">steps for validating an assertion can be found in the WebAuthn specification</a>. Assuming the validation is successful, the server will note that the user is now authenticated. This is outside the scope of the WebAuthn specification, but one option would be to drop a new cookie for the user session.</li>
</ol>
<h2 id="Interfaces">Interfaces</h2>
<dl>
<dt>{{domxref("CredentialsContainer")}}</dt>
<dd>WebAuthn extends the <a href="/en-US/docs/Web/API/Credential_Management_API">Credential Management API</a>'s <a href="/en-US/docs/Web/API/CredentialsContainer/create">create()</a> and <a href="/en-US/docs/Web/API/CredentialsContainer/get">get()</a> methods to take a new option: publicKey. When the publicKey option is passed to create() and / or get(), the Credential Management API will create a new public key pair or get an authentication for a key pair, respectively.</dd>
<dt>{{domxref("PublicKeyCredential")}}</dt>
<dd>A credential for logging in to a service using an un-phishable and data-breach resistant asymmetric key pair instead of a password.</dd>
<dt>{{domxref("AuthenticatorResponse")}}</dt>
<dd>Part of the PublicKeyCredential, the AuthenticatorResponse includes information from the browser (such as the challenge and origin); as well as information from the authenticator such as an AuthenticatorAttestationResponse (for new credentials) or an AuthenticatorAssertionResponse (when authenticating with existing credentials).</dd>
<dt>{{domxref("AuthenticatorAttestationResponse")}}</dt>
<dd>When a PublicKeyCredential has been created with the <a href="/en-US/docs/Web/API/CredentialsContainer/create">create()</a> call, it will include an AuthenticatorAttestationResponse. This is the authenticator's way of providing a cryptographic root of trust for the new key pair that has been generated.</dd>
<dt>{{domxref("AuthenticatorAssertionResponse")}}</dt>
<dd>When a PublicKeyCredential is the result of a <a href="/en-US/docs/Web/API/CredentialsContainer/get">get()</a> call, it will include an AuthenticatorAssertionResponse. This is the authenticator's way of proving to a service that it has the key pair and that the authentication request is valid and approved.</dd>
</dl>
<h2 id="Opções">Opções</h2>
<dl>
<dt>{{domxref("PublicKeyCredentialCreationOptions")}}</dt>
<dd>The options for creating a credential via <a href="/en-US/docs/Web/API/CredentialsContainer/create">navigator.credentials.create() </a></dd>
<dt>{{domxref("PublicKeyCredentialRequestOptions")}}</dt>
<dd>The options for using a credential via <a href="/en-US/docs/Web/API/CredentialsContainer/get">navigator.credentials.get() </a></dd>
</dl>
<h2 id="Exemplos">Exemplos</h2>
<ul>
<li><a class="external" href="https://webauthn.bin.coffee/">Mozilla Demo</a> website and it's <a href="https://github.com/jcjones/webauthn.bin.coffee">source code</a>.</li>
<li><a class="external" href="http://webauthndemo.appspot.com/">Google Demo</a> website and it's <a href="https://github.com/google/webauthndemo">source code</a>.</li>
</ul>
<h2 id="Especificações">Especificações</h2>
<table class="standard-table">
<tbody>
<tr>
<th scope="col">Especificação</th>
<th scope="col">Estado</th>
<th scope="col">Comentário</th>
</tr>
<tr>
<td>{{SpecName('WebAuthn')}}</td>
<td>{{Spec2('WebAuthn')}}</td>
<td>Definção inicial.</td>
</tr>
</tbody>
</table>
<h2 id="Compatibilidade_do_Navegador">Compatibilidade do Navegador</h2>
<div>
<div>
<p>{{Compat("api.PublicKeyCredential")}}</p>
</div>
</div>
<h2 id="Consulte_também">Consulte também:</h2>
<ul>
<li><a href="https://www.youtube.com/watch?v=UNI_Ad-9gX8">WebAuthentication and WebPayment demo</a> num dispositivo Android</li>
</ul>
|
