Authentication

Studio evaluates HttpContext.User from your application. It does not create a separate user store or login system.

Choose one access mode

An access mode is required. Select one per dashboard configuration.

Configure the host first

This example uses cookie authentication and restricts Studio to an Admin role. The application must implement its own login and access-denied pages and issue authenticated identities.

using Microsoft.AspNetCore.Authentication.Cookies;
using Runiq.AI.Core;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRuniqServer();
builder.Services
    .AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
    .AddCookie(options =>
    {
        options.LoginPath = "/login";
        options.AccessDeniedPath = "/access-denied";
    });
builder.Services.AddAuthorization();

var app = builder.Build();
app.UseAuthentication();
app.UseAuthorization();

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

app.Run();

Authentication middleware must run before Studio evaluates the user. Configuring RequireRole does not issue roles; it checks the host identity's existing role claims.

Understand denied requests

For an anonymous request, Studio calls the host's authentication challenge when a default scheme is available; otherwise it returns HTTP 401.

For a signed-in user who lacks access, Studio calls the host's forbid handler when available; otherwise it returns HTTP 403. Redirects or response codes then depend on the authentication handler and request. Do not assume every failed request redirects to a login page.

Check the boundary

The configured Studio path and its inspection APIs use this access check. A separate application endpoint or MCP route needs its own host policy.

Test an anonymous request, an authenticated user without the required role, and an authorized user. Protect the surface according to the operations and runtime data it exposes.