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

Fixing some mistakes

master
Антон Касимов 2021-11-10 15:24:26 +03:00
parent 237caaef79
commit 812ccdbb84
Signed by: toxa
GPG Key ID: CC3C1E3EA2534D0C
1 changed files with 15 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
OpenID_Connect.md
View File

@ -9,28 +9,28 @@ 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
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.
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 `grant access`.
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 (see Figure 1).
@ -41,18 +41,21 @@ flowchart LR
B--> C{User authorized?}
C--> D[Yes] & E[No]
D--> F[Grant access]
E-->|Client_ID, Redirect_Uri, <br> Response_Type, cookies|G[oidc]
E-->|redirection|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
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.
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.
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)**:
@ -178,4 +181,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.