@@ -71,7 +71,7 @@ These error codes can be returned by any API endpoint:
7171Forbidden access, e.g. joining a room without permission, failed login.
7272
7373` M_UNKNOWN_TOKEN ` 
74- The access token specified was not recognised.
74+ The access or refresh  token specified was not recognised.
7575
7676An additional response parameter, ` soft_logout ` , might be present on the
7777response for 401 HTTP status codes. See [ the soft logout
@@ -314,7 +314,8 @@ Most API endpoints require the user to identify themselves by presenting
314314previously obtained credentials in the form of an ` access_token `  query
315315parameter or through an Authorization Header of ` Bearer $access_token ` .
316316An access token is typically obtained via the [ Login] ( #login )  or
317- [ Registration] ( #account-registration-and-management )  processes.
317+ [ Registration] ( #account-registration-and-management )  processes. Access tokens
318+ can expire; a new access token can be generated by using a refresh token.
318319
319320{{% boxes/note %}}
320321This specification does not mandate a particular format for the access
@@ -338,40 +339,94 @@ inaccessible for the client.
338339
339340When credentials are required but missing or invalid, the HTTP call will
340341return with a status of 401 and the error code, ` M_MISSING_TOKEN `  or
341- ` M_UNKNOWN_TOKEN `  respectively.
342+ ` M_UNKNOWN_TOKEN `  respectively.  Note that an error code of ` M_UNKNOWN_TOKEN ` 
343+ could mean one of four things:
344+ 
345+ 1 .  the access token was never valid.
346+ 2 .  the access token has been logged out.
347+ 3 .  the access token has been [ soft logged out] ( #soft-logout ) .
348+ 4 .  {{< added-in v="1.3" >}} the access token [ needs to be refreshed] ( #refreshing-access-tokens ) .
349+ 
350+ When a client receives an error code of ` M_UNKNOWN_TOKEN ` , it should:
351+ 
352+ -  attempt to [ refresh the token] ( #refreshing-access-tokens ) , if it has a refresh
353+   token;
354+ -  if [ ` soft_logout ` ] ( #soft-logout )  is set to ` true ` , it can offer to
355+   re-log in the user, retaining any of the client's persisted
356+   information;
357+ -  otherwise, consider the user as having been logged out.
342358
343359### Relationship between access tokens and devices  
344360
345361Client [ devices] ( ../index.html#devices )  are closely related to access
346- tokens. Matrix servers should record which device each access token is
347- assigned to, so that subsequent requests can be handled correctly.
362+ tokens and refresh tokens. Matrix servers should record which device
363+ each access token and refresh token are assigned to, so that
364+ subsequent requests can be handled correctly. When a refresh token is
365+ used to generate a new access token and refresh token, the new access
366+ and refresh tokens are now bound to the device associated with the
367+ initial refresh token.
348368
349369By default, the [ Login] ( #login )  and [ Registration] ( #account-registration-and-management ) 
350370processes auto-generate a new ` device_id ` . A client is also free to
351371generate its own ` device_id `  or, provided the user remains the same,
352372reuse a device: in either case the client should pass the ` device_id `  in
353373the request body. If the client sets the ` device_id ` , the server will
354- invalidate any access token previously assigned to that device. There is
355- therefore at most one active access token assigned to each device at any
356- one time.
374+ invalidate any access and refresh tokens previously assigned to that device.
375+ 
376+ ### Refreshing access tokens  
377+ 
378+ {{% added-in v="1.3" %}}
379+ 
380+ Access tokens can expire after a certain amount of time. Any HTTP calls that
381+ use an expired access token will return with an error code ` M_UNKNOWN_TOKEN ` ,
382+ preferably with ` soft_logout: true ` . When a client receives this error and it
383+ has a refresh token, it should attempt to refresh the access token by calling
384+ [ ` /refresh ` ] ( #post_matrixclientv3refresh ) . Clients can also refresh their
385+ access token at any time, even if it has not yet expired. If the token refresh
386+ succeeds, the client should use the new token for future requests, and can
387+ re-try previously-failed requests with the new token. When an access token is
388+ refreshed, a new refresh token may be returned; if a new refresh token is
389+ given, the old refresh token will be invalidated, and the new refresh token
390+ should be used when the access token needs to be refreshed.
391+ 
392+ The old refresh token remains valid until the new access token or refresh token
393+ is used, at which point the old refresh token is revoked. This ensures that if
394+ a client fails to receive or persist the new tokens, it will be able to repeat
395+ the refresh operation.
396+ 
397+ If the token refresh fails and the error response included a `soft_logout:
398+ true` property, then the client can treat it as a [ soft logout] ( #soft-logout ) 
399+ and attempt to obtain a new access token by re-logging in. If the error
400+ response does not include a ` soft_logout: true `  property, the client should
401+ consider the user as being logged out.
402+ 
403+ Handling of clients that do not support refresh tokens is up to the homeserver;
404+ clients indicate their support for refresh tokens by including a
405+ ` refresh_token: true `  property in the request body of the
406+ [ ` /login ` ] ( #post_matrixclientv3login )  and
407+ [ ` /register ` ] ( #post_matrixclientv3register )  endpoints. For example, homeservers
408+ may allow the use of non-expiring access tokens, or may expire access tokens
409+ anyways and rely on soft logout behaviour on clients that don't support
410+ refreshing.
357411
358412### Soft logout  
359413
360- When a request fails due to a 401 status code per above, the server can
361- include an extra response parameter, ` soft_logout ` , to indicate if the
362- client's persisted information can be retained. This defaults to
363- ` false ` , indicating that the server has destroyed the session. Any
414+ A client can be in a "soft logout" state if the server requires
415+ re-authentication before continuing, but does not want to invalidate the
416+ client's session. The server indicates that the client is in a soft logout
417+ state by including a ` soft_logout: true `  parameter in an ` M_UNKNOWN_TOKEN ` 
418+ error response; the ` soft_logout `  parameter defaults to ` false ` . If the
419+ ` soft_logout `  parameter is omitted or is ` false ` , this means the server has
420+ destroyed the session and the client should not reuse it. That is, any
364421persisted state held by the client, such as encryption keys and device
365- information, must not be reused and must be discarded.
422+ information, must not be reused and must be discarded. If ` soft_logout `  is
423+ ` true `  the client can reuse any persisted state.
366424
367- When ` soft_logout `  is true, the client can acquire a new access token by
368- specifying the device ID it is already using to the login API. In most
369- cases a ` soft_logout: true `  response indicates that the user's session
370- has expired on the server-side and the user simply needs to provide
371- their credentials again.
372- 
373- In either case, the client's previously known access token will no
374- longer function.
425+ {{% changed-in v="1.3" %}} A client that receives such a response can try to
426+ [ refresh its access token] ( #refreshing-access-tokens ) , if it has a refresh
427+ token available. If it does not have a refresh token available, or refreshing
428+ fails with ` soft_logout: true ` , the client can acquire a new access token by
429+ specifying the device ID it is already using to the login API.
375430
376431### User-Interactive Authentication API  
377432
@@ -1105,6 +1160,8 @@ errcode of `M_EXCLUSIVE`.
11051160
11061161{{% http-api spec="client-server" api="login" %}}
11071162
1163+ {{% http-api spec="client-server" api="refresh" %}}
1164+ 
11081165{{% http-api spec="client-server" api="logout" %}}
11091166
11101167#### Login Fallback  
0 commit comments