ps
/
docs
4
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Изменил(а) на 'OpenID_Connect.md'

pull/1/head
Ашотян 2021-11-08 12:45:31 +03:00
parent b8914651c0
commit ed2de71383
1 changed files with 38 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
OpenID_Connect.md
View File

@ -35,13 +35,20 @@
Если никакие данные о пользователе не найдены, веб-сайту необходимо установить личность пользователя.
Для этого веб-сайт перенаправляет пользователя на сервер авторизации oidc и включает в запрос Сlient ID, Redirect Uri, Response Type и одно или несколько Scopes (разрешений), которые ему необходимы (см. рисунок 1).
```mermaid
flowchart LR
A[User]-->|cookies|B(Website)
B--> C{User authorized?}
C--> D[Yes] & E[No]
D--> F[Grant access]
E-->|Client_ID, Redirect_Uri, <br> Response_Type, cookies|G[oidc]
```
*Рисунок 1. Пользователь посещает веб-сайт*
```
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
```
*Рисунок 1. Диаграмма первого шага, когда пользователь заходит на веб-сайт*
Вместе с запросом от веб-сайта сервер авторизации oidc получает cookie-файлы, и на основании полученных данных решает - авторизован данный пользователь или нет.
Если конечный пользователь уже был авторизован, то autorization_endpoint спрашивает у базы данных, было ли получено согласие пользователя для этого веб-сайта.
@ -65,7 +72,17 @@ HTTP/1.1 302 Redirect
Location: {redirect_uri}
```
*Рисунок 2. Диаграмма потока данных, когда пользователь авторизован на веб-ресурсе*
```mermaid
flowchart LR
G[oidc]--> C{User authorized?}
C--> D[Yes] & E[No]
D--> H{Consent<br>obtained?}
H--> I[Yes] & J[No]
I-->B(Website)
J--> K[/Web consent/]--> B(Website)
E-->AF[/Authorization form/]
```
*Рисунок 3. Аутентификация пользователя на сервере авторизации*
Если же сервер решает, что пользователь никогда не был авторизован, то сервер авторизации oidc просит конечного пользователя авторизоваться.
Переходим к этапу 2.
@ -111,6 +128,17 @@ Location: {redirect_uri}
В случае, если сервер авторизации oidc не получил никакого ответа, после перехода по ссылке *magic link* в письме пользователь видит форму согласия на обработку персональных данных Consent Collection, в которой помимо предзаполненного поля с введенным ранее email, содержатся также дополнительные поля, например: [имя], [фамилия], [место работы] и т.д.
Все данные, собранные с помощью данной формы, также сохраняются в таблицу User Info (см. рисунок 6).
```mermaid
flowchart LR
AF[/Authorization form/]-->|Email|G[oidc]
G[oidc]-->|Magic link|em[email]-->OD[odic]-->AD{Any data<br>about User?}
A[User]-->|Click on Magic link|em[Email]
AD--> D[Yes] & E[No]
D-->DB[(Database)]-->FC[/Full Consent/]
E[No]-->FC[/Full Consent/]
FC[/Full Consent/]-->UI[(User Info)]
```
*Рисунок 6. Диаграмма потока данных при сборе данных о пользователе*
### Этап 5. Выдача JWT
@ -125,6 +153,12 @@ Location: {redirect_uri}?id_token
При этом id_token (JWT) представляет из себя JSON файл, содержащий информацию, необходимую для аутентификации и проверки достоверности информации и веб-сайт может извлечь из JWT различную информацию, такую как ID, имя пользователя, время входа в учетную запись, срок окончания действия ID Token'а, наличие попыток вмешательства в JWT, например, `sub+email+collected_data+signature`.
Signature содержит в себе закрытый ключ, которым сервер авторизации oidc подписывает конкретный JWT.
```mermaid
flowchart LR
OD[oidc]-->|JWT: sub+email+collected_data+signature|A[User]-->|JWT|B(Website)
```
*Рисунок 7. Выдача токена пользователю*
Чтобы продолжить работу с данными веб-сайт должен проверить подписанный JWT, для этого он обращается к конечной точке jwks_endpoint, с которой может получить открытые ключи для проверки подписи JWT.
Цель достигнута.