A Mosart server runs in one of three modes. They are mutually exclusive, and the choice is a trade-off rather than a progression.
Mode | What guards the REST API | Per-user identity | Roles enforced by the Mosart server | API-key clients |
|---|---|---|---|---|
Default, out of the box | nothing | no | no | not applicable |
API key | one shared secret, sent as | no | no | yes |
OIDC authentication | a token issued by your identity provider | yes | named overlays only, today | no |
The Roles column is for the Mosart server only. The Mosart Web Apps enforce their own roles independently: Showmaker and Smart Panel gate their APIs on the Web Apps server whether or not the Mosart server uses OIDC. On the Mosart server, the playout surfaces, meaning the SignalR hub and the timeline, fader, devices and settings APIs, accept any signed-in user, so a user holding no Mosart role can still take things on air.
The last column is what usually decides the mode. Enabling OIDC turns the API key off, so a single Mosart server cannot serve a signed-in browser user and an API-key integration at the same time.
Which to choose:
API key if you have integrations that call the Mosart REST API directly and cannot obtain a token: the Elgato Stream Deck plugin, or your own scripts without an OAuth flow. You keep those integrations and give up role enforcement. A Generic REST device no longer forces this choice, since it can sign in with the Client credentials grant.
OIDC if what matters is that the people using the web apps are identified, and that a viewer cannot change named overlays by calling the API directly.
Do you need the Mosart Web Apps?
It depends on which part of this chapter you are following.
For HTTPS and the API key, no. Both are settings on the Mosart server, and they work with no Web Apps installed.
For OIDC sign-in, yes in practice. The Mosart Web Apps are what sign the user in, hold the session, and pass the resulting access token to the browser apps.
The Mosart server itself is not fussy about where a token comes from. It validates any token issued by the configured authority, and needs nothing from the Web Apps to do that. In a server-only installation, something else has to obtain the token: a Generic REST device using the Client credentials grant can, and so can your own integrations that perform an OAuth flow. Browser sign-in always needs the Web Apps.
Third-party integrations and the REST API
Anything that calls the Mosart REST API is affected by the mode you choose.
With the API key. The integration sends X-API-Key with the value from Remote Controller Service > Security. Simple, and it works from anywhere that can reach the server. The key identifies no user, carries no role, and is the same key for every caller, so nothing in the audit trail says who did what.
With OIDC. The integration has to obtain an access token from your identity provider and send it as Authorization: Bearer <token>. The Mosart server validates it against the configured authority. To create, change or delete named overlays, that token must carry mosart-admin in its roles claim, exactly as a user's token does. An integration that cannot perform an OAuth flow cannot use this mode.
For health checks, use GET /status, which needs no credential in either mode.
Known integration limits
Integration | With the API key | With OIDC |
|---|---|---|
Your own scripts and panels | Works | Works, if they can obtain a token |
Works | Not yet. It authenticates with an API key only and has no sign-in flow. | |
Generic REST device pointed at Mosart's own REST API | Works | Works, from Viz Mosart 5.16. Set the device's authentication type to OAuth2 with the Client credentials grant, so it signs in as its own service account. See the example on Generic REST Drivers. Earlier versions offered only the API key, or a password grant that an OIDC provider will not normally accept. |
The Stream Deck plugin is a Vizrt component, so this is a current client limitation rather than a design decision. The Mosart server itself accepts a valid token from any caller; what the plugin lacks is a way to obtain one.
Info: A device token carries the roles assigned to its service account, not a person's. For a Generic REST device to change named overlays, IT assigns mosart-admin to the client created for it, as described in Identity Provider and Certificates.
Note: The Stream Deck plugin also requires the Mosart Web Apps. Its Mosart Url setting points at the Web Apps host, and it reaches the Mosart server through the proxy rather than directly, so it is not an option for a server-only installation.
Info: A Generic REST device that calls a third-party service is unaffected by any of this. The limitation applies only when Viz Mosart controls Viz Mosart through its own REST API.
What works when OIDC is enabled
Feature or integration | With OIDC enabled |
|---|---|
Named Overlays Editor | Works, with roles enforced. |
Status endpoints, | Work, and need no credential. Monitoring keeps working. |
Mosart SignalR hub | Works. The token is passed as an |
Playout REST API ( | Works for any signed-in user. No role check. |
Any client sending the REST API key | Refused with 401. The key is ignored while OIDC is on. |
A Generic REST device pointed at Mosart's own REST API | Works, with the Client credentials grant, from Viz Mosart 5.16. |
Elgato Stream Deck plugin | Not yet, apart from its status check. |