Перевод OpenD Connect на английский

OpenID_Connect.md

@@ -1,39 +1,39 @@
 # OpenID Connect
 
-## Вводная информация
+## Introduction
 
-На данный момент серьезной проблемой для международных компаний при ведении бизнеса на территории Российской Федерации является использование глобальных веб-сайтов. 
-В соответствии с местным законодательством, зарубежные веб-сайты не могут обрабатывать персональные данные граждан Российской Федерации без их первоначального сбора и обработки в локальных базах данных. 
+At the moment, the use of global websites is a serious problem for international companies when doing business in the Russian Federation.
+In accordance with local legislation, foreign websites cannot process personal data of citizens of the Russian Federation without first collecting and processing it in local databases.
 
-Решением данной проблемы является использование сервера, размещенного на территории Российской Федерации, который будет осуществлять сбор необходимых данных, их обновление, хранение, а также будет давать возможность конечным пользователям изменять внесенные данные, отзывать согласия и т.д.
+The solution to this problem is to use a server located on the territory of the Russian Federation, which will collect the necessary data, update, store, and also allow end users to change the entered data, revoke consent, etc.
 
-Таким решением, решающим проблему локализации персональных данных, является разработанная нами система.
+The system developed by us is such a solution that solves the problem of localizing personal data.
 
-Система предусматривает работу по протоколу OpenID Connect в соответствии со стандартом [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0-final.html). 
-Перейдя по ссылке на спецификацию можно изучить основную функциональность OpenID Connect: аутентификацию, построенную на базе [OAuth 2.0](https://oauth.net/2/), и использование формул для передачи информации о конечном пользователе.
+The system provides for OpenID Connect protocol in accordance with [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0-final.html) stadard. 
+Follow the link to the specification to explore the core functionality of OpenID Connect: 	authentication built on top of [OAuth 2.0](https://oauth.net/2/), and the use of Claims to communicate information about the End-User.
 
-Также в рамках системы развернута конфигурация staging-окружения (https://staging.ps.radium-it.ru/.well-known/openid-configuration), в рамках которого возможно тестирование работы сервера авторизации oidc. 
+Also, within the framework of the system, a Staging environment configuration is deployed (https://staging.ps.radium-it.ru/.well-known/openid-configuration), within which it is possible to test the operation of the oidc authorization server.
 
-Важно отметить, что адрес production-сервера будет отличен от staging-окружения.
-Для настройки брендированного адреса сервера авторизации oidc, например, https://client.privacy.ru или https://client.ps.radium-it.ru вам потребуется создать CNAME-запись на DNS-сервере нужного домена.
+It is important to note that the address of the Production server will be different from the Staging environment.
+To customize a web address of the oidc authorization server, for example, https://client.privacy.ru or https://client.ps.radium-it.ru you need to add a CNAME Record to the necessary domain`s DNS.
 
-Кроме того, система предполагает наличие конечной точки jwks_endpoint, предоставляемой сервером авторизации oidc, с которой могут быть получены открытые ключи для проверки подписи подписанных JWT (https://staging.ps.radium-it.ru/.well-known/jwks.json).
-Вся необходимая информация относительно конфигурации доступна по [ссылке](https://ldapwiki.com/wiki/Openid-configuration).
+In addition, the system assumes a jwks_endpoint, provided by the oidc authorization server, from which public keys can be obtained to verify the signature of signed JWTs (https://staging.ps.radium-it.ru/.well-known/jwks.json).
+All the necessary information regarding the configuration is available [here](https://ldapwiki.com/wiki/Openid-configuration).
 
-Далее будет представлен более подробный механизм работы системы по протоколу OpenID Connect, примеры запросов, потоков данных и т.д.
-Мы предоставляем возможность изучить нашу систему и опробовать работу в конфигурации по описанному алгоритму.
+Futher, a more detailed mechanism of the system operation on the OpenID Connect protocol, examples of requests, data flows, etc will be presented.
+We provide an opportunity to study our system and try out the work in the configuration of the described algorithm. 
 
-## Схема работы протокола OpenID Connect Core 1.0
+## Scheme of the OpenID Connect Core 1.0 protocol work
 
-### Этап 1. Посещение зарубежного сайта
+### Stage 1. Visiting a foreign website
 
-Когда пользователь заходит на веб-сайт, веб-сайт определяет, знаком ли этот пользователь веб-сайту или он заходит на сайт впервые. 
-Проверка осуществляется путем анализа GET-запроса от пользователя на наличие cookie-файлов.
+When an End-User visits a website, the website determines whether the End-User is familiar with the website or is visiting the site for the first time.
+The check is carried out by analyzing the GET request from the user for the presence of cookies. 
 
-В случае, если по cookie-файлам было определено, что пользователь уже посещал данный веб-сайт, то ему представляется доступ `grant access`.
+If a cookie determines that the End-User has already visited the website, access is granted `grant access`.
 
-Если никакие данные о пользователе не найдены, веб-сайту необходимо установить личность пользователя. 
-Для этого веб-сайт перенаправляет пользователя на сервер авторизации oidc и включает в запрос Сlient ID, Redirect Uri, Response Type и одно или несколько Scopes (разрешений), которые ему необходимы (см. рисунок 1).
+If no data about the End-User is found, the website needs to identify the End-User.
+To do this, the website redirects the End-User to the oidc authorization server and includes in the request Сlient ID, Redirect Uri, Response Type and one or more Scopes (permissions), that it needs (see Figure 1).
 
 ```mermaid
 flowchart LR
@@ -43,29 +43,29 @@ flowchart LR
     D--> F[Grant access]
     E-->|Client_ID, Redirect_Uri, <br> Response_Type, cookies|G[oidc]
 ```
-*Рисунок 1. Пользователь посещает веб-сайт*
+*Figure 1. End-User visits website*
 
 ```
 GET https://staging.ps.radium-it.ru/oidc/authorize?scope=openid&redirect_uri=website/cb&client_id=AC!8&response_type=id_token"
 Host: ps.radium-it.ru
 ```
-Вместе с запросом от веб-сайта сервер авторизации oidc получает cookie-файлы, и на основании полученных данных решает - авторизован данный пользователь или нет.
+The oidc authorization server receives cookies along with the request from the website, and based on this data decides whether the End-User is authorized or not.
 
-Если конечный пользователь уже был авторизован, то autorization_endpoint спрашивает у базы данных, было ли получено согласие пользователя для этого веб-сайта. 
-Если согласие для этого сайта еще не было дано пользователем, то сервер авторизации oidc выводит форму Consent (подтверждения) с перечнем всех Scopes (разрешений), запрашиваемых веб-сайтом, а также с чекбоксом для подтверждения согласия на обработку персональных данных. 
+If the End-User has already been authorized, authorization_endpoint asks the database if the End-User's consent has been obtained for that website.
+If consent for this site has not yet been given by the End-User, the oidc authorization server displays a Consent form with a list of all Scopes requested by the website, as well as a checkbox to confirm consent to the processing of personal data. 
 
-На странице пользователь видит форму для заполнения данных и следующий текст **(В ИДЕАЛЕ ДОБАВИТЬ РИСУНОК С ДЕМО ВЕРСИЕЙ СТРАНИЧКИ/Рисунок 2)**:
+On the page the End-User sees a form to fill out the data and the following text **(В ИДЕАЛЕ ДОБАВИТЬ РИСУНОК С ДЕМО ВЕРСИЕЙ СТРАНИЧКИ/Рисунок 2)**:
 
-> Сайт example.client.ru запрашивает доступ к вашим данным: ID, email
+> The example.client.ru requests access to your data: ID, email
 > 
-> Разрешить доступ к данным?
+> Allow data access?
 > 
-> [X] Согласие
+> [X] Consent
 > 
-> [Разрешить / Submit]
+> [Submit]
 
 
-Как только пользователь нажимает [Разрешить / Submit], Consent записывается в базу данных `sub+client_id+date+scope` и пользователь тут же перенаправляется с сервера авторизации oidc обратно на тот веб-ресурс, куда он хотел попасть (см. рисунок 3).
+As soon as the End-User clicks [Submit], Consent is written to the `sub+client_id+date+scope` database and the End-user is immediately redirected from the oidc authorization server back to the website he wanted to visit (see Figure 3).
 
 ```
 HTTP/1.1 302 Redirect
@@ -82,51 +82,51 @@ I-->B(Website)
 J--> K[/Web consent/]--> B(Website)
 E-->AF[/Authorization form/]
 ```
-*Рисунок 3. Аутентификация пользователя на сервере авторизации*
+*Figure 3. End-User authentication on oidc authorization server*
 
-Если же сервер решает, что пользователь никогда не был авторизован, то сервер авторизации oidc просит конечного пользователя авторизоваться. 
-Переходим к этапу 2.
+If the server decides that the user has never been authorized, then the oidc authorization server asks the end user to authorize. 
+Let`s move on stage 2.
 
-### Этап 2. Посещение страницы авторизации и ввод первичных данных
+### Stage 2. Visiting Consent page & entering primary data
 
-Сервер авторизации oidc выводит форму Consent (подтверждения) с перечнем всех Scopes (разрешений), запрашиваемых веб-сайтом. 
-На странице пользователь видит форму для заполнения данных и следующий текст **(В ИДЕАЛЕ ДОБАВИТЬ РИСУНОК С ДЕМО ВЕРСИЕЙ СТРАНИЧКИ/см. рисунок 2)**:
+The oidc authorization server displays a Consent form listing all the Scopes requested by the website.
+On the page the End-User sees a form to fill out the data and the following text **(В ИДЕАЛЕ ДОБАВИТЬ РИСУНОК С ДЕМО ВЕРСИЕЙ СТРАНИЧКИ/см. рисунок 2)**:
 
-> Сайт example.client.ru запрашивает доступ к вашим данным: ID, email. 
+> The example.client.ru requests access to your data: ID, email. 
 > 
-> Если вы разрешаете доступ к данным, введите данные в отмеченные поля и нажмите [Разрешить / Submit]
+> If you allow access to the data, enter the data in the marked fields and click [Submit]
 > 
-> [] Согласие
+> [] Consent
 > 
-> | Введите ваш email |
+> | Enter your email |
 
-Помимо заполнения поля для ввода email пользователь также проставляет галочку в чекбоксе, подтверждая тем самым свое согласие на обработку персональных данных. 
+In addition to filling out the field for entering email, the End-User also ticks the checkbox, thereby confirming his consent to the processing of personal data.  
 
-После того, как пользователь ввел email в форму, проставил галочку в чекбокс и нажал кнопку [Разрешить / Submit], он видит страницу со следующим содержанием **(В ИДЕАЛЕ ДОБАВИТЬ РИСУНОК С ДЕМО ВЕРСИЕЙ СТРАНИЧКИ/Рисунок 4)**:
+After the End-User has entered the email into the form, put a tick in the checkbox and clicked [Submit], he sees a page with the following text **(В ИДЕАЛЕ ДОБАВИТЬ РИСУНОК С ДЕМО ВЕРСИЕЙ СТРАНИЧКИ/Рисунок 4)**:
 
-> Спасибо за предоставленные данные, проверьте указанную электронную почту.
+> Thank you for your submission, please check your email.
 
-В тот момент, когда пользователь нажимает кнопку [Разрешить / Submit], на сервер авторизации oidc отправляется запрос о необходимости отправить пользователю *magic link*, в следствии чего сервер авторизации oidc уже со своей стороны отправляет на указанную почту письмо, содержащее *magic link* и следующий текст **(В ИДЕАЛЕ ДОБАВИТЬ РИСУНОК С ДЕМО ВЕРСИЕЙ СТРАНИЧКИ/Рисунок 5)**:
+When the End-User clicks [Submit], a request is sent to the oidc authorization server to send a *magic link* to the End-User, whereupon the oidc authorization server sends an email containing a *magic link* and the following text to the specified email **(В ИДЕАЛЕ ДОБАВИТЬ РИСУНОК С ДЕМО ВЕРСИЕЙ СТРАНИЧКИ/Рисунок 5)**:
 
-> Если вы хотите получить доступ к веб-ресурсу, перейдите по ссылке ниже:
+> If you want to access the website, follow the link below:
 > 
 > *magic link*
 
-### Этап 3. Поиск имеющихся данных о пользователе
+### Stage 3. Search for available user data
 
-Когда пользователь переходит по ссылке *magic link*, он на самом деле осуществляет GET запрос по [*magic link*] на сервер авторизации oidc. 
-Таким образом, сервер авторизации oidc видит, что пользователь подтвердил, что он разрешает веб-сайту доступ к своим персональным данным.
+When the End-User follows the *magic link*, he is actually sending GET request on [*magic link*] to the oidc authorization server. 
+Thus, the oidc authorization server sees that the End-User has confirmed that he authorizes the website to access his personal data. 
 
-При получении GET запроса по [*magic link*], сервер авторизации oidc создает в базе данных уникальный и никогда непереназначаемый идентификатор, основанный на только что полученных данных `sub+client_id+scope+consent_data`.
+When receiving GET request on [*magic link*], the oidc authorization server creates a unique and never reassignable identifier in the database based on the data it just received `sub+client_id+scope+consent_data`.
 
-Так как одного email не достаточно для корректной работы с веб-сайтом, сервер авторизации oidc постарается запросить у сторонних баз данных (БД) известные сведения о данном пользователе, для этого сервер авторизации oidc отправляет GET запрос по [*email*]. 
+Since one email is not enough to work correctly with the website, the oidc authorization server will try to request the known information about this End-User from third-party databases, for this the oidc authorization server sends a GET request on [*email*]. 
 
-Если на сервер авторизации oidc от какой-либо БД возвращается перечень необходимых сведений о пользователе, то эти данные сохраняются в таблицу User Info и пользователь переадресовывается на адрес веб-сайта, указанный ранее в redirect_uri (см. рисунок 6).
+If a list of necessary End-User information is returned to the oidc authorization server from any database, then this data is saved in the User Info table and the End-User is redirected to the website address specified earlier in redirect_uri (see Figure 6).
 
-### Этап 4. Заполнение формы согласия
+### Stage 4. Filling out the consent form
 
-В случае, если сервер авторизации oidc не получил никакого ответа, после перехода по ссылке *magic link* в письме пользователь видит форму согласия на обработку персональных данных Consent Collection, в которой помимо предзаполненного поля с введенным ранее email, содержатся также дополнительные поля, например: [имя], [фамилия], [место работы] и т.д. 
-Все данные, собранные с помощью данной формы, также сохраняются в таблицу User Info (см. рисунок 6).
+If the oidc authorization server has not received any response, after clicking on the *magic link* in the email, the End-User sees a Consent to Personal Data Processing form, which in addition to the pre-filled field with the previously entered email, also contains additional fields, for example: [first name], [last name], [place of employment], etc.
+All data collected using this form is also saved to the User Info table (see Figure 6).
 
 ```mermaid
 flowchart LR
@@ -139,35 +139,36 @@ E[No]-->FC[/Full Consent/]
 FC[/Full Consent/]-->UI[(User Info)]
 ```
 
-*Рисунок 6. Диаграмма потока данных при сборе данных о пользователе*
+*Figure 6. Data flow diagram for user data collection*
 
-### Этап 5. Выдача JWT
+### Stage 5. JWT generation & delivery
 
-После того, как все необходимые данные о пользователе собраны, сервер авторизации oidc отправляет пользователю следующий ответ, содержащий ссылку на веб-сайт и id_token (JWT - JSON Web Token):
+After all the necessary data about the End-User has been collected, the oidc authorization server sends the following response to the End-User, containing a link to the website and the id_token (JWT - JSON Web Token):
 
 ```
 HTTP/1.1 302 Redirect
 Location: {redirect_uri}?id_token
 ```
 
-При этом id_token (JWT) представляет из себя JSON файл, содержащий информацию, необходимую для аутентификации и проверки достоверности информации и веб-сайт может извлечь из JWT различную информацию, такую как ID, имя пользователя, время входа в учетную запись, срок окончания действия ID Token'а, наличие попыток вмешательства в JWT, например, `sub+email+collected_data+signature`. 
-Signature содержит в себе закрытый ключ, которым сервер авторизации oidc подписывает конкретный JWT. 
+The id_token (JWT) is a JSON file that contains the information needed for authentication and validation, and the website can extract various information from the JWT, such as ID, user name, time of login to the account, expiration date of the ID Token, the presence of tampering attempts in the JWT, for example, `sub+email+collected_data+signature`. 
+Signature contains the private key with which the oidc authorization server signs a particular JWT. 
 
 ```mermaid
 flowchart LR
 OD[oidc]-->|JWT: sub+email+collected_data+signature|A[User]-->|JWT|B(Website)
 ```
-*Рисунок 7. Выдача токена пользователю*
+*Figure 7. JWT delivery*
 
-Чтобы продолжить работу с данными веб-сайт должен проверить подписанный JWT, для этого он обращается к конечной точке jwks_endpoint, с которой может получить открытые ключи для проверки подписи JWT.
+The website must verify the signed JWT to proceed with the data. 
+To do this, it accesses the jwks_endpoint, from which it can obtain public keys to verify the JWT signature.
 
-Цель достигнута. 
-Теперь веб-сайт может использовать id_token (JWT) для получения необходимой информации о пользователе.
+The goal has been achieved. 
+The website can now use the id_token (JWT) to get the necessary information about the End-User.
 
-**ВАЖНО:**
+**ATTENTION:**
 
-1. Все действия пользователь должен осуществлять в одном браузере = с одного устройства. 
-Использование нескольких устройств помешает успешному прохождению авторизации.
-2. На Этапе 2 пользователю можно предложить ввести не email, а, например, номер телефона или оба варианта. 
-Тогда на следующих этапах будет возможность выбрать наиболее удобный способ коммуникации при отправке *magic link*.
-3. На данный момент на сервере авторизации oidc сведения о сессии конкретного пользователя на веб-сайте (cookies) хранятся в течении 30 дней, однако при необходимости данный срок может быть увеличен.
+1. The user must perform all actions in one browser = from one device. 
+Using multiple devices will prevent successful authorization.
+2. In Stage 2, the user can be asked to enter not an email, but, for example, a phone number or both.
+Then, at the next stages, it will be possible to choose the most convenient communication method when sending *magic link *. 
+3. Cookies are currently stored on the oidc authorization server for 30 days, but this period may be extended if necessary.