Authentication

Studio does not have a separate authentication system.

Runiq Studio runs inside your ASP.NET Core application and evaluates the HttpContext.User created by that host. This means Studio access should be controlled with the same authentication and authorization setup you already use in your application.

For local development you can allow anonymous access, but production applications should protect Studio because it exposes runtime details such as registered agents, tool contracts, workflows, Context Spaces, and debugging information.

Require an authenticated user

Use RequireAuthenticatedUser() when every signed-in application user is allowed to access Studio.

app.UseRuniqDashboard(options =>
{
    options.Path = "/dashboard";
    options.Title = "Runiq Dashboard";

    options.Authentication(auth =>
    {
        auth.RequireAuthenticatedUser();
    });
});

With this configuration, anonymous requests are handled by the host application's authentication middleware. For example, if your app uses cookie authentication, anonymous users can be redirected to your login page before Studio is shown.

Require a role

Use RequireRole(...) when Studio should be limited to users with a specific role.

app.UseRuniqDashboard(options =>
{
    options.Path = "/dashboard";
    options.Title = "Runiq Dashboard";

    options.Authentication(auth =>
    {
        auth.RequireRole("Admin");
    });
});

Runiq does not define its own role store. RequireRole("Admin") checks the role claims already present on the authenticated HttpContext.User.

For example, a user with this claim can access Studio when RequireRole("Admin") is configured:

new Claim(ClaimTypes.Role, "Admin")

A signed-in user without the required role is rejected by the host application's authorization behavior.

Host authentication still matters

The Studio authentication option only declares what Studio requires. Your ASP.NET Core application still needs to configure authentication and authorization middleware.

For cookie authentication, the host setup commonly looks like this:

builder.Services
    .AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
    .AddCookie(options =>
    {
        options.LoginPath = "/login";
        options.LogoutPath = "/logout";
        options.AccessDeniedPath = "/access-denied";
    });

builder.Services.AddAuthorization();

The middleware must run before Studio is mapped:

app.UseAuthentication();
app.UseAuthorization();

app.UseRuniqDashboard(options =>
{
    options.Authentication(auth =>
    {
        auth.RequireAuthenticatedUser();
    });
});

Production guidance

In production, avoid auth.AllowAnonymous() unless Studio is protected by another trusted boundary.

Prefer one of these access models:

• RequireAuthenticatedUser() for internal applications where every signed-in user may inspect Studio,
• RequireRole("Admin") for admin-only access,
• a stricter authorization setup in the host application when Studio should be limited to operations, platform, or developer teams.

Use your normal identity provider, user store, role source, HTTPS policy, cookie settings, logging, auditing, and operational access controls. Studio should be treated like an internal developer or administration surface, not a public product UI.