Allo-Media secures its APIs with oauth2, openIdConnect, and http across 5 declared security schemes, as derived from its OpenAPI definitions. OAuth 2.0 is offered via the clientCredentials flow(s).
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.