Simplification of the structure
Касимов
parent
9dd69adf40
commit
52ad95234f
163
oidc.md
163
oidc.md
|
|
@ -3,9 +3,7 @@
|
|||
## 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:
|
||||
|
||||
* [Authorization flow](#Authorization-flow)
|
||||
* [Visiting target website](#Visiting-target-website)
|
||||
* [Authentication](#Authentication-Authorization)
|
||||
* [JWT generation, delivery & validation](JWT-generation,-delivery-&-validation)
|
||||
|
|
@ -34,15 +32,12 @@ All the necessary information regarding the configuration is available [here](ht
|
|||
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.
|
||||
|
||||
## Work flow
|
||||
## Authorization flow
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
actor Visitor
|
||||
participant Website
|
||||
participant OIDC
|
||||
Visitor->>Website: Sign me inkk
|
||||
Visitor->>Website: Sign me in
|
||||
Website->>Visitor: Obtain token from OIDC
|
||||
Visitor->>OIDC: Authorize website
|
||||
OIDC->>Visitor: Token for Website
|
||||
|
|
@ -52,7 +47,7 @@ sequenceDiagram
|
|||
Website-)Visitor: Signed in
|
||||
```
|
||||
|
||||
### Visiting a website
|
||||
### Visiting target website
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
|
|
@ -81,9 +76,9 @@ 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"
|
||||
```
|
||||
|
||||
### Authentication & athorization
|
||||
### Authentication & authorization
|
||||
|
||||
NOTE: The system currently only supports [Implicit Flow](https://openid.net/specs/openid-connect-core-1_0-final.html#ImplicitFlowAuth)
|
||||
NOTE: The system currently supports only [Implicit Flow](https://openid.net/specs/openid-connect-core-1_0-final.html#ImplicitFlowAuth)
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
|
|
@ -129,140 +124,26 @@ The Authorization Server will attempt to authenticate the User in the following
|
|||
|
||||
More information can be found [here](https://openid.net/specs/openid-connect-core-1_0-final.html#Authenticates)
|
||||
|
||||
### 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]
|
||||
```
|
||||
|
||||
On the page with the Consent form the 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 User clicks [Submit], Consent is written to the 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 Found
|
||||
Location: {redirect_uri}#
|
||||
&id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
|
||||
&state=af0ifjsldkj
|
||||
```
|
||||
|
||||
If the Authorization Server decides that the User has never been authorized, then the oidc Authorization Server asks the end user to authorize via Registration form.
|
||||
|
||||
#### Registration form
|
||||
|
||||
```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. Start of authorization via registration form*
|
||||
|
||||
The oidc Authorization Server displays a Registration form listing all the Scopes requested by the Website.
|
||||
On the page the 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 User also ticks the checkbox, thereby confirming his consent to the processing of personal data.
|
||||
|
||||
After the 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 User clicks [Submit], a request is sent to the oidc Authorization Server to send a *magic link* to the 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 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 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. Search for available User data*
|
||||
|
||||
Since one email is not enough to work correctly with the Website, the oidc Authorization Server will attempt to request the known information about the User with this email from the local or, if necessary, third-party databases.
|
||||
For this the oidc Authorization Server sends a GET request on [*email*].
|
||||
|
||||
If a list of necessary User information is returned to the oidc Authorization Server from any database, then this data is saved in the User Info table and the User is redirected to the Website address specified earlier in `redirect_uri` (see Figure 7).
|
||||
|
||||
#### Filling out the Website form
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
U[User]-->|PD input| WF[Website form]
|
||||
WF-.->UI[(User Info)]
|
||||
WF-->RU[/redirect_uri/]
|
||||
```
|
||||
|
||||
*Figure 7. Data flow diagram for user data collection*
|
||||
|
||||
If the oidc Authorization Server has not received any response from databases, after clicking on the *magic link* in the email, the User sees a Website 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).
|
||||
|
||||
**NOTE:** Registration form and Website form are the same pages but with the different content depending on the situation.
|
||||
|
||||
### JWT generation, delivery & validation
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
|
||||
OD[oidc]-->|JWT|A[User]-->|JWT|B[/redirect_uri/]
|
||||
B-->|Decoding JWT|JW[/jwks_endpoint/]
|
||||
JW-.->CH[Check public & private keys]-->S(Successful)
|
||||
S-->GA(Goal achieved)
|
||||
flowchart TB
|
||||
OP[OIDC]-->R[/Make redirect URI/]
|
||||
JWKS[JWKS]
|
||||
subgraph Token generation
|
||||
U[(Database)] -->|Claims| TS
|
||||
TS[/sign/] --> T[Token]
|
||||
end
|
||||
subgraph Token usage
|
||||
W[Website] --> TT[/Take token from<br>#fragment or <br>?query/]
|
||||
TT --> TP[Verify token]
|
||||
TP -->|user authenticated| TU(Use token)
|
||||
end
|
||||
T -.-> R
|
||||
JWKS -.->|private key| TS
|
||||
JWKS -.->|public key| TP
|
||||
R -->|redirect user| W
|
||||
```
|
||||
*Figure 8. JWT generation, delivery & validation*
|
||||
|
||||
After all the necessary data about the User has been collected, the oidc Authorization Server sends the following response to the User, containing a link to the website and the `id_token` (JWT - JSON Web Token):
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue