Proposal: single sign-on (SSO) for the AerolVM API and dashboard

[sumansaurabh]

The problem

Today, every AerolVM server has one API token, the operator token (SB_PAT_TOKEN). The SDKs and the aerolvm CLI send it, and so do MCP clients. The dashboard asks you to paste it into the browser. So everyone who uses the server shares one secret, and removing one person means changing the token for everyone.

What you can do today

Keep the token in a secret manager, and hand it only to services, not people. Put the dashboard and API behind your own login proxy, and keep port 21212 private.

A starting shape

• Sign in with OpenID Connect (OIDC) first, since Okta, Entra ID, Google and Keycloak all speak it. SAML could come later if people need it.
• aerolvm login opens the browser and saves a short-lived token instead of the operator token.
• The dashboard signs you in with your company account, so no one pastes the operator token.
• The operator token stays, for automation and for recovery.

This depends on scoped tokens and roles, because a signed-in person needs a role.

Questions for you

1. Which identity provider do you use?
2. Is the dashboard, the CLI or the SDK the place you most need SSO?
3. Do you need SAML, or is OIDC enough?
4. Do you need groups from your identity provider mapped to roles?

How to weigh in

React with 👍 if you need this, and comment with your answers.

Want to talk it through? Book a call with the maintainer, or join the community call on the first Saturday of every month at 8 pm Pacific Time.

If your company needs this soon, you can sponsor the work. It is built in the open and ships to everyone.

[sumansaurabh]

Thanks for proposing this. It shipped in v0.6.8, together with scoped
tokens and roles (#646) and caller identity in audit records (#649).

How it works:

• People sign in with your company account through any OIDC provider:
  Okta, Entra ID, Google, Keycloak and others. In a terminal,
  aerolvm login https://<your-server> opens the browser (or --device over
  SSH). In the dashboard, a "Sign in with " button appears.
• AerolVM never sees a password and keeps no session. Your provider signs
  a short-lived token, and every AerolVM server checks that signature with
  the provider's public keys. There is no login service, no shared session
  store, and no client secret on the server. It is the same model as the
  Kubernetes API server's --oidc-issuer-url.
• Roles come from your groups. An identity file maps provider groups (or
  Entra app roles, or any claim) to a role and a team. It is a plain YAML
  file, so you can keep it in Git, and every change writes an audit record.
• CI needs no stored secret. GitHub Actions and Kubernetes service account
  tokens are checked the same way.
• Removing someone: remove them at your provider, and their access ends
  when their last sign-in expires (about an hour). For an instant block, add
  them to the identity file's deny list.
• MCP connectors (claude.ai, ChatGPT) can sign in with OAuth against your
  provider. We document a provider and connector pair only after a manual live
  check passes, and none has passed yet, so treat this part as unverified for
  now. The runbook records each run.

Docs:

• Setup and identity file: https://microvm.aerol.ai/enterprise/sso/
• CLI sign-in: https://microvm.aerol.ai/cli/#save-your-login
• Dashboard sign-in: https://microvm.aerol.ai/dashboard/

Not in this release: SAML and SCIM. Every provider we target speaks OIDC. A
SAML-only provider can be bridged through Keycloak or Dex, and leavers are
removed at the provider. If SCIM matters for your rollout, please tell us
below.