Overview
Token exchange model and the two-token pattern.
The Access SDK authenticates users via token exchange. The partner platform signs a JWT for the user. CI HUB validates the signature against the partner's JWKS, checks the SDK subscription, and returns a CI HUB access token and refresh token. Subsequent API calls use the CI HUB tokens. The client library implements this flow: exchangeToken starts the session and TokenManager keeps both token kinds fresh.
Flow
The partner JWT is consumed once per exchange and discarded. The CI HUB access token is a standard CI HUB JWT (HS256, 1 hour) and flows through the same middleware as panel sessions. The partner's JWKS is the root of trust for that partner; CI HUB caches the published keys for 10 minutes.
Two-token pattern
CI HUB tokens identify the user inside CI HUB. Each DAM provider authenticates separately and has its own credentials.
Authorization: Bearer <CI HUB access_token> (always)
provider-authorization: <DAM connection token> (on content calls)provider-authorization is required on calls that hit a specific DAM (folder browse, search, download). The CI HUB token alone is sufficient for endpoints that operate on CI HUB state (provider listing, token refresh, user session).
The partner platform obtains and stores DAM connection tokens. CI HUB does not persist them server-side.
CI HUB auth vs DAM auth: redirect behavior
Token exchange itself has no browser redirect. It runs server-to-server between the partner backend and CI HUB.
DAM provider login is a separate flow, covered under DAM connection. Most DAMs use OAuth and require a browser-side redirect for the end user to authenticate at the provider. That redirect is part of the DAM login flow, not the CI HUB exchange.
Token lifetimes
| Token | Lifetime | Algorithm | Storage |
|---|---|---|---|
| Partner JWT | up to maxTokenAge (1 hour default) | RS256 | Minted per exchange, discarded |
| CI HUB access token | 1 hour | HS256 | Cached by partner, sent on every call |
| CI HUB refresh token | 30 days | HS256 | Cached by partner, used to mint new access tokens |
The refresh flow uses the refresh token returned by the exchange against GET /auth/refreshToken. Check token revalidates a session; logout signals the end of one.