diff options
Diffstat (limited to 'files/ru/web/api/web_authentication_api/index.html')
| -rw-r--r-- | files/ru/web/api/web_authentication_api/index.html | 14 |
1 files changed, 7 insertions, 7 deletions
diff --git a/files/ru/web/api/web_authentication_api/index.html b/files/ru/web/api/web_authentication_api/index.html index d7951c18d6..4407249491 100644 --- a/files/ru/web/api/web_authentication_api/index.html +++ b/files/ru/web/api/web_authentication_api/index.html @@ -11,11 +11,11 @@ translation_of: Web/API/Web_Authentication_API <p>API Web Authentication (также называемое WebAuthn) использует {{interwiki("wikipedia", "Public-key_cryptography", "ассиметричную криптографию (систему с открытым ключом)")}} вместо паролей или SMS-сообщений для регистрации, входа и {{interwiki("wikipedia", "Multi-factor_authentication", "двухфакторной аутентификации")}} на веб-сайтах. Это устраняет многие значительные проблемы безопасности, такие как {{interwiki("wikipedia", "Phishing", "фишинг")}}, {{interwiki("wikipedia", "Data_breach", "утечки данных")}} и атаки на SMS или иные методы двухфакторной аутентификации, при этом сильно упрощая использование, т.к. пользователям не нужно запоминать десятки сложных паролей.</p> -<p>На многих сайтах уже есть страницы для регистрации и входа в существующие учетные записи, и Web Authentication API может быть как заменой, так и дополнением для них. Как и остальные виды <a href="/en-US/docs/Web/API/Credential_Management_API">Credential Management API</a>, Web Authentication API содержит два базовых метода: для регистрации и для входа:</p> +<p>На многих сайтах уже есть страницы для регистрации и входа в существующие учётные записи, и Web Authentication API может быть как заменой, так и дополнением для них. Как и остальные виды <a href="/en-US/docs/Web/API/Credential_Management_API">Credential Management API</a>, Web Authentication API содержит два базовых метода: для регистрации и для входа:</p> <ul> - <li>{{domxref("CredentialsContainer.create()", "navigator.credentials.create()")}} - при использовании с опцией <code>publicKey</code> создает новый набор учетных данных для регистрации нового аккаунта или добавления пары ключей к уже существующему.</li> - <li>{{domxref("CredentialsContainer.get()", "navigator.credentials.get()")}} - при использовании с опцией <code>publicKey</code> использует существующий набор учетных данных для аутентификации в сервисе в качестве основного способа входа или второго фактора.</li> + <li>{{domxref("CredentialsContainer.create()", "navigator.credentials.create()")}} - при использовании с опцией <code>publicKey</code> создаёт новый набор учётных данных для регистрации нового аккаунта или добавления пары ключей к уже существующему.</li> + <li>{{domxref("CredentialsContainer.get()", "navigator.credentials.get()")}} - при использовании с опцией <code>publicKey</code> использует существующий набор учётных данных для аутентификации в сервисе в качестве основного способа входа или второго фактора.</li> </ul> <p><strong>Обратите внимание</strong>, и <code>create()</code>, и <code>get()</code> работают только в <a href="/en-US/docs/Web/Security/Secure_Contexts">Secure Context</a> (например, когда подключение к серверу происходит через https или сервер работает на localhost).</p> @@ -43,8 +43,8 @@ translation_of: Web/API/Web_Authentication_API <li><strong>Приложение запрашивает регистрацию</strong> - The application makes the initial registration request. The protocol and format of this request is outside of the scope of the Web Authentication API.</li> <li><strong>Server Sends Challenge, User Info, and Relying Party Info</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 the Web Authentication API. 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 buffer of random information (at least 16 bytes) and it MUST be generated on the server in order to ensure the security of the registration process.</strong></li> <li><strong>Браузер вызывает authenticatorMakeCredential() для аутентификатора</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 is 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>Аутентификатор создает новую пару ключей и Attestation</strong> - Before doing anything, the authenticator will typically ask for some form of user verification. This could be entering a PIN, using a fingerprint, doing an iris scan, etc. to prove that the user is present and consenting to 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 authenticator 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>Аутентификатор передает информацию в браузер</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>Аутентификатор создаёт новую пару ключей и Attestation</strong> - Before doing anything, the authenticator will typically ask for some form of user verification. This could be entering a PIN, using a fingerprint, doing an iris scan, etc. to prove that the user is present and consenting to 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 authenticator 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>Аутентификатор передаёт информацию в браузер</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>Браузер создаёт итоговый набор данных, приложение отвечает серверу</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>Сервер проверят и завершает регистрацию</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> @@ -67,8 +67,8 @@ translation_of: Web/API/Web_Authentication_API <li><strong>Приложение запрашивает аутентификацию</strong> - The application makes the initial authentication request. The protocol and format of this request is outside of the scope of the Web Authentication API.</li> <li><strong>Server Sends Challenge</strong> - The server sends a challenge to the JavaScript program. The protocol for communicating with the server is not specified and is outside of the scope of the Web Authentication API. 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 buffer of random information (at least 16 bytes) and it MUST be generated on the server in order to ensure the security of the authentication process.</strong></li> <li><strong>Браузер вызывает authenticatorGetCredential() для аутентификатора</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 get() 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>Аутентификатор создает подпись</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>Аутентификатор передает информацию в браузер</strong> - The authenticator returns the authenticatorData and assertion signature back to the browser.</li> + <li><strong>Аутентификатор создаёт подпись</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>Аутентификатор передаёт информацию в браузер</strong> - The authenticator returns the authenticatorData and assertion signature back to the browser.</li> <li><strong>Браузер создаёт итоговый набор данных, приложение отвечает серверу</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>Сервер проверят и завершает аутентификацию</strong> - Upon receiving the result of the authentication request, the server performs validation of the response such as: <ol> |