---
title: "Authentication and Authorization"
description: ""
---
NeMo Platform includes a built-in security layer that lets you control who can access your platform and what they can do. When multiple teams or users share a NeMo Platform deployment, authentication and authorization ensure that each user sees only the workspaces and resources they are permitted to access, and can only perform actions appropriate to their role.

Access control has two layers:

-   **Authentication** — Prove your identity. NeMo Platform validates a JWT issued by your OpenID Connect (OIDC) identity provider.
-   **Authorization** — Control what you can do. Workspace-scoped RBAC with roles (Viewer, Editor, Admin) and optional API scopes on tokens.

Both layers are opt-in. When `auth.enabled` is `false` (the default), all requests are allowed without checks. This lets you get started quickly and add security when you are ready for multi-user or production deployments.

## How Authentication Works

NeMo Platform authenticates every request using a JWT from your OIDC identity provider. The token is sent in the `Authorization: Bearer <token>` header, and NeMo Platform validates the signature, issuer, audience, and expiry. Refer to [OIDC Setup](/documentation/access-control/authentication/oidc-setup) to connect your identity provider.

How you **obtain** the token depends on your context:

-   **CLI** — Run `nemo auth login` to authenticate using the browser-based device flow. The CLI stores and auto-refreshes the token. Refer to [Using Authentication](/documentation/access-control/authentication/using-authentication).
-   **SDK** — After `nemo auth login`, the Python SDK automatically reads stored tokens from the CLI config and refreshes them transparently. Refer to [Using Authentication](/documentation/access-control/authentication/using-authentication#python-sdk).
-   **HTTP** — For raw HTTP calls, fetch a token from your IdP (or from the CLI using `nemo auth token`) and pass it in the `Authorization: Bearer <token>` header.
-   **Studio** — When auth is enabled, Studio automatically redirects you to your IdP to sign in and uses the resulting token for all API calls.

<Tip>

**Quickstart shortcut** — When running NeMo Platform quickstart without an OIDC provider, you can use an unsigned JWT:

`nemo auth login --unsigned-token --email <email>`

Quickstart-generated unsigned tokens expire after 24 hours.

Unsigned JWT login only works for quickstart and must not be used in production. See [Getting Started](#quickstart-development) below.

</Tip>
## Getting Started

### Quickstart / Development

#### Step 1: Enable Authorization

Run `nemo quickstart configure` and select **Configure advanced options** → **Yes** for authentication. Provide an admin email — it receives the **PlatformAdmin** role with full platform access.

```bash
$ nemo quickstart configure
# Select: Configure advanced options → Enable authentication → Yes
# Enter admin email: admin@example.com
```

<Accordion title="Full quickstart configure output">

```text
NeMo Platform Quickstart Configuration
...
Step 3 of 3: Save Config
Save configuration?
1. Save configuration
> 2. Configure advanced options - authentication, ports, registry

• Platform Authorization
Enable auth to require authentication for API requests.
When enabled, you can set an admin email to bootstrap access.

Enable authentication/authorization?
1. No - Allow all requests without authentication
> 2. Yes - Require authentication for API access

✓ Authorization enabled

Admin email (grants PlatformAdmin role): admin@example.com
✓ Admin: admin@example.com

ℹ All CLI requests will be authenticated as admin@example.com.
To use a different identity: nemo auth login --unsigned-token --email <email>
...
✓ Configuration saved successfully!
```

</Accordion>
The CLI is automatically configured to authenticate as the admin email for all subsequent commands after setup. To switch identity, run:

`nemo auth login --unsigned-token --email <email>`.

#### Step 2: Make Authenticated Calls

After authorization is enabled, all API requests must include an identity. The CLI and SDK are already configured after Step 1 — they read the admin email from the CLI config automatically.

<Tabs>

<Tab title="CLI">

```bash
# CLI is already configured after quickstart configure
# All commands are authenticated as the admin
nemo workspaces list

# To use a different identity:
nemo auth login --unsigned-token --email other-user@example.com
```

</Tab>
<Tab title="Python SDK">

```python
from nemo_platform import NeMoPlatform

# No arguments needed — the SDK reads base_url, workspace, and credentials
# from the active CLI context (set by `nemo auth login` or `nemo quickstart configure`).
# See: Initializing the CLI and SDK in the quickstart for other init options.
client = NeMoPlatform()

workspaces = client.workspaces.list()
print(f"Found {len(workspaces.data)} workspaces")
```

</Tab>

</Tabs>
### Production / Helm Deployment

For production or Helm-based deployments, enable auth by setting `platformConfig.auth.enabled: true` in your Helm values and configure the `auth:` section in platform config. Refer to [Auth Configuration](/documentation/access-control/deployment/configuration) for the full reference and [OIDC Setup](/documentation/access-control/authentication/oidc-setup) to connect your identity provider.

## Where to Go Next

<Cards>

<Card title="Security Model" href="/documentation/access-control/security-model">

Understand how NeMo Platform authentication and authorization work together — trust boundaries, principal model, and authorization layers.

</Card>
<Card title="Connect an Identity Provider" href="/documentation/access-control/authentication/oidc-setup">

Configure NeMo Platform to authenticate users using your OIDC identity provider.

</Card>
<Card title="Manage Workspace Access" href="/documentation/access-control/authorization/managing-access">

Add users to workspaces, assign roles, and control who can access your resources.

</Card>
<Card title="Configuration Reference" href="/documentation/access-control/deployment/configuration">

Full configuration reference — enabling auth, PDP provider, OIDC settings, environment variables.

</Card>
<Card title="Harden for Production" href="/documentation/access-control/deployment/production-hardening">

Security checklist for production deployments — OIDC, gateway headers, scoped tokens, TLS.

</Card>
<Card title="Troubleshooting" href="/documentation/access-control/troubleshooting">

Fix common auth issues — 401/403 errors, login failures, role propagation delays.

</Card>

</Cards>
