generated: '2026-08-17' method: probed source: https://id.uh.live/realms/uhlive/.well-known/openid-configuration artifact: well-known/allo-media-openid-configuration.json docs: null docs_note: >- The provider publishes NO scopes or permissions reference page. Every scope below was read from the live OIDC discovery document of the Keycloak realm the provider's own documentation names as its token endpoint — not from documentation, and not derived from an OpenAPI (there is none). note: >- This is the most interesting thing recovered from Allo-Media in this pass. The developer documentation states only that you exchange a client_id and client_secret for a token; it never mentions scopes at all. The realm's discovery document exposes a per-product scope model that the docs are silent about, including one scope — `voip-callapi` — for a surface that has no public documentation page whatsoever. Because these come from `scopes_supported` on the realm, they are the scopes the AUTHORIZATION SERVER can issue, not necessarily the scopes any given client is granted or that a given API enforces. Product mappings below are marked with an honest confidence: the names map onto documented product surfaces one-for-one, but no provider documentation confirms the binding. schemes: - name: uhlive_keycloak_realm type: openIdConnect issuer: https://id.uh.live/realms/uhlive discovery: https://id.uh.live/realms/uhlive/.well-known/openid-configuration jwks_uri: https://id.uh.live/realms/uhlive/protocol/openid-connect/certs flows: - flow: clientCredentials tokenUrl: https://id.uh.live/realms/uhlive/protocol/openid-connect/token documented: true note: the only flow the provider's developer docs describe - flow: authorizationCode authorizationUrl: https://id.uh.live/realms/uhlive/protocol/openid-connect/auth tokenUrl: https://id.uh.live/realms/uhlive/protocol/openid-connect/token documented: false note: >- Advertised by the realm but not documented for API consumers; presumably serves the WebApp/Scribr human login rather than API integrations. - flow: deviceCode deviceAuthorizationUrl: https://id.uh.live/realms/uhlive/protocol/openid-connect/auth/device documented: false - flow: password documented: false note: >- Resource-owner password grant is still enabled on the realm. It is deprecated in OAuth 2.1 and generally should be off; flagged as an observation, not an exploit. - flow: refreshToken documented: false - flow: tokenExchange grant: urn:ietf:params:oauth:grant-type:token-exchange documented: false - flow: jwtBearer grant: urn:ietf:params:oauth:grant-type:jwt-bearer documented: false - flow: uma grant: urn:ietf:params:oauth:grant-type:uma-ticket documented: false - flow: ciba grant: urn:openid:params:grant-type:ciba backchannel_authentication_endpoint: https://id.uh.live/realms/uhlive/protocol/openid-connect/ext/ciba/auth documented: false scopes: - scope: activate description: >- Access to the Activate API — the read-only REST surface over processed calls at https://activate.uh.live. product: Allo-Media Activate API api: allo-media-activate-api confidence: high sources: [well-known/allo-media-openid-configuration.json] - scope: stream-h2h description: >- Access to the Stream API for humans (real-time human-to-human transcription over WebSocket) — protocol V1. product: Allo-Media Stream API for Humans api: allo-media-stream-api-humans confidence: high sources: [well-known/allo-media-openid-configuration.json] - scope: stream-h2h-v2 description: >- Access to the Stream API for humans, protocol V2 — the current version. product: Allo-Media Stream API for Humans api: allo-media-stream-api-humans confidence: high note: >- A separate scope per protocol version. That is real evidence the V1/V2 split is enforced at the authorization server, so a V1 client's token will not simply work against V2 — a migration detail the deprecation docs do not mention. sources: [well-known/allo-media-openid-configuration.json] - scope: stream-h2b description: >- Access to the Stream API for voicebots (human-to-bot, MRCP/WebSocket). product: Allo-Media Stream API for Voicebots api: allo-media-stream-api-voicebots confidence: high sources: [well-known/allo-media-openid-configuration.json] - scope: voip-callapi description: >- A VoIP / call API scope with no corresponding public documentation page. product: unknown confidence: low note: >- The only scope that does not map onto a documented product. There is no "call API" or VoIP section anywhere in the documentation sitemap. Recorded as an undocumented surface rather than guessed at — this is a real question to put to the provider, not a finding to publish as a product. sources: [well-known/allo-media-openid-configuration.json] - scope: scribr description: >- Access to Scribr, the hosted search interface over calls and transcripts. product: Scribr confidence: high note: >- Scribr is documented as a product UI with its own search syntax; the scope suggests it is served by an API behind the realm, though no Scribr API is documented. sources: [well-known/allo-media-openid-configuration.json] - scope: service_account description: Machine/service-account identity scope (Keycloak client credentials). category: platform confidence: medium sources: [well-known/allo-media-openid-configuration.json] - scope: app_metadata description: Application metadata claims. category: platform confidence: medium sources: [well-known/allo-media-openid-configuration.json] - scope: basic description: Keycloak built-in basic claims scope. category: standard confidence: high sources: [well-known/allo-media-openid-configuration.json] - scope: openid description: OIDC required scope. category: standard confidence: high - scope: profile category: standard - scope: email category: standard - scope: address category: standard - scope: phone category: standard - scope: roles category: standard - scope: web-origins category: standard - scope: offline_access category: standard - scope: acr category: standard - scope: microprofile-jwt category: standard summary: scopes_total: 19 product_scopes: 6 platform_scopes: 2 standard_oidc_scopes: 11 documented_by_provider: 0 undocumented_product_surfaces: 1 x-security-posture: note: >- Read from the same discovery document. This realm is configured well above the baseline, which is worth recording because it contrasts sharply with the provider's thin API documentation. pkce: [plain, S256] pkce_note: >- S256 supported; `plain` is also still advertised, which is the weaker option OAuth 2.1 removes. token_endpoint_auth_methods: - private_key_jwt - client_secret_basic - client_secret_post - tls_client_auth - client_secret_jwt mtls_client_auth: true mtls_bound_access_tokens: true dpop: true dpop_algs: [PS384, RS384, EdDSA, ES384, ES256, RS256, ES512, PS256, PS512, RS512] introspection_endpoint: https://id.uh.live/realms/uhlive/protocol/openid-connect/token/introspect revocation_endpoint: https://id.uh.live/realms/uhlive/protocol/openid-connect/revoke dynamic_client_registration_endpoint: https://id.uh.live/realms/uhlive/clients-registrations/openid-connect assessment: >- mTLS-bound access tokens, DPoP, private_key_jwt and a dynamic client registration endpoint are all advertised — capabilities most catalogued providers do not offer. They are also Keycloak defaults, so their presence proves the platform supports them, not that Allo-Media requires or documents them. The gap here is documentation, not capability: a customer reading the developer docs would never learn that sender-constrained tokens are an option.