...
listener.name.<listener name>.oauthbearer.sasl.jwks.endpoint.uri
: OAuth issuer's JWK Set endpoint URI from which to retrieve the set of JWKs managed by the provider; this can be afile://
-based URL that points to a broker file system-accessible file-based copy of the JWKS data. This allows the JWKS data to be updated on the file system and refreshed on the broker when the file is updated, thus avoiding any HTTP(S) communication with the OAuth/OIDC providerlistener.name.<listener name>.oauthbearer.sasl.jwks.refresh.interval.ms
: optional value in milliseconds for how often to refresh the JWKS from the URL pointed to bylistener.name.<listener name>.oauthbearer.sasl.jwks.endpoint.uri
. Only used when using an HTTP or HTTPS(S)-based URI forlistener.name.<listener name>.oauthbearer.sasl.jwks.endpoint.uri
. Defaults to3600000
(1 hour)listener.name.<listener name>.oauthbearer.sasl.sub.claim.name
: name of the scope from which to extract the subject claim from the JWT; defaults tosub
listener.name.<listener name>.oauthbearer.sasl.scope.claim.name
: name of the scope from which to extract the scope claim from the JWT; defaults toscope
listener.name.<listener name>.oauthbearer.sasl.clock.skew.seconds
: optional value in seconds for the clock skew between the OAuth/OIDC provider and the broker. Only used when using an HTTP or HTTPS(S)-based URI forlistener.name.<listener name>.oauthbearer.sasl.jwks.endpoint.uri
. Defaults to30
listener.name.<listener name>.oauthbearer.sasl.expected.audience
: The (optional) comma-delimited setting for the broker to use to verify that the JWT was issued for one of the expected audiences. The JWT will be inspected for the standard OAuthaud
claim and if this configuration option is set, the broker will match the value from JWT'saud
claim to see if there is an exact match. If there is no match, the broker will reject the JWT and authentication will fail.listener.name.<listener name>.oauthbearer.sasl.expected.issuer
: Optional setting for the broker to use to verify that the JWT was created by the expected issuer. The JWT will be inspected for the standard OAuthiss
claim and if this configuration option is set, the broker will match the value from JWT'siss
claim to see if there is an exact match. If there is no match, the broker will reject the JWT and authentication will fail.
...
Providing a JWKS URL. In this mode, the JWKS data will be retrieved from the OAuth provider via the configured URL on broker startup. All then-current keys will be cached on the broker (per the ‘max age’; the jose4j library has a means to keep these-up-to-date when they age out) for incoming requests. If an authentication request is received for a JWT that includes a
kid
that isn’t yet in the cache, the JWKS endpoint will be queried again on demand. However, we prefer polling via a background thread to hopefully pre-populate the cache with any forthcoming keys before any JWT requests that include them are received.Providing a JWKS file. On startup, the broker will load the JWKS file from the configured location. Any updates to the file will require a restart of the broker. The means by which the JWKS file is updated is left to the cluster administrator. In the event that an unknown JWT key is encountered, this implementation will simply issue an error and validation will fail.
Warning |
---|
If the the URL or file that is specified cannot be read, the broker will fail to start up. In the case of an HTTP(S)-based URI, the configured It is also important that the JWKS is retrieved before the broker's ports are opened. Otherwise clients that connect to the broker before the JWKS is retrieved will experience spurious authentication failures (e.g. during broker restarts). |
Broker-to-broker Support
The use of OAuth credentials for broker-to-broker communication will continue to be supported. As with the existing implementation, users can specify the protocols and implementations to use for broker-based communication. This would require providing the appropriate configuration for both client login and broker validation.
...