Восстановление файла с правками
Арина Ашотян
parent
75e4a2ce2e
commit
81ad1b4a54
|
|
@ -0,0 +1,313 @@
|
|||
# OpenID Connect
|
||||
|
||||
## Table of contents
|
||||
|
||||
**[Introduction](#Introduction)**
|
||||
|
||||
**[Scheme of the OpenID Connect Core 1.0 protocol work](#Scheme-of-the-OpenID-Connect-Core-1.0-protocol-work)**
|
||||
|
||||
**Steps:**
|
||||
|
||||
**[Visiting a foreign website](#Visiting-a-foreign-website)**
|
||||
|
||||
**[Authentication](#Authentication)**
|
||||
|
||||
**[](#)**
|
||||
|
||||
**[](#)**
|
||||
|
||||
**[](#)**
|
||||
|
||||
**[](#)**
|
||||
|
||||
**[](#)**
|
||||
|
||||
## 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.
|
||||
|
||||
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.
|
||||
|
||||
Also, within the framework of the system, a [Staging](https://staging.ps.radium-it.ru/.well-known/openid-configuration) environment configuration is deployed, within which it is possible to test the operation of the OpenID Connect authorization server.
|
||||
|
||||
It is important to note that the address of the Production server will be different from the Staging environment.
|
||||
By default, production server is located under https://client.ps.radium-it.ru.
|
||||
To customize a web address of the oidc authorization server, for example, https://privacy.client.ru or you need to add a CNAME Record to your DNS server.
|
||||
|
||||
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://openid.net/specs/openid-connect-core-1_0.html#RFC6749).
|
||||
|
||||
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.
|
||||
|
||||
## Scheme of the OpenID Connect Core 1.0 protocol work
|
||||
<<<<<<< HEAD
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
VW[Visiting a foreign website]--> GA(Grant Access) & SA[Authentication]
|
||||
SA--> AT{User authenticated?}
|
||||
AT--> Y(Yes) & N(No)
|
||||
Y--> CO{Consent obtained?}
|
||||
CO--> Y2(Yes) & N2(No)
|
||||
Y2--> RU[/redirect_uri/]
|
||||
N--> AZ[Authorization]
|
||||
N2--> AZ[Authorization]
|
||||
AZ--> CF[Consent form] & RF[Registration form]
|
||||
CF--> RU[/redirect_uri/]
|
||||
RF--> CD[Check for available data]
|
||||
CD--> AD{Any data?}
|
||||
AD--> Y3[Yes] & N3[No]
|
||||
Y3--> RU[/redirect_uri/]
|
||||
N3-->|magic link| WF[Website form]
|
||||
WF--> RU[/redirect_uri/]
|
||||
```
|
||||
=======
|
||||
### Stage 1. Visiting a foreign website
|
||||
|
||||
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 a request from the user for the presence of cookies.
|
||||
|
||||
If a cookie determines that the End-User has already visited the website, access is granted.
|
||||
>>>>>>> e5f76a9e429d74ea55422540654512b7ab950d32
|
||||
|
||||
### Visiting a foreign website
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[User]-->B(Website)
|
||||
B--> C{User is authenticated?}
|
||||
C--> D[Yes] & E[No]
|
||||
D--> F[Grant access]
|
||||
<<<<<<< HEAD
|
||||
E-->|redirect|G[oidc]
|
||||
=======
|
||||
E-->|redirection|G[oidc]
|
||||
>>>>>>> e5f76a9e429d74ea55422540654512b7ab950d32
|
||||
```
|
||||
*Figure 1. End-User visits website*
|
||||
|
||||
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 a request from the user for the presence of cookies.
|
||||
|
||||
An example of GET-request from the user:
|
||||
|
||||
```
|
||||
GET https://www.foreign_website//
|
||||
```
|
||||
If a cookie determines that the End-User has already visited the website, access is granted.
|
||||
|
||||
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.
|
||||
|
||||
An example of HTTP 302 redirect response:
|
||||
|
||||
```
|
||||
HTTP/1.1 302 Found
|
||||
Location: https://{OIDC server}/oidc/authorize?scope=openid&redirect_uri={Redirect URI}&client_id={Client ID}&response_type=id_token"
|
||||
```
|
||||
An example of Browser - Website communication is presented in figure 2.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
BROWSER ->> WEBSITE: GET https://www.foreign_website//
|
||||
WEBSITE ->> BROWSER: HTTP/1.1 302 Found <br/> Location: https://{OIDC server}/oidc/authorize?<br/>?scope=openid&redirect_uri={Redirect URI}&client_id={Client ID}&response_type=id_token"
|
||||
```
|
||||
*Figure 2. Browser - Website communication*
|
||||
|
||||
### Authentication
|
||||
|
||||
#### NOTE: The system only supports [Implicit Flow](https://openid.net/specs/openid-connect-core-1_0-final.html#ImplicitFlowAuth)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
G[oidc]--> C{User authenticated?}
|
||||
C--> D[Yes] & E[No]
|
||||
D--> H{Consent<br>obtained?}
|
||||
H--> I[Yes] & J[No]
|
||||
I-->B[/redirect_uri/]
|
||||
J--> K[/Web consent/]--> B[/redirect_uri/]
|
||||
E-->RF[Registration form]
|
||||
```
|
||||
<<<<<<< HEAD
|
||||
*Figure 3. End-User authentication on oidc authorization server*
|
||||
|
||||
If the user has already been in contact with the authorization server, browser sends the existing cookies to the authorization server along with the request.
|
||||
The oidc authorization server receives cookies along with the request from the website, and based on this data decides whether the End-User is authenticated or not.
|
||||
|
||||
If the End-User has already been authenticated, Authorization Endpoint asks the database if the End-User's consent has been obtained for that website.
|
||||
|
||||
If consent for this site has already been given by the End-User, the oidc authorization server redirects the End-User to the address that was specified in the redirect_uri.
|
||||
|
||||
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.
|
||||
|
||||
### Authorization
|
||||
|
||||
#### Consent form
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
AT{User authenticated?}--> Y(Yes) & N(No)
|
||||
Y--> CO{Consent obtained?}
|
||||
CO--> Y2(Yes) & N2(No)
|
||||
Y2--> RU[/redirect_uri/]
|
||||
N2--> AZ[Authorization]
|
||||
N--> AZ[Authorization]
|
||||
AZ--> CF[Consent form]
|
||||
CF-->|Click on 'submit' button| CP[Consent to PD processing]-.-> DB[(sub+client_id+<br/>+date+scope)]
|
||||
CP--> RU[/redirect_uri/]
|
||||
AZ--> RF[Registration form]
|
||||
```
|
||||
|
||||
*Figure 4.*
|
||||
=======
|
||||
HTTP/2 301 Moved Permanently
|
||||
Location: https://{OIDC server}/oidc/authorize?scope=openid&redirect_uri={Redirect URI}&client_id={Client ID}&response_type=id_token"
|
||||
```
|
||||
|
||||
### Stage 2. Redirecting to OIDC server
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
>>>>>>> e5f76a9e429d74ea55422540654512b7ab950d32
|
||||
|
||||
On the page with the Consent form the End-User sees a form with the following text **(An example demo will be presented later)**:
|
||||
|
||||
> The example.client.ru requests access to your data: ID, email
|
||||
>
|
||||
> Allow data access?
|
||||
>
|
||||
> [X] Consent
|
||||
>
|
||||
> [Submit]
|
||||
|
||||
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 4).
|
||||
|
||||
An example of HTTP 302 redirect response:
|
||||
|
||||
```
|
||||
HTTP/1.1 302 Redirect
|
||||
Location: {redirect_uri}
|
||||
```
|
||||
|
||||
If the authorization server decides that the End-User has never been authorized, then the oidc authorization server asks the end user to authorize via Registration form.
|
||||
|
||||
#### Registration form
|
||||
|
||||
Visiting Consent page & entering primary data
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
AZ[Authorization]--> CF[Consent form]
|
||||
AZ-->|Enter email| RF[Registration form]--> CB[User clicks on checkbox & 'submit' button]
|
||||
CB-->AS[oidc]
|
||||
AS-->|magic link| EA[Email]
|
||||
EA--> WF[Website Form]
|
||||
AS-.-> CAD[Check for available data]
|
||||
CAD-->AD{Any data?}
|
||||
AD--> Y[Yes] & N[No]
|
||||
Y--> RU[/redirect_uri/]
|
||||
N--> EA[Email]
|
||||
|
||||
```
|
||||
|
||||
*Figure 5.*
|
||||
|
||||
The oidc authorization server displays a Registration 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 **(An example demo will be presented later)**:
|
||||
|
||||
> The example.client.ru requests access to your data: ID, email.
|
||||
>
|
||||
> If you allow access to the data, enter the data in the marked fields and click [Submit]
|
||||
>
|
||||
> [] Consent
|
||||
>
|
||||
> | Enter your 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.
|
||||
|
||||
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 **(An example demo will be presented later)**:
|
||||
|
||||
> Thank you for your submission, please check your email.
|
||||
|
||||
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 **(An example demo will be presented later)**:
|
||||
|
||||
> If you want to access the website, follow the link below:
|
||||
>
|
||||
> *magic link*
|
||||
|
||||
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.
|
||||
|
||||
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`.
|
||||
|
||||
#### Search for available user data
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
CAD[Check for available data]
|
||||
CAD-->AD{Any data?}
|
||||
AD<-.-> DB[(DB)]
|
||||
AD--> Y[Yes] & N[No]
|
||||
Y--> RU[/redirect_uri/]
|
||||
N--> EA[Email]
|
||||
EA--> WF[Website Form]
|
||||
```
|
||||
|
||||
*Figure 6.*
|
||||
|
||||
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*].
|
||||
|
||||
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 7).
|
||||
|
||||
#### Filling out the Website form
|
||||
|
||||
If the oidc authorization server has not received any response from databases, after clicking on the *magic link* in the email, the End-User sees a Website 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 7).
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
WC[Website consent]-->UI[(User Info)]
|
||||
```
|
||||
|
||||
*Figure 7. Data flow diagram for user data collection*
|
||||
|
||||
#### JWT generation & delivery
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
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` (see Figure 8).
|
||||
Signature contains the private key with which the oidc authorization server signs a particular JWT.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
OD[oidc]-->|JWT|A[User]-->|JWT|B(Website)
|
||||
```
|
||||
*Figure 8. JWT delivery*
|
||||
|
||||
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.
|
||||
|
||||
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. 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.
|
||||
|
|
@ -0,0 +1,287 @@
|
|||
# OpenID Connect
|
||||
|
||||
## Table of contents
|
||||
|
||||
**[Introduction](#Introduction)**
|
||||
|
||||
**[Scheme of the OpenID Connect Core 1.0 protocol work](#Scheme-of-the-OpenID-Connect-Core-1.0-protocol-work)**
|
||||
|
||||
**Steps:**
|
||||
|
||||
**[Visiting a foreign website](#Visiting-a-foreign-website)**
|
||||
|
||||
**[Authentication](#Authentication)**
|
||||
|
||||
**[](#)**
|
||||
|
||||
**[](#)**
|
||||
|
||||
**[](#)**
|
||||
|
||||
**[](#)**
|
||||
|
||||
**[](#)**
|
||||
|
||||
## 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.
|
||||
|
||||
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.
|
||||
|
||||
Also, within the framework of the system, a [Staging](https://staging.ps.radium-it.ru/.well-known/openid-configuration) environment configuration is deployed, within which it is possible to test the operation of the OpenID Connect authorization server.
|
||||
|
||||
It is important to note that the address of the Production server will be different from the Staging environment.
|
||||
By default, production server is located under https://client.ps.radium-it.ru.
|
||||
To customize a web address of the oidc authorization server, for example, https://privacy.client.ru or you need to add a CNAME Record to your DNS server.
|
||||
|
||||
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://openid.net/specs/openid-connect-core-1_0.html#RFC6749).
|
||||
|
||||
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.
|
||||
|
||||
## Scheme of the OpenID Connect Core 1.0 protocol work
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
VW[Visiting a foreign website]--> GA(Grant Access) & SA[Authentication]
|
||||
SA--> AT{User authenticated?}
|
||||
AT--> Y(Yes) & N(No)
|
||||
Y--> CO{Consent obtained?}
|
||||
CO--> Y2(Yes) & N2(No)
|
||||
Y2--> RU[/redirect_uri/]
|
||||
N--> AZ[Authorization]
|
||||
N2--> AZ[Authorization]
|
||||
AZ--> CF[Consent form] & RF[Registration form]
|
||||
CF--> RU[/redirect_uri/]
|
||||
RF--> CD[Check for available data]
|
||||
CD--> AD{Any data?}
|
||||
AD--> Y3[Yes] & N3[No]
|
||||
Y3--> RU[/redirect_uri/]
|
||||
N3-->|magic link| WF[Website form]
|
||||
WF--> RU[/redirect_uri/]
|
||||
```
|
||||
|
||||
### Visiting a foreign website
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[User]-->B(Website)
|
||||
B--> C{User is authenticated?}
|
||||
C--> D[Yes] & E[No]
|
||||
D--> F[Grant access]
|
||||
E-->|redirect|G[oidc]
|
||||
```
|
||||
*Figure 1. End-User visits website*
|
||||
|
||||
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 a request from the user for the presence of cookies.
|
||||
|
||||
An example of GET-request from the user:
|
||||
|
||||
```
|
||||
GET https://www.foreign_website//
|
||||
```
|
||||
If a cookie determines that the End-User has already visited the website, access is granted.
|
||||
|
||||
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.
|
||||
|
||||
An example of HTTP 302 redirect response:
|
||||
|
||||
```
|
||||
HTTP/1.1 302 Found
|
||||
Location: https://{OIDC server}/oidc/authorize?scope=openid&redirect_uri={Redirect URI}&client_id={Client ID}&response_type=id_token"
|
||||
```
|
||||
An example of Browser - Website communication is presented in figure 2.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
BROWSER ->> WEBSITE: GET https://www.foreign_website//
|
||||
WEBSITE ->> BROWSER: HTTP/1.1 302 Found <br/> Location: https://{OIDC server}/oidc/authorize?<br/>?scope=openid&redirect_uri={Redirect URI}&client_id={Client ID}&response_type=id_token"
|
||||
```
|
||||
*Figure 2. Browser - Website communication*
|
||||
|
||||
### Authentication
|
||||
|
||||
#### NOTE: The system only supports [Implicit Flow](https://openid.net/specs/openid-connect-core-1_0-final.html#ImplicitFlowAuth)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
G[oidc]--> C{User authenticated?}
|
||||
C--> D[Yes] & E[No]
|
||||
D--> H{Consent<br>obtained?}
|
||||
H--> I[Yes] & J[No]
|
||||
I-->B[/redirect_uri/]
|
||||
J--> K[/Web consent/]--> B[/redirect_uri/]
|
||||
E-->RF[Registration form]
|
||||
```
|
||||
*Figure 3. End-User authentication on oidc authorization server*
|
||||
|
||||
If the user has already been in contact with the authorization server, browser sends the existing cookies to the authorization server along with the request.
|
||||
The oidc authorization server receives cookies along with the request from the website, and based on this data decides whether the End-User is authenticated or not.
|
||||
|
||||
If the End-User has already been authenticated, Authorization Endpoint asks the database if the End-User's consent has been obtained for that website.
|
||||
|
||||
If consent for this site has already been given by the End-User, the oidc authorization server redirects the End-User to the address that was specified in the redirect_uri.
|
||||
|
||||
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.
|
||||
|
||||
### Authorization
|
||||
|
||||
#### Consent form
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
AT{User authenticated?}--> Y(Yes) & N(No)
|
||||
Y--> CO{Consent obtained?}
|
||||
CO--> Y2(Yes) & N2(No)
|
||||
Y2--> RU[/redirect_uri/]
|
||||
N2--> AZ[Authorization]
|
||||
N--> AZ[Authorization]
|
||||
AZ--> CF[Consent form]
|
||||
CF-->|Click on 'submit' button| CP[Consent to PD processing]-.-> DB[(sub+client_id+<br/>+date+scope)]
|
||||
CP--> RU[/redirect_uri/]
|
||||
AZ--> RF[Registration form]
|
||||
```
|
||||
|
||||
*Figure 4.*
|
||||
|
||||
On the page with the Consent form the End-User sees a form with the following text **(An example demo will be presented later)**:
|
||||
|
||||
> The example.client.ru requests access to your data: ID, email
|
||||
>
|
||||
> Allow data access?
|
||||
>
|
||||
> [X] Consent
|
||||
>
|
||||
> [Submit]
|
||||
|
||||
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 4).
|
||||
|
||||
An example of HTTP 302 redirect response:
|
||||
|
||||
```
|
||||
HTTP/1.1 302 Redirect
|
||||
Location: {redirect_uri}
|
||||
```
|
||||
|
||||
If the authorization server decides that the End-User has never been authorized, then the oidc authorization server asks the end user to authorize via Registration form.
|
||||
|
||||
#### Registration form
|
||||
|
||||
Visiting Consent page & entering primary data
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
AZ[Authorization]--> CF[Consent form]
|
||||
AZ-->|Enter email| RF[Registration form]--> CB[User clicks on checkbox & 'submit' button]
|
||||
CB-->AS[oidc]
|
||||
AS-->|magic link| EA[Email]
|
||||
EA--> WF[Website Form]
|
||||
AS-.-> CAD[Check for available data]
|
||||
CAD-->AD{Any data?}
|
||||
AD--> Y[Yes] & N[No]
|
||||
Y--> RU[/redirect_uri/]
|
||||
N--> EA[Email]
|
||||
|
||||
```
|
||||
|
||||
*Figure 5.*
|
||||
|
||||
The oidc authorization server displays a Registration 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 **(An example demo will be presented later)**:
|
||||
|
||||
> The example.client.ru requests access to your data: ID, email.
|
||||
>
|
||||
> If you allow access to the data, enter the data in the marked fields and click [Submit]
|
||||
>
|
||||
> [] Consent
|
||||
>
|
||||
> | Enter your 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.
|
||||
|
||||
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 **(An example demo will be presented later)**:
|
||||
|
||||
> Thank you for your submission, please check your email.
|
||||
|
||||
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 **(An example demo will be presented later)**:
|
||||
|
||||
> If you want to access the website, follow the link below:
|
||||
>
|
||||
> *magic link*
|
||||
|
||||
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.
|
||||
|
||||
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`.
|
||||
|
||||
#### Search for available user data
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
CAD[Check for available data]
|
||||
CAD-->AD{Any data?}
|
||||
AD<-.-> DB[(DB)]
|
||||
AD--> Y[Yes] & N[No]
|
||||
Y--> RU[/redirect_uri/]
|
||||
N--> EA[Email]
|
||||
EA--> WF[Website Form]
|
||||
```
|
||||
|
||||
*Figure 6.*
|
||||
|
||||
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*].
|
||||
|
||||
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 7).
|
||||
|
||||
#### Filling out the Website form
|
||||
|
||||
If the oidc authorization server has not received any response from databases, after clicking on the *magic link* in the email, the End-User sees a Website 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 7).
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
WC[Website consent]-->UI[(User Info)]
|
||||
```
|
||||
|
||||
*Figure 7. Data flow diagram for user data collection*
|
||||
|
||||
### JWT generation & delivery
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
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` (see Figure 8).
|
||||
Signature contains the private key with which the oidc authorization server signs a particular JWT.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
OD[oidc]-->|JWT|A[User]-->|JWT|B(Website)
|
||||
```
|
||||
*Figure 8. JWT delivery*
|
||||
|
||||
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.
|
||||
|
||||
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. 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.
|
||||
Loading…
Reference in New Issue