generated: '2026-08-17' method: searched source: https://docs.allo-media.net/activate-api/rest/authentication/ docs: - https://docs.allo-media.net/activate-api/rest/authentication/ - https://docs.allo-media.net/stream-h2h/protocol/ - https://docs.allo-media.net/stream-h2h/python/getting-started/ - https://docs.allo-media.net/stream-h2b/protocols/authentication/ note: >- Derived by reading the provider's own auth documentation, not from an OpenAPI — no machine-readable spec was reachable during this pass (see x-coverage in apis.yml). Every value below is quoted from the docs pages listed above. Credentials themselves are not self-service: the docs state client_id/client_secret "were provided to you by your account manager". summary: types: [oauth2, openIdConnect, http] oauth2_flows: [clientCredentials] oauth2_flows_available_but_undocumented: [authorizationCode, deviceCode, password, refreshToken, tokenExchange, jwtBearer, uma, ciba] bearer_in: [header, query] identity_provider: Keycloak (realm `uhlive`) oidc_discovery: https://id.uh.live/realms/uhlive/.well-known/openid-configuration oidc_discovery_verified: true scopes_documented: false scopes_discovered: 19 self_service_signup: false x-discovery-upgrade: date: '2026-08-17' note: >- This profile was upgraded from documentation-only to probe-verified. The provider's docs describe one flow and no scopes; the realm's OIDC discovery document (captured verbatim at well-known/allo-media-openid-configuration.json, HTTP 200, application/json, 6,625 bytes) exposes a full authorization-server configuration including a per-product scope model, mTLS-bound access tokens, DPoP, private_key_jwt and dynamic client registration. Full detail in scopes/allo-media-scopes.yml. discovery_url: https://id.uh.live/realms/uhlive/.well-known/openid-configuration http_status: 200 schemes: - name: uhlive_keycloak_oidc type: openIdConnect openIdConnectUrl: https://id.uh.live/realms/uhlive/.well-known/openid-configuration issuer: https://id.uh.live/realms/uhlive jwks_uri: https://id.uh.live/realms/uhlive/protocol/openid-connect/certs verified: probed detail: scopes/allo-media-scopes.yml note: >- The realm behind every API surface. Advertises PKCE (S256 and plain), private_key_jwt, tls_client_auth with mTLS-bound access tokens, DPoP, token introspection and revocation endpoints, and dynamic client registration. None of this is mentioned in the developer documentation. - name: uhlive_oauth2_client_credentials type: oauth2 flow: clientCredentials token_url: https://id.uh.live/realms/uhlive/protocol/openid-connect/token request_body: client_id: "{provided by your account manager}" client_secret: "{provided by your account manager}" grant_type: client_credentials scopes: [activate, stream-h2h, stream-h2h-v2, stream-h2b, voip-callapi, scribr] scopes_note: >- No OAuth scopes are documented anywhere in the provider's public docs — no scope parameter appears in any example. But the realm's OIDC discovery document advertises a per-product scope model: `activate`, `stream-h2h`, `stream-h2h-v2`, `stream-h2b`, `scribr`, plus `voip-callapi` for a surface with no documentation page at all. Captured in scopes/allo-media-scopes.yml with per-scope confidence, because `scopes_supported` describes what the authorization server can issue, not what any given client is granted. source: https://docs.allo-media.net/activate-api/rest/authentication/ - name: activate_api_bearer type: http scheme: bearer in: header header: Authorization format: "bearer {access_token}" token_lifetime_seconds: 3600 token_lifetime_note: >- "Token lifetime: 60 minutes" per the Activate API authentication page. applies_to: Activate API (REST) — https://activate.uh.live source: https://docs.allo-media.net/activate-api/rest/authentication/ - name: stream_api_jwt_query type: http scheme: bearer in: query parameter: jwt format: "wss://api.uh.live/socket/websocket?vsn=2.0.0&jwt={access_token}" token_lifetime_seconds: 300 token_lifetime_note: >- "Token validity: 5 minutes" per the Stream API V2 protocol reference — a different, much shorter TTL than the Activate REST token, so an integration holding one token for both surfaces will fail on the stream side first. applies_to: Stream API for humans (WebSocket) — wss://api.uh.live source: https://docs.allo-media.net/stream-h2h/protocol/ note: >- The access token is passed as a URL query parameter on the WebSocket handshake rather than an Authorization header. That is normal for browser WebSocket clients (which cannot set headers) but it does mean the token can land in proxy/access logs. - name: jupload_sftp type: other mechanism: SFTP account credentials applies_to: JUpload batch audio ingestion (SFTP) optional_payload_encryption: GPG (public key supplied by the provider) source: https://docs.allo-media.net/jupload/encryption/ note: >- JUpload is not an HTTP API: audio and metadata are delivered over SFTP, optionally GPG-encrypted with a public key the provider supplies. Recorded here for completeness because it is a credentialed ingestion path, not an OpenAPI securityScheme. x-gaps: - No self-service credential issuance; every documented path routes through an account manager, so no anonymous or trial token could be obtained to verify the flows live. - No documented token refresh/rotation guidance beyond the two TTLs. - No documented scopes, audiences, or least-privilege model on the realm.