Добавлены диаграммы, изменены разделы
Арина Ашотян
parent
237caaef79
commit
17adbaf719
|
|
@ -1,5 +1,27 @@
|
|||
# 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.
|
||||
|
|
@ -9,52 +31,129 @@ The solution to this problem is to use a server located on the territory of the
|
|||
|
||||
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.
|
||||
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 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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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
|
||||
|
||||
### Stage 1. Visiting a foreign website
|
||||
```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/]
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
If a cookie determines that the End-User has already visited the website, access is granted `grant access`.
|
||||
|
||||
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).
|
||||
### Visiting a foreign website
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[User]-->|cookies|B(Website)
|
||||
B--> C{User authorized?}
|
||||
A[User]-->B(Website)
|
||||
B--> C{User is authenticated?}
|
||||
C--> D[Yes] & E[No]
|
||||
D--> F[Grant access]
|
||||
E-->|Client_ID, Redirect_Uri, <br> Response_Type, cookies|G[oidc]
|
||||
E-->|redirect|G[oidc]
|
||||
```
|
||||
*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
|
||||
```
|
||||
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.
|
||||
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 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.
|
||||
An example of GET-request from the user:
|
||||
|
||||
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, see Figure 2)**:
|
||||
```
|
||||
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
|
||||
>
|
||||
|
|
@ -64,34 +163,40 @@ On the page the End-User sees a form to fill out the data and the following text
|
|||
>
|
||||
> [Submit]
|
||||
|
||||
*Figure 2.*
|
||||
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).
|
||||
|
||||
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).
|
||||
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
|
||||
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/]
|
||||
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 3. End-User authentication on oidc authorization server*
|
||||
|
||||
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.
|
||||
*Figure 5.*
|
||||
|
||||
### Stage 2. Visiting Consent page & entering primary data
|
||||
|
||||
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 **(An example demo will be presented later, Figure 4)**:
|
||||
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.
|
||||
>
|
||||
|
|
@ -101,54 +206,55 @@ On the page the End-User sees a form to fill out the data and the following text
|
|||
>
|
||||
> | Enter your email |
|
||||
|
||||
*Figure 4.*
|
||||
|
||||
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, Figure 5)**:
|
||||
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.
|
||||
|
||||
*Figure 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 **(An example demo will be presented later, Figure 6)**:
|
||||
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*
|
||||
|
||||
*Figure 6.*
|
||||
|
||||
### Stage 3. Search for available user data
|
||||
|
||||
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).
|
||||
|
||||
### Stage 4. Filling out the consent form
|
||||
#### Filling out the Website form
|
||||
|
||||
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.
|
||||
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
|
||||
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)]
|
||||
WC[Website consent]-->UI[(User Info)]
|
||||
```
|
||||
|
||||
*Figure 7. Data flow diagram for user data collection*
|
||||
|
||||
### Stage 5. JWT generation & delivery
|
||||
### 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):
|
||||
|
||||
|
|
@ -162,7 +268,7 @@ Signature contains the private key with which the oidc authorization server sign
|
|||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
OD[oidc]-->|JWT: sub+email+collected_data+signature|A[User]-->|JWT|B(Website)
|
||||
OD[oidc]-->|JWT|A[User]-->|JWT|B(Website)
|
||||
```
|
||||
*Figure 8. JWT delivery*
|
||||
|
||||
|
|
@ -178,4 +284,4 @@ The website can now use the id_token (JWT) to get the necessary information abou
|
|||
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.
|
||||
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