matrix/authentication-service
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-authentication-service.git synced 2025-08-01 20:26:56 +03:00
Code Activity

Apply typos corrections from review

Browse Source 
Co-authored-by: Will Lewis <1543626+wrjlewis@users.noreply.github.com>
This commit is contained in:
Quentin Gliech
2024-05-03 17:42:12 +02:00
parent 0c2305ad6f
commit f3b481f4ae
5 changed files with 13 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
docs/topics/authorization.md
View File

@ -1,7 +1,7 @@
# Authorization and sessions
The main job of the authentication service is to grant access to resources to clients, and to lets resources know who is accessing them.
In less abstract terms, this means that the service is responsible for issuing access token and let the homeserver (and other services) introspect those access tokens.
The main job of the authentication service is to grant access to resources to clients, and to let resources know who is accessing them.
In less abstract terms, this means that the service is responsible for issuing access tokens and letting the homeserver (and other services) introspect those access tokens.
## How access tokens work
@ -13,7 +13,7 @@ An access token has:
- a client for which the token is issued
- a timeframe for which the token is valid
On a single token, those metadata are immutable: they don't change over time.
On a single token, metadata is immutable: it doesn't change over time.
One exception is the validity of the token: the service may revoke a token before its expiration date.
A typical client will get a short-lived access token (valid 5 minutes) along with a refresh token.
@ -34,7 +34,7 @@ Out of this request, Synapse will care about the following:
- [`urn:matrix:org.matrix.msc2967.client:device:AABBCC`], which encodes the Matrix device ID used by the client
- [`urn:synapse:admin:*`], which grants access to the Synapse admin API
It's important to understand that when Synapse delegates the authentication to MAS, a lot of user attributes are not managed by Synapse anymore.
It's important to understand that when Synapse delegates authentication to MAS, Synapse no longer manages many user attributes.
This includes the user admin, locked, and deactivated status.
## Compatibility sessions
@ -57,7 +57,7 @@ This was the case in the past with Synapse, as the admin status was set on the u
## OAuth 2.0 sessions
Modern clients are expected to use OAuth 2.0 to authenticate with the homeserver.
In OAuth 2.0/OIDC, there are multiple way to start an OAuth 2.0 session called grants.
In OAuth 2.0/OIDC, there are multiple ways to start an OAuth 2.0 session called grants.
An OAuth 2.0 session has three important properties:

2
docs/topics/policy.md
View File

@ -32,7 +32,7 @@ The policy is evaluated in three different scenarios:
### Client registration
The policy ([`client_registration.rego`]) is evaluated when a client send their metadata through the OAuth 2.0 dynamic client registration API.
The policy ([`client_registration.rego`]) is evaluated when a client sends their metadata through the OAuth 2.0 dynamic client registration API.
By default, it enforces a set of strict rules to make sure clients provide enough information about themselves, with coherent URLs.
This is useful in production environments, but can be relaxed in development environments.