This section specifies how Client connections are authorized by the AS and verified by the MQTT Broker. Figure 1
shows the basic protocol flows during connection setup. The token request and response use the token endpoint at the AS, specified for HTTP-based interactions in Section 5.8
of RFC 9200
. Steps (D) and (E) are optional and use the introspection endpoint specified in Section 5.9
of RFC 9200
. The discussion in this document assumes that the Client and the Broker use HTTPS to communicate with the AS via these endpoints. The Client and the Broker use MQTT to communicate between them. The C-AS and Broker-AS communications MAY
be implemented using protocols other than HTTPS, e.g., CoAP or MQTT. Whatever protocol is used for the C-AS and Broker-AS communications MUST
provide mutual authentication, confidentiality protection, and integrity protection.
If the Client is resource constrained or does not support HTTPS, a separate Client Authorization Server may carry out the token request on behalf of the Client (Figure 1
, steps (A) and (B)) and, later, onboard the Client with the token. The interactions between a Client and its Client Authorization Server for token onboarding and support for MQTT-based token requests at the AS are out of the scope of this document.
| Client |
+---(A) Token request------| Client - |
| | Authorization |
| +-(B) Access token-----> Server Interface |
| | | (HTTPS) |
| | |_____________________|
| | | |
+--v-------------+ | Pub/Sub Interface |
| Authorization | | (MQTT over TLS) |
| Server | +----------------^----+
|________________| | |
| ^ (C) Connection (F) Connection
| | request + response
| | access token |
| | | |
| | +---v--------------+
| | | Broker |
| | | (MQTT over TLS) |
| | |__________________|
| +(D) Introspection-----| |
| request (optional)| RS-AS interface |
| | (HTTPS) |
The first step in the protocol flow (Figure 1
, step (A)) is the token acquisition by the Client from the AS. The Client and the AS MUST
perform mutual authentication. The Client requests an access token from the AS, as described in Section 5.8.1
of RFC 9200
. The document follows the procedures defined in Section 3.2.1
of RFC 9202
for raw public keys (RPKs) [RFC 7250
]) and in Section 3.3.1
of RFC 9202
for pre-shared keys (PSKs). However, the content type of the request is set to "application/ace+json", and the AS uses JSON in the Payload of its responses to the Client and the RS. As explained earlier, implementations MAY
also use the "application/ace+cbor" content type.
On receipt of the token request, the AS verifies the request. If the AS successfully verifies the access token request and authorizes the Client for the indicated audience (i.e., RS) and scopes (i.e., publish/subscribe permissions over topics, as described in Section 2.3
), the AS issues an access token (Figure 1
, step (B)).
The response includes the parameters described in Section 5.8.2
of RFC 9200
. For RPKs, the parameters are as described in Section 3.2.1
of RFC 9202
. For PSKs, the document follows Section 3.3.1
of RFC 9202
. In both cases, if the response contains an "ace_profile" parameter, this parameter is set to "mqtt_tls". The returned token is a Proof-of-Possession (PoP) token by default.
This document follows [RFC 7800
] for PoP semantics for JWTs (CWTs MAY
also be used). The AS includes a "cnf" (confirmation) parameter in the PoP token to declare that the Client possesses a particular key and the RS can cryptographically confirm that the Client has possession of that key, as described in [RFC 9201
Note that the contents of the web tokens (including the "cnf" parameter) are to be consumed by the RS and not the Client (the Client obtains the key information in a different manner). The RPK case is handled as described in Section 3.2.1
of RFC 9202
. For the PSK case, the referenced procedures apply, with the following exceptions to accommodate JWT and JOSE use. In this case, the AS adds a "cnf" parameter to the Access Information carrying [RFC 7517
] object that contains either the symmetric key itself or a key identifier that can be used by the RS to determine the secret key it shares with the Client. The JWT is created as explained in Section 7
of RFC 7519
, and the JWT MUST
include [RFC 7516
]. If a CWT/COSE is used, this information MUST
be inside the "COSE_Key" object and MUST
be encrypted using a "COSE_Encrypt0" structure.
The AS returns error responses for JSON-based interactions following Section 5.2
of RFC 6749
. When CBOR is used, the interactions MUST
implement the procedure described in Section 5.8.3
of RFC 9200
Unless the Client publishes and subscribes to only public topics, the Client and the Broker MUST
perform mutual authentication. The Client MUST
authenticate to the Broker either over MQTT or TLS before performing any other action. For MQTT, the options are "None" and "ace". For TLS, the options are "Anon" for an anonymous client, and "Known(RPK/PSK)" for RPKs and PSKs, respectively. The "None" and "Anon" options do not provide client authentication but can be used either during authentication or in combination with authentication at the other layer. When the Client uses TLS:Anon,MQTT:None, the Client can only publish or subscribe to public topics. Thus, the client authentication procedures involve the following possible combinations:
This option is used only for the topics that do not require authorization, including the "authz-info" topic. Publishing to the "authz-info" topic is described in Section 2.2.2.
The token is transported inside the CONNECT packet and MUST be validated using one of the methods described in Section 2.2.2. This option also supports a tokenless connection request for AS discovery. As per the [RFC 9200], a separate step is needed to determine whether the discovered AS URI is authorized to act as an AS.
This specification supports client authentication with TLS with RPKs and PSKs, following the procedures described in the [RFC 9202]. For the RPK, the Client MUST have published the token to the "authz-info" topic. For the PSK, the token MAY be published to the "authz-info" topic or MAY be, alternatively, provided as a "PSK identity" (e.g., an "identity" in the "identities" field in the Client's "pre_shared_key" extension in TLS 1.3).
This option SHOULD NOT be chosen as the token transported in the CONNECT packet and overwrites any permissions passed during the TLS authentication.
It is RECOMMENDED
that the Client implements TLS:Anon,MQTT:ace as the first choice when working with protected topics. However, MQTT v3.1.1 Clients that do not prefer to overload the User Name and Password fields for ACE (as described in Section 6
implement TLS:Known(RPK/PSK),MQTT:none and, consequently, TLS:Anon,MQTT:None to submit their token to "authz-info".
The Broker MUST
support TLS:Anon,MQTT:ace. To support Clients with different capabilities, the Broker MAY
provide multiple client authentication options, e.g., support TLS:Known(RPK),MQTT:none and TLS:Anon,MQTT:None, to enable RPK-based client authentication.
The Client MUST
authenticate the Broker during the TLS handshake. If the Client authentication uses TLS:Known(RPK/PSK), then the Broker is authenticated using the respective method. Otherwise, to authenticate the Broker, the Client MUST
validate a public key from an X.509 certificate or an RPK from the Broker against the "rs_cnf" parameter in the token response, which contains information about the public key used by the RS to authenticate if the token type is "pop" and asymmetric keys are used as defined in [RFC 9201
]. The AS MAY
include the thumbprint of the RS's X.509 certificate in the "rs_cnf" (thumbprint, as defined in [RFC 9360
]). In this case, the Client MUST
validate the RS certificate against this thumbprint.
In the cases when the Client must transport the token to the Broker first, the Client connects to the Broker to publish its token to the "authz-info" topic. The "authz-info" topic MUST
only be published (i.e., the Clients are not allowed to subscribe to it). "authz-info" is not protected, and hence, the Client uses the TLS:Anon,MQTT:None option over a TLS connection. After publishing the token, the Client disconnects from the Broker and is expected to reconnect using client authentication over TLS (i.e., TLS:Known(RPK/PSK),MQTT:none).
The Broker stores and indexes all tokens received to the "authz-info" topic in its key store (similar to the [RFC 9202
]). This profile follows the recommendation of Section 5.10.1
of RFC 9200
and expects that the Broker stores only one token per PoP key, and any other token linked to the same key overwrites an existing token.
The Broker MUST
verify the validity of the token (i.e., through local validation or introspection if the token is a reference), as described in Section 2.2.5
. If the token is not valid, the Broker MUST
discard the token.
Depending on the QoS level of the PUBLISH packet, the Broker returns the error response as a PUBACK, PUBREC, or DISCONNECT packet. If the QoS level is equal to 0, and the token is not valid, or if the claims cannot be obtained in the case of an introspected token, the Broker MUST
send a DISCONNECT packet with reason code 0x87 (Not authorized). If the PUBLISH Payload does not parse to a token, the Broker MUST
send a DISCONNECT with reason code 0x99 (Payload format invalid).
If the QoS level of the PUBLISH packet is greater than or equal to 1, and the token is not valid, or the claims cannot be obtained in the case of an introspected token, the Broker MUST
send reason code 0x87 (Not authorized) in the PUBACK or PUBREC. If the PUBLISH Payload does not parse to a token, the PUBACK/PUBREC reason code is 0x99 (Payload format invalid).
When the Broker sends the "Not authorized" response, it must be noted that this corresponds to the token being not valid and not that the actual PUBLISH packet was not authorized. Given that the "authz-info" is a public topic, this response is not expected to cause confusion.
This document supports TLS with raw public keys (RPKs) [RFC 7250
] and with pre-shared keys (PSKs). The TLS session setup follows the [RFC 9202
], as the profile applies to TLS equally well [RFC 9430
]. When there are exceptions to the DTLS profile, these are explicitly stated in the document. If TLS 1.2 is used, [RFC 7925
] describes how TLS can be used for constrained devices, alongside recommended cipher suites. Additionally, TLS 1.2 implementations MUST
use the "Extended Main Secret" extension (terminology adopted from [TLS-bis
]) to incorporate the handshake transcript into the main secret [RFC 7627
]. TLS implementations SHOULD
use the Server Name Indication (SNI) [RFC 6066
] and Application-Layer Protocol Negotiation (ALPN) [RFC 7301
] extensions so the TLS handshake authenticates as much of the protocol context as possible.
This document follows the procedures defined in Section 3.2.2
of RFC 9202
with the following exceptions. The Client MUST
upload the access token to the Broker using the method specified in Section 2.2.2
before initiating the handshake.
This document follows the procedures defined in Section 3.3.2
of RFC 9202
with the following exceptions.
To use TLS 1.3 with pre-shared keys, the Client utilizes the PSK extension specified in [RFC 8446
] using the key conveyed in the "cnf" parameter of the AS response. The same key is bound to the access token in the "cnf" claim. The Client can upload the token, as specified in Section 2.2.2
, before initiating the handshake. When using a previously uploaded token, the Client MUST
indicate during the handshake which previously uploaded access token it intends to use. To do so, it MUST
create a "COSE_Key" or "JWK" structure with the "kid" that was conveyed in the "rs_cnf" claim in the token response from the AS and the key type "symmetric". This structure is then included as the only element in the "cnf" structure and the encoded value of that "cnf" structure used as a PSK identity in TLS. As an alternative to the access token upload, the Client can provide the most recent access token, JWT or CWT, as a PSK identity.
In contrast to the [RFC 9202
], a Client MAY
omit support for the cipher suites TLS_PSK_WITH_AES_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8. For TLS 1.2, however, a client MUST
support TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 for PSKs [RFC 8442
] and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for RPKs [RFC 8422
], as recommended in [RFC 9325
] (and adjusted to be a PSK cipher suite as appropriate).
This section describes how the Client transports the token to the Broker inside the CONNECT packet. If this method is used, the Client TLS connection is expected to be anonymous, and the Broker is authenticated during the TLS connection setup. The approach described in this section is similar to an earlier proposal by Fremantle, et al. [Fremantle14
After sending the CONNECT packet, the Client MUST
wait to receive the CONNACK packet from the Broker. The only packets it is allowed to send are DISCONNECT or AUTH that are in response to the Broker AUTH. Similarly, except for a DISCONNECT and AUTH response from the Client, the Broker MUST NOT
process any packets before sending a CONNACK packet.
shows the structure of the MQTT CONNECT packet used in MQTT v5.0. A CONNECT packet is composed of a Fixed Header, a Variable Header, and a Payload The Fixed Header contains the Control Packet Type (CPT), Reserved, and Remaining Length fields. The Remaining Length is a Variable Byte Integer that represents the number of bytes remaining within the current Control Packet, including data in the Variable Header and the Payload. The Variable Header contains the Protocol Name, Protocol Level, Connect flags, Keep Alive, and Properties fields. The Connect flags in the Variable Header specify the properties of the MQTT Session. It also indicates the presence or absence of some fields in the Payload. The Payload contains one or more encoded fields, namely a unique Client Identifier for the Client, a Will Topic, Will Payload, User Name, and Password. All but the Client Identifier can be omitted depending on the flags in the Variable Header. The Client Identifier identifies the Client to the Broker and, therefore, is unique for each Client. It must be noted that the Client Identifier is an unauthenticated identifier used within the MQTT protocol and so is not bound to the access token.
0 8 16
|Protocol name length = 4 |
| 'M' 'Q' |
| 'T' 'T' |
| Keep alive |
| CONNECT Properties Length |
| (up to 4 bytes) |
| ( ..Other properties..) |
| Authentication Method |
| (0x15) | Len |
| Len | 'a' |
| 'c' | 'e' |
| Authentication Data |
| (0x16) | Len |
| Len | token |
| or token + PoP data |
The CONNECT flags are User Name, Password, Will Retain, Will QoS, Will Flag, Clean Start, and Reserved. Table 1
shows how the flags MUST
be set to use AUTH packets for authentication and authorization, i.e., the User Name Flag and Password Flag MUST
be set to 0. An MQTT v5.0 Broker MAY
also support token transport using the User Name and Password to provide a security option for MQTT v3.1.1 Clients, as described in Section 6
Table 1: CONNECT Flags for AUTH
|User Name Flag
The Will Flag indicates that a Will Message needs to be sent. The Client MAY
set the Will Flag as desired (marked as "X" in Table 1
). If the Will Flag is set to 1, the Broker MUST
check that the token allows the publication of the Will Message (i.e., the Will Topic Filter is in the scope array). The check is performed against the token scope described in Section 2.3
. If the Will authorization fails, the connection is refused, as described in Section 2.4.1
. If the Broker accepts the connection request, the Broker stores the Will Message and publishes it when the Network Connection is closed according to Will QoS, Will Retain parameters, and MQTT Will management rules. To avoid publishing the Will Messages in the case of temporary network disconnections, the Client specifies a Will Delay Interval in the Will Properties. Section 5
explains how the Broker deals with the retained messages in further detail.
In MQTT v5.0, the Client signals a new Session (i.e., that the Session does not continue an existing Session) by setting the Clean Start flag to 1 in the CONNECT packet. In this profile, the Client SHOULD
always start with a new Session. The Broker MAY
also signal that it does not support the continuation of an existing Session by setting the Session Expiry Interval to 0 in the CONNACK. If the Broker starts a new Session, the Broker MUST
set the Session Present flag to 0 in the CONNACK packet to signal this to the Client.
The Broker MAY
support continuing an existing Session, e.g., if the Broker requires it for QoS reasons. In this case, if a CONNECT packet is received with Clean Start set to 0, and there is a Session associated with the Client Identifier, the Broker MUST
resume communications with the Client based on the state from the existing Session. In its response, the Broker MUST
set the Session Present flag to 1 in the CONNACK packet to signal the continuation of an existing Session to the Client. The Session State stored by the Client and the Broker is described in Section 5
When reconnecting to a Broker that supports continuing existing Sessions, the Client MUST
still provide a token in addition to using the same Client Identifier and setting the Clean Start to 0. The Broker MUST
still perform PoP validation on the provided token. If the token matches the stored state, the Broker MAY
skip introspecting a token-by-reference and use the stored introspection result. The Broker MUST
also verify the Client is authorized to receive or send MQTT packets that are pending transmission. When a Client connects with a long Session Expiry Interval, the Broker may need to maintain the Client's MQTT Session State after it disconnects for an extended period. Brokers SHOULD
implement administrative policies to limit misuse.
Note that, according to the MQTT standard, the Broker uses the Client Identifier to identify the Session State. In the case of a Client Identifier collision, a Client may take over another Client's Session. Given that the Broker MUST
associate the Client with a valid token, a Client will only send or receive messages to its authorized topics. Therefore, while this issue is not expected to affect security, it may affect QoS (i.e., PUBLISH or QoS messages saved for Client A may be delivered to a Client B). In addition, if this Client Identifier represents a Client already connected to the Broker, the Broker sends a DISCONNECT packet to the existing Client with reason code 0x8E (Session taken over) and closes the connection to the Client.
shows the Authentication Method and Authentication Data fields when the client authenticates using the AUTH property. The Client MUST
set the Authentication Method as a property of a CONNECT packet by using the property identifier 21 (0x15). This is followed by a UTF-8-encoded string containing the name of the Authentication Method, which MUST
be set to "ace". If the Broker does not support this profile, it sends a CONNACK packet with reason code 0x8C (Bad authentication method).
The Authentication Method is followed by the Authentication Data, which has a property identifier 22 (0x16) and is Binary Data. Based on the Authentication Data, the Broker MUST
support both options below:
proof of possession using a challenge from the TLS session
proof of possession via a Broker-generated challenge/response
|Authentication|Token Length|Token |MAC or Signature |
|Data Length | | |(over TLS exporter content) |
For this option, the Authentication Data inside the Client's CONNECT packet MUST
contain the two-byte integer token length, the token, and the keyed message digest (MAC) or the Client signature (as shown in Figure 3
). The Proof-of-Possession key in the token is used to calculate the keyed message digest (MAC) or the Client signature based on the content obtained from the TLS exporter ([RFC 5705
] for TLS 1.2 and Section 7.5
of RFC 8446
for TLS 1.3). This content is exported from the TLS session using the exporter label "EXPORTER-ACE-MQTT-Sign-Challenge", an empty context, and a length of 32 bytes. The token is also validated, as described in Section 2.2.5
, and the Broker responds with a CONNACK packet with the appropriate response code. The Client cannot reauthenticate using this method during the same TLS session (see Section 4
|Authentication|Token Length|Token |
|Data Length | | |
|Authentication|RS Nonce |
|Data Length |(8 bytes) |
For this option, the Broker follows a Broker-generated challenge/response protocol. If the Authentication Data inside the Client's CONNECT contains only the two-byte integer token length and the token (as shown in Figure 4
), the Broker MUST
respond with an AUTH packet with the authenticated reason code set to 0x18 (Continue Authentication). The Broker also uses this method if the Authentication Data does not contain a token, but the Broker has a token stored for the connecting Client.
The Broker continues authentication using an AUTH packet that contains the Authentication Method and the Authentication Data. The Authentication Method MUST
be set to "ace", and the Authentication Data MUST NOT
be empty and MUST
contain an 8-byte RS nonce as a challenge for the Client (Figure 5
|Authentication|Client Nonce |MAC or Signature |
|Data Length |(8 bytes) |(over RS nonce+Client nonce)|
The Client responds to this with an AUTH packet with reason code 0x18 (Continue Authentication). Similarly, the Client packet sets the Authentication Method to "ace". The Authentication Data in the Client's response is formatted as shown in Figure 6
and includes the 8-byte Client nonce and the signature or MAC computed over the RS nonce concatenated with the Client nonce using PoP key in the token.
Next, the token is validated as described in Section 2.2.5
. The success case is illustrated in Figure 7
. The Client MAY
also reauthenticate using this challenge-response flow, as described in Section 4
|<===========>| TLS connection setup
+------------>| CONNECT with Authentication Data
| | contains only token
<-------------+ AUTH 0x18 (Cont. Authentication)
| | 8-byte RS nonce as challenge
|------------>| AUTH 0x18 (Cont. Authentication)
| | 8-byte Client nonce + signature/MAC
| |---+ Token validation
| | | (may involve introspection)
|<------------+ CONNACK 0x00 (Success)
The Broker MUST
verify the validity of the token either locally (e.g., in the case of a self-contained token) or MAY
send a request to the introspection endpoint of the AS (as described for HTTP-based interactions in Section 5.9
of RFC 9200
). The Broker MUST
verify the claims in the access token according to the rules set in Section 220.127.116.11
of RFC 9200
To authenticate the Client, the Broker validates the signature or the MAC, depending on how the PoP protocol is implemented. For self-contained tokens, the Broker MUST
process the security protection of the token first, as specified by the respective token format, i.e., a CWT uses COSE, while a JWT uses JOSE. For a token-by-reference, the Broker uses the "cnf" structure returned as a result of token introspection, as specified in [RFC 7519
]. HMAC-SHA-256 (HS256) [RFC 6234
] and Ed25519 [RFC 8032
] are mandatory to implement for the Broker. The Client MUST
implement at least one of them depending on the choice of symmetric or asymmetric validation. Validation of the signature or MAC MUST
fail if the signature algorithm is set to "none" when the key used for the signature algorithm cannot be determined or the computed and received signature/MAC do not match.
The Broker MUST
check if the access token is still valid, if it is the intended destination (i.e., the audience) of the token, and if the token was issued by an authorized Authorization Server. If the Client is using TLS RPK mode to authenticate to the Broker, the AS constructs the access token so that the Broker can associate the access token with the Client's public key. The "cnf" claim MUST
contain either the Client's RPK or, if the key is already known by the Broker (e.g., from previous communication), a reference to it.
The scope field contains the publish and subscribe permissions for the Client. Therefore, the token or its introspection result MUST
be cached to allow a Client's future PUBLISH and SUBSCRIBE messages. During the CONNECT, if the Will Flag is set to 1, the Broker MUST
also authorize the publication of the Will Topic and Will Message using the token's scope field. The Broker uses the scope to match against the Topic Name in a PUBLISH packet (including Will Topic in the CONNECT) or a Topic Filter in a SUBSCRIBE packet.
The scope in the token is a single value. For a JWT, the single scope is a base64url-encoded string with any padding characters removed, which has an internal structure of a JSON array. For a CWT, this information is represented in CBOR. The internal structure follows the [RFC 9237
]. Using the Concise Data Definition Language (CDDL) [RFC 8610
], the specific data model for MQTT is:
AIF-MQTT = AIF-Generic<mqtt-topic-filter, mqtt-permissions>
AIF-Generic<Toid, Tperm> = [* [Toid, Tperm]]
mqtt-topic-filter = tstr ; as per Section 4.7 of MQTT v5.0
mqtt-permissions = [+permission]
permission = "pub"/"sub"
Topic Filters are implemented according to Section 4.7 of the [MQTT-OASIS-Standard-v5
]. By default, Wildcard Subscriptions are supported, and so, the Topic Filter may include special wildcard characters. The multi-level wildcard, "#", matches any number of levels within a topic, and the single-level wildcard, "+", matches one topic level. The Broker MAY
signal in the CONNACK explicitly whether Wildcard Subscriptions are supported by returning a CONNACK property "Wildcard Subscription Available". A value of 0 means that Wildcard Subscriptions are not supported. A value of 1 means Wildcard Subscriptions are supported.
Following this model, an example scope may contain:
This access token gives publish ("pub") and subscribe ("sub") permissions to the "topic1", publish permission to all the subtopics of "topic2", and subscribe permission to all "topic3", skipping one level.
If the scope is empty, the Broker records no permissions for the Client for any topic. In this case, the Client is not able to publish or subscribe to any protected topics. The non-empty scope is used to authorize the Will Topic, if provided, in the CONNECT packet, during connection setup and, if the connection request succeeds, the Topic Names or Topic Filters requested in the future PUBLISH and SUBSCRIBE packets. For the authorization to succeed, the Broker MUST
verify that the Topic Name or Topic Filter in question is either an exact match to or a subset of at least one "topic_filter" in the scope.
Based on the validation result (obtained either via local inspection or using the introspection interface of the AS), the Broker MUST
send a CONNACK packet to the Client.
Authentication can fail for the following reasons:
if the Client does not provide a valid token,
the Client omits the Authentication Data field and the Broker has no token stored for the Client,
the token or Authentication data are malformed, or
if the Will Flag is set, the authorization checks for the Will Topic fails.
The Broker responds with the CONNACK reason code 0x87 (Not Authorized) or any other applicable reason code.
The Broker MAY
also trigger AS discovery and include a User Property (identified as property type 38 (0x26)) in the CONNACK for the AS Request Creation Hints. The User Property is a UTF-8 string pair, composed of a name and a value. The name of the User Property MUST
be set to "ace_as_hint". The value of the User Property is a UTF-8-encoded JSON object containing the mandatory "AS" parameter and the optional parameters "audience", "kid", "cnonce", and "scope", as defined in Section 5.3
of RFC 9200
On success, the reason code of the CONNACK is 0x00 (Success). If the Broker starts a new Session, it MUST
also set Session Present to 0 in the CONNACK packet to signal a new Session to the Client. Otherwise, it MUST
set Session Present to 1.
Having accepted the connection, the Broker MUST
be prepared to store the token during the connection and after disconnection for future use. If the token is not self-contained and the Broker uses token introspection, it MAY
cache the validation result to authorize the subsequent PUBLISH and SUBSCRIBE packets. PUBLISH and SUBSCRIBE packets, which are sent after a connection setup, do not contain access tokens. If the introspection result is not cached, the Broker needs to introspect the saved token for each request. The Broker SHOULD
also use a cache timeout to introspect tokens regularly. The timeout value is specific to the application and should be chosen to reduce the risk of using stale introspection responses.