Atlassian JWT Plugin
The Atlassian JWT plugin (tika-pipes-atlassian-jwt) provides a fetcher specifically for Atlassian Connect endpoints (Jira Cloud, Confluence Cloud) that require an Atlassian-style JWT bearer token. It is fetcher-only — pair it with another emitter and iterator.
For generic HTTP fetching, use the HTTP plugin instead.
| Interface | Component name | Class |
|---|---|---|
Fetcher |
|
|
Atlassian JWT Fetcher (atlassian-jwt-fetcher)
Fetches resources from an Atlassian Cloud endpoint, generating a fresh JWT for each request signed with the app’s shared secret.
{
"fetchers": {
"ajwt": {
"atlassian-jwt-fetcher": {
"issuer": "tika-pipes-app-key",
"sharedSecret": "REDACTED_SHARED_SECRET",
"subject": "service-account@example.com",
"jwtExpiresInSeconds": 3600,
"maxConnections": 2000,
"maxConnectionsPerRoute": 1000,
"connectTimeoutMillis": 30000,
"socketTimeoutMillis": 60000,
"requestTimeoutMillis": 60000,
"overallTimeoutMillis": 120000,
"userAgent": "tika-pipes/1.0"
}
}
}
}
Configuration
| Field | Default | Description |
|---|---|---|
|
required |
Atlassian Connect app key (the |
|
required |
Shared secret from the app installation, used as the JWT signing key. |
|
none |
JWT |
|
|
JWT validity window. Each request gets a freshly-signed token. |
|
none |
|
|
|
HTTP connection-pool size. |
|
|
Per-route connection-pool size. |
|
|
TCP connect timeout. |
|
|
Socket read timeout. |
|
|
Connection-manager request timeout. |
|
|
Hard cap on total time for a single fetch operation. |
|
|
Maximum number of redirects to follow. |
|
|
Maximum bytes to spool locally. |
|
|
Maximum bytes of error response body to capture into the exception. |
|
empty |
Extra HTTP headers, formatted as |
|
empty |
Structured per-request headers as a |
Security Notes
This fetcher verifies TLS certificates and hostnames against the JVM trust store, and its
config exposes no way to turn verification off. Traffic to Atlassian Cloud is therefore both
encrypted and authenticated, which matters here because the Authorization header carries a
signed JWT. If the cluster presents a certificate from a private CA, add that CA to the JVM
truststore.
The fetch key is used as the request URL with no validation, exactly as in the HTTP fetcher — the same server-side request forgery considerations apply, including the absence of a redirect host allowlist. Treat the source of fetch keys as fully trusted.
Notes
-
The JWT is computed per request — the
qshclaim is derived from the request method and URL, as required by Atlassian Connect. -
sharedSecretis sensitive; use environment-variable substitution or external secret stores rather than inlining it in source control. -
For Jira Server / Data Center (not Cloud) endpoints, use the HTTP plugin with basic or token auth instead — those endpoints do not accept Atlassian Connect JWTs.