Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-02-21 13:33:44 +01:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Apply review suggestions

Browse source 
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
This commit is contained in:
Kévin Commaille 2025-06-18 11:36:55 +02:00
parent f0a1ee14d9
commit 6309cff957
No known key found for this signature in database
GPG key ID: F26F4BE20A08255B
1 changed files with 43 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

57
content/client-server-api/_index.md
View file

@ -1487,24 +1487,53 @@ When a user wants to log out from a client, the client SHOULD use OAuth 2.0
token revocation as defined in [RFC 7009](https://datatracker.ietf.org/doc/html/rfc7009).
The client makes a `POST` request to the `revocation_endpoint` that can be found
in the authorization server metadata.
in the [authorization server metadata](#server-metadata-discovery).
The body of the request includes the following parameters, encoded as
`application/x-www-form-urlencoded`:
- `token`: This parameter MUST contain either the access token or the refresh
token to be revoked.
- `token_type_hint`: This parameter is OPTIONAL, and if present, MUST have a
value of either `access_token` or `refresh_token`. The server MAY use this
value to optimize the token lookup process.
- `client_id`: The client identifier obtained during client registration. This
parameter is OPTIONAL.
If the `client_id` is not provided, or does not match the client associated
with the token, the server SHOULD still revoke the token. This behavior is
meant to help good actors like secret scanning tools to proactively revoke
leaked tokens. The server MAY also warn the user that one of their sessions
may be compromised in this scenario.
<table>
<thead>
<tr>
<th>Parameter</th>
<th>Value</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>token</code></td>
<td>
<strong>Required.</strong> MUST contain either the access token or the
refresh token to be revoked.
</td>
</tr>
<tr>
<td><code>token_type_hint</code></td>
<td>
<strong>Optional.</strong> If present, MUST have a value of either
<code>access_token</code> or <code>refresh_token</code>. The server MAY
use this value to optimize the token lookup process.
</td>
</tr>
<tr>
<td><code>client_id</code></td>
<td>
<p>
<strong>Optional.</strong> The client identifier obtained during
<a href="#client-registration">client registration</a>.
</p>
<p>
If the <code>client_id</code> is not provided, or does not match the
client associated with the token, the server SHOULD still revoke the
token. This behavior is meant to help good actors like secret scanning
tools to proactively revoke leaked tokens. The server MAY also warn
the user that one of their sessions may be compromised in this
scenario.
</p>
</td>
</tr>
</tbody>
</table>
For example, revoking using the access token: