Red5 Authentication

generated: '2026-09-04'
method: searched
source: openapi/red5-admin-api-openapi.yml, openapi/red5-file-restreamer-api-openapi.yml, openapi/red5-images-api-openapi.yml,
  openapi/red5-inputs-api-openapi.yml, openapi/red5-mixers-api-openapi.yml, openapi/red5-provision-api-openapi.yml,
  openapi/red5-proxy-api-openapi.yml, openapi/red5-rtmp-restreamer-api-openapi.yml, openapi/red5-servlet-configuration-api-openapi.yml,
  openapi/red5-streams-api-openapi.yml
summary:
  types:
  - apiKey
  - http
  api_key_in:
  - query
schemes:
- name: bearerAuth
  type: http
  scheme: bearer
  bearerFormat: JWT
  description: JWT bearer token for authenticating Stream Manager API requests
  sources:
  - openapi/red5-admin-api-openapi.yml
  - openapi/red5-provision-api-openapi.yml
  - openapi/red5-proxy-api-openapi.yml
  - openapi/red5-streams-api-openapi.yml
- name: accessToken
  type: apiKey
  in: query
  parameter: accessToken
  description: API access token for authenticating Restreamer API requests
  sources:
  - openapi/red5-file-restreamer-api-openapi.yml
  - openapi/red5-images-api-openapi.yml
  - openapi/red5-inputs-api-openapi.yml
  - openapi/red5-mixers-api-openapi.yml
  - openapi/red5-rtmp-restreamer-api-openapi.yml
  - openapi/red5-servlet-configuration-api-openapi.yml
docs: https://www.red5.net/docs/red5-pro/users-guide/authentication/
docs_additional:
- https://www.red5.net/docs/red5-cloud/users-guide/authentication/
- https://www.red5.net/docs/red5-cloud/users-guide/authentication/red5-cloud-digest-token-authentication/
- https://www.red5.net/docs/red5-cloud/users-guide/authentication/red5-cloud-round-trip-authentication/
- https://www.red5.net/docs/red5-pro/development/api/authentication/
- https://www.red5.net/docs/red5-cloud/development/sdks/backend-sdk/
note: Upgraded from derived to searched 2026-09-04. The two OpenAPI-declared schemes below cover only
  the control plane. Red5's real authentication story has a second half the specs do not carry — the MEDIA
  PLANE, where publish/subscribe credentials travel in the client SDK's connectionParams (username / password
  / token) rather than in an HTTP header, and where the mechanism differs between the self-hosted and
  managed products.
media_plane:
  red5_pro_self_hosted:
  - name: Round Trip Authentication
    class: RoundTripAuthValidator
    description: Red5 asks a customer-operated remote validation service to authorize each publish or
      subscribe request; the service returns a JSON result. Clients missing username/password/token entirely
      are rejected at connect time, before the round trip fires. Publishers and subscribers are authenticated
      distinctly by role.
    docs: https://www.red5.net/docs/red5-pro/users-guide/authentication/
  - name: JWT Authentication
    class: JwtAuthenticator
    description: RFC 7519 tokens validated LOCALLY with standard libraries and signatures — no remote
      call per request. Validates expiration, issuer, roles, transport restrictions and room restrictions.
    standard: RFC 7519
  - name: Simple Authentication
    plugin: red5pro-simple-auth-plugin
    description: Connection-level (not action-level) username/password checking for RTMP, RTSP and WebRTC
      clients. Configurable per webapp via red5-web.xml or globally via simple-auth-plugin.credentials
      in RED5_HOME/conf, and tunable independently per connection type.
  red5_cloud_managed:
  - name: Round Trip Authentication (Cloud)
    description: Same concept as standalone, but wired up per node group in the Red5 Cloud UI by pointing
      at a validation server URL instead of editing red5-web.xml. Requires a node image built with the
      Simple Auth plugin. The validator implements validateCredentials / invalidateCredentials HTTP POST
      endpoints.
  - name: Digest Token Authentication
    cloud_only: true
    description: 'Self-contained cryptographically signed token — no callback to an external server. Seven
      colon-separated fields: stream:user:role:key1=value1:app:expiration:digest, where stream is the
      SHORT stream id (stream1, not live/stream1), role is streamer or viewer, expiration is a Unix timestamp,
      and digest is sha256(payload + ":" + secret) as 64-char lowercase hex over the first six fields.
      Configured per node group in the Cloud UI (Digest Algorithm SHA-256 plus the shared secret).'
    common_failure: A secret mismatch between the Cloud UI and the token generator rejects every connection.
  transport_note: 'On WebRTC/WHIP/WHEP the credential is passed through the SDK''s connectionParams init
    property — connectionParams: { username, password, token } — not a query string. The WHIP/WHEP endpoint
    uses the FULL stream path (/live/stream1) while a Digest Token''s stream field uses only the short
    id (stream1).'
token_minting:
  backend_sdks:
  - red5-bcs-node (npm, published)
  - net.red5:red5-bcs-java (documented, not on Maven Central)
  - github.com/red5pro/red5-bcs-go (documented, module not public)
  description: 'Red5 Cloud Backend SDKs mint short-lived role-scoped tokens server-side from a master
    key and master secret: getConferenceToken(userId, roomId, role, expirationMinutes) with role admin
    / publisher / subscriber, and getChatToken(userId, channelId, read, write, ttlMinutes). Red5 documents
    these as a separate mechanism from the standalone JwtAuthenticator path.'
  guidance:
  - Store master credentials in environment variables, never in client code.
  - Never generate tokens on the client.
  - Use HTTPS.
  - Keep token lifetimes short.
  - Validate users before issuing tokens.
oauth2:
  supported: false
  evidence: derive-oauth-scopes.py 2026-09-04 found 0 oauth2 schemes and 0 scopes across all ten specs;
    /.well-known/openid-configuration 404s on every Red5-owned host.