Minor text improvements
parent
9e0fc332c6
commit
6a8b2d253e
GPG Key ID:
CC3C1E3EA2534D0C
74
oidc.md
74
oidc.md
|
|
@ -2,27 +2,18 @@
|
|||
|
||||
## Table of contents
|
||||
|
||||
**[Introduction](#Introduction)**
|
||||
* [Introduction](#Introduction)
|
||||
* [Scheme of the OpenID Connect Core 1.0 protocol work](#Scheme-of-the-OpenID-Connect-Core-1.0-protocol-work)
|
||||
* Steps:
|
||||
|
||||
**[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)**
|
||||
|
||||
**[Authorization](#Authorization)**
|
||||
|
||||
**[- Consent form](#Consent-form)**
|
||||
|
||||
**[- Registration form](#Registration-form)**
|
||||
|
||||
**[- Search for available user data](#Search-for-available-user-data)**
|
||||
|
||||
**[- Filling out the Website form](#Filling-out-the-Website-form)**
|
||||
|
||||
**[JWT generation, delivery & validation](JWT-generation,-delivery-&-validation)**
|
||||
* [Visiting a foreign website](#Visiting-a-foreign-website)
|
||||
* [Authentication](#Authentication)
|
||||
* [Authorization](#Authorization)
|
||||
* [Consent form](#Consent-form)
|
||||
* [Registration form](#Registration-form)
|
||||
* [Search for available user data](#Search-for-available-user-data)
|
||||
* [Filling out the Website form](#Filling-out-the-Website-form)
|
||||
* [JWT generation, delivery & validation](JWT-generation,-delivery-&-validation)
|
||||
|
||||
## Introduction
|
||||
|
||||
|
|
@ -89,12 +80,12 @@ The check is carried out by analyzing a request from the user for the presence o
|
|||
An example of GET-request from the user:
|
||||
|
||||
```
|
||||
GET https://www.foreign_website//
|
||||
GET https://www.client.com/
|
||||
```
|
||||
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 `client_id`, `redirect_uri`, `response type` and one or more `scopes` (permissions), that it needs.
|
||||
To do this, the Website redirects the End-User to the oidc Authorization Server and includes in the request `client_id`, `redirect_uri`, `response_type` and one or more `scopes` (permissions), that it needs.
|
||||
|
||||
**NOTE:**
|
||||
|
||||
|
|
@ -131,7 +122,7 @@ E-->RF[Registration form]
|
|||
```
|
||||
*Figure 3. End-User authentication on oidc Authorization Server*
|
||||
|
||||
If the user has already been in contact with the oidc Authorization Server, browser sends the existing cookies to the oidc Authorization Server along with the request.
|
||||
If the user has already been in contact with the oidc Authorization Server, browser sends the existing cookies to the oidc Authorization Server along with the request.
|
||||
|
||||
The following is a non-normative example request using the Implicit Flow that would be sent by the Browser to the oidc Authorization Server in response to a corresponding HTTP 302 redirect response by the Website:
|
||||
|
||||
|
|
@ -169,7 +160,6 @@ The authentication request contains the `prompt` parameter with the value `none`
|
|||
More information can be found [here](https://openid.net/specs/openid-connect-core-1_0-final.html#Authenticates)
|
||||
|
||||
### Authorization
|
||||
|
||||
#### Consent form
|
||||
|
||||
```mermaid
|
||||
|
|
@ -185,7 +175,6 @@ CF-->|Click on 'submit' button| CP[Consent to PD processing]-.-> DB[(sub+client_
|
|||
CP--> RU[/redirect_uri/]
|
||||
AZ--> RF[Registration form]
|
||||
```
|
||||
|
||||
*Figure 4. General authorization scheme*
|
||||
|
||||
On the page with the Consent form the End-User sees a form with the following text (An example demo will be presented later):
|
||||
|
|
@ -198,20 +187,13 @@ On the page with the Consent form the End-User sees a form with the following te
|
|||
>
|
||||
> [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).
|
||||
As soon as the End-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 Redirect
|
||||
Location: {redirect_uri}
|
||||
```
|
||||
|
||||
**ПРИМЕР ответа из спецификации: Какой оставить?**
|
||||
|
||||
```
|
||||
HTTP/1.1 302 Found
|
||||
Location: https://client.example.org/cb#
|
||||
Location: {redirect_uri}#
|
||||
access_token=SlAV32hkKG
|
||||
&token_type=bearer
|
||||
&id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
|
||||
|
|
@ -219,7 +201,7 @@ access_token=SlAV32hkKG
|
|||
&state=af0ifjsldkj
|
||||
```
|
||||
|
||||
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.
|
||||
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
|
||||
|
||||
|
|
@ -263,8 +245,8 @@ When the End-User clicks [Submit], a request is sent to the oidc Authorization S
|
|||
>
|
||||
> *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 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`.
|
||||
|
||||
|
|
@ -284,7 +266,7 @@ EA--> WF[Website Form]
|
|||
*Figure 6. Search for available End-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 End-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*].
|
||||
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).
|
||||
|
||||
|
|
@ -323,24 +305,24 @@ 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`.
|
||||
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`.
|
||||
|
||||
More information on `id_token` data structure can be found [here](https://openid.net/specs/openid-connect-core-1_0-final.html#IDToken).
|
||||
|
||||
Signature contains the private key with which the oidc Authorization Server signs a particular JWT.
|
||||
Signature contains the private key with which the oidc Authorization Server signs a particular JWT.
|
||||
The private key used to sign the JWT content must be associated with a public key used for signature verification published by the sender in its `jwks_endpoint` (JWK Set document).
|
||||
|
||||
The website must [validate](https://openid.net/specs/openid-connect-core-1_0-final.html#IDTokenValidation) the JWT in the Token Response to proceed with the data.
|
||||
The website must [validate](https://openid.net/specs/openid-connect-core-1_0-final.html#IDTokenValidation) the JWT in the Token Response 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 achieved.
|
||||
The goal achieved.
|
||||
|
||||
The website can now use the 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.
|
||||
1. The user must perform all actions in one browser = from one device.
|
||||
Using multiple devices may 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.
|
||||
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