Commit 2e8ae275 authored by Suzanne Selhorn's avatar Suzanne Selhorn

Merge branch 'master' into 'master'

Change future tense to present tense oauth2.md

See merge request gitlab-org/gitlab!60197
parents cbe30081 f864559d
......@@ -41,7 +41,7 @@ how all those flows work and pick the right one for your use case.
Both **authorization code** (with or without PKCE) and **implicit grant** flows require `application` to be
registered first via the `/profile/applications` page in your user's account.
During registration, by enabling proper scopes, you can limit the range of
resources which the `application` can access. Upon creation, you'll obtain the
resources which the `application` can access. Upon creation, you obtain the
`application` credentials: _Application ID_ and _Client Secret_ - **keep them secure**.
### Prevent CSRF attacks
......@@ -63,7 +63,7 @@ and the [OAuth 2.0 Threat Model RFC](https://tools.ietf.org/html/rfc6819#section
These factors are particularly important when using the
[Implicit grant flow](#implicit-grant-flow), where actual credentials are included in the `redirect_uri`.
In the following sections you will find detailed instructions on how to obtain
In the following sections you can find detailed instructions on how to obtain
authorization with each flow.
### Authorization code with Proof Key for Code Exchange (PKCE)
......@@ -213,12 +213,12 @@ To request the access token, you should redirect the user to the
https://gitlab.example.com/oauth/authorize?client_id=APP_ID&redirect_uri=REDIRECT_URI&response_type=token&state=YOUR_UNIQUE_STATE_HASH&scope=REQUESTED_SCOPES
```
This will ask the user to approve the applications access to their account
This prompts the user to approve the applications access to their account
based on the scopes specified in `REQUESTED_SCOPES` and then redirect back to
the `REDIRECT_URI` you provided. The [scope parameter](https://github.com/doorkeeper-gem/doorkeeper/wiki/Using-Scopes#requesting-particular-scopes)
is a space separated list of scopes you want to have access to (e.g. `scope=read_user+profile`
would request `read_user` and `profile` scopes). The redirect
will include a fragment with `access_token` as well as token details in GET
includes a fragment with `access_token` as well as token details in GET
parameters, for example:
```plaintext
......@@ -285,7 +285,7 @@ echo 'grant_type=password&username=<your_username>&password=<your_password>' > a
curl --data "@auth.txt" --user client_id:client_secret --request POST "https://gitlab.example.com/oauth/token"
```
Then, you'll receive the access token back in the response:
Then, you receive a response containing the access token:
```json
{
......@@ -358,7 +358,7 @@ The fields `scopes` and `expires_in_seconds` are included in the response.
These are aliases for `scope` and `expires_in` respectively, and have been included to
prevent breaking changes introduced in [doorkeeper 5.0.2](https://github.com/doorkeeper-gem/doorkeeper/wiki/Migration-from-old-versions#from-4x-to-5x).
Don't rely on these fields as they will be removed in a later release.
Don't rely on these fields as they are slated for removal in a later release.
## OAuth2 tokens and GitLab registries
......
......@@ -79,7 +79,7 @@ Database Lab provides an API we can interact with to manage thin clones. In orde
The short-term focus is on testing regular migrations (typically schema changes) and using the existing Database Lab instance from postgres.ai for it.
In order to secure this process and meet compliance goals, the runner environment will be treated as a *production* environment and similarly locked down, monitored and audited. Only Database Maintainers will have access to the CI pipeline and its job output. Everyone else will only be able to see the results and statistics posted back on the merge request.
In order to secure this process and meet compliance goals, the runner environment is treated as a *production* environment and similarly locked down, monitored and audited. Only Database Maintainers have access to the CI pipeline and its job output. Everyone else can only see the results and statistics posted back on the merge request.
We implement a secured CI pipeline on <https://ops.gitlab.net> that adds the execution steps outlined above. The goal is to secure this pipeline in order to solve the following problem:
......@@ -117,7 +117,7 @@ An alternative approach we have discussed and abandoned is to "scrub" and anonym
- Anonymization is complex by nature - it is a hard problem to call a "scrubbed clone" actually safe to work with in public. Different data types may require different anonymization techniques (e.g. anonymizing sensitive information inside a JSON field) and only focusing on one attribute at a time does not guarantee that a dataset is fully anonymized (for example join attacks or using timestamps in conjunction to public profiles/projects to de-anonymize users by there activity).
- Anonymization requires an additional process to keep track and update the set of attributes considered as sensitive, ongoing maintenance and security reviews every time the database schema changes.
- Annotating data as "sensitive" is error prone, with the wrong anonymization approach used for a data type or one sensitive attribute accidentally not marked as such possibly leading to a data breach.
- Scrubbing not only removes sensitive data, but also changes data distribution, which greatly affects performance of migrations and queries.
- Scrubbing not only removes sensitive data, but it also changes data distribution, which greatly affects performance of migrations and queries.
- Scrubbing heavily changes the database contents, potentially updating a lot of data, which leads to different data storage details (think MVC bloat), affecting performance of migrations and queries.
## Who
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment