Skip to main content
Anchor provides flexible system settings that control user registration, authentication methods, and access policies. These settings allow you to customize Anchor for different deployment scenarios.

Registration Settings

Registration Modes

Anchor supports three registration modes:

Enabled

Anyone can register and immediately access the system

Review

New registrations require admin approval before access

Disabled

New user registration is completely disabled

Viewing Registration Settings

Get the current registration configuration:
GET /api/admin/settings/registration
Response:
{
  "mode": "review"
}
The mode field indicates the current registration policy.

Updating Registration Mode

Change the registration mode:
PATCH /api/admin/settings/registration
Request Body:
{
  "mode": "review"
}
Valid Values:
  • "enabled" - Open registration
  • "review" - Requires admin approval
  • "disabled" - No new registrations
Response:
{
  "mode": "review"
}
The registration mode only affects new registrations. Existing users can continue to log in regardless of the setting.

Registration Mode Details

Enabled Mode

1

User Registers

User fills out registration form with email, password, and name.
2

Account Created

Account is created with status: active immediately.
3

Instant Access

User can log in right away without waiting for approval.
Use Cases:
  • Public Anchor instances
  • Internal company deployments with trusted networks
  • Personal or family instances
With open registration, anyone who can access your Anchor instance can create an account. Ensure this aligns with your security requirements.

Review Mode

1

User Registers

User submits registration with email, password, and name.
2

Pending Status

Account is created with status: pending.
3

Admin Reviews

Admins see the pending registration in the admin panel.
4

Approval Decision

Admin approves or rejects the registration.
5

Access Granted/Denied

Approved users can log in; rejected users are deleted.
Use Cases:
  • Private communities or organizations
  • Instances requiring identity verification
  • Controlling system growth and resource usage
Review mode provides a balance between accessibility and control. Users can self-register, but admins maintain oversight.

Disabled Mode

1

Registration Blocked

The registration form is disabled or returns an error.
2

Admin Creates Users

Only admins can create new user accounts manually.
3

Controlled Access

Every user is explicitly created by an admin.
Use Cases:
  • Fully private instances
  • Organizations with strict access control
  • Migration scenarios where you’re importing existing users
With registration disabled, you must manually create accounts for all users via the admin API.

OpenID Connect (OIDC) Settings

Anchor supports OIDC for single sign-on with external identity providers.

Viewing OIDC Configuration

GET /api/admin/settings/oidc
Response:
{
  "enabled": true,
  "providerName": "Okta",
  "issuerUrl": "https://example.okta.com",
  "clientId": "abc123xyz",
  "hasClientSecret": true,
  "disableInternalAuth": false
}
Fields:
  • enabled: Whether OIDC authentication is active
  • providerName: Display name for the identity provider
  • issuerUrl: OIDC issuer/discovery URL
  • clientId: OAuth 2.0 client identifier
  • hasClientSecret: Whether a client secret is configured (actual secret is never returned)
  • disableInternalAuth: Whether local username/password login is disabled

Updating OIDC Settings

PATCH /api/admin/settings/oidc
Request Body:
{
  "enabled": true,
  "providerName": "Okta",
  "issuerUrl": "https://example.okta.com",
  "clientId": "abc123xyz",
  "clientSecret": "super-secret-value",
  "disableInternalAuth": false
}
All Fields Optional:
FieldTypeDescription
enabledbooleanEnable/disable OIDC authentication
providerNamestringProvider display name (e.g., “Google”, “Okta”)
issuerUrlstringOIDC issuer URL (must be valid URL)
clientIdstringOAuth 2.0 client ID
clientSecretstringOAuth 2.0 client secret
clearClientSecretbooleanSet to true to remove the stored secret
disableInternalAuthbooleanDisable local password authentication
Response:
{
  "enabled": true,
  "providerName": "Okta",
  "issuerUrl": "https://example.okta.com",
  "clientId": "abc123xyz",
  "hasClientSecret": true,
  "disableInternalAuth": false
}

OIDC Configuration Steps

1

Configure Your Identity Provider

Set up an OAuth 2.0 / OIDC application in your identity provider (Google, Okta, Auth0, etc.).Configure the redirect URI to:
https://your-anchor-instance.com/auth/oidc/callback
2

Obtain Credentials

Get the following from your identity provider:
  • Issuer URL (discovery endpoint)
  • Client ID
  • Client Secret
3

Update Anchor Configuration

Use the PATCH endpoint to configure OIDC settings:
curl -X PATCH https://anchor.example.com/api/admin/settings/oidc \
  -H "Authorization: Bearer YOUR_JWT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "enabled": true,
    "providerName": "Your Provider",
    "issuerUrl": "https://provider.com",
    "clientId": "your-client-id",
    "clientSecret": "your-client-secret"
  }'
4

Test Authentication

Verify that users can log in via OIDC. Check that user accounts are created with the correct email and name.

Managing Client Secrets

Updating the Secret: Simply include the new clientSecret in your PATCH request:
{
  "clientSecret": "new-secret-value"
}
Clearing the Secret: To remove the stored client secret:
{
  "clearClientSecret": true
}
The client secret is stored securely and never returned by the API. The hasClientSecret boolean indicates whether one is configured.

Disabling Internal Authentication

When you set disableInternalAuth: true:
  • Local username/password login is disabled
  • Users can only authenticate via OIDC
  • Admin users may still have fallback access (check your deployment configuration)
Before disabling internal authentication, ensure OIDC is properly configured and tested. Otherwise, you may lock yourself out of the system.
Recommended Approach:
1

Configure OIDC

Set up OIDC with enabled: true and disableInternalAuth: false.
2

Test Thoroughly

Verify that OIDC login works correctly for your users.
3

Keep Local Backup

Ensure at least one admin account has a working password.
4

Disable Internal Auth

Only after confirming OIDC works, set disableInternalAuth: true.

Authentication Method Indicators

When listing users, the API indicates how each user authenticated:
{
  "id": "user-123",
  "email": "[email protected]",
  "authMethod": "oidc"
}
Auth Methods:
  • "local": User registered with email/password
  • "oidc": User authenticated via OIDC provider
The auth method is determined by the presence of an oidcSubject field (server/src/admin/admin.service.ts:82).

Configuration Examples

Open Public Instance

{
  "registration": {
    "mode": "enabled"
  },
  "oidc": {
    "enabled": false
  }
}
Anyone can register with email/password and access the system immediately.

Private Organization (OIDC Only)

{
  "registration": {
    "mode": "disabled"
  },
  "oidc": {
    "enabled": true,
    "providerName": "Company SSO",
    "issuerUrl": "https://sso.company.com",
    "clientId": "anchor-client",
    "disableInternalAuth": true
  }
}
Users can only authenticate via company SSO. No self-registration or local passwords.

Moderated Community

{
  "registration": {
    "mode": "review"
  },
  "oidc": {
    "enabled": false
  }
}
Users can register, but admins must approve before they can access the system.

Hybrid Authentication

{
  "registration": {
    "mode": "enabled"
  },
  "oidc": {
    "enabled": true,
    "providerName": "Google",
    "issuerUrl": "https://accounts.google.com",
    "clientId": "google-client-id",
    "disableInternalAuth": false
  }
}
Users can choose to register with email/password or authenticate via Google SSO.

Security Recommendations

Use HTTPS

Always run Anchor over HTTPS, especially when using OIDC or collecting passwords

Secure Client Secrets

Store OIDC client secrets securely and rotate them periodically

Review Pending Users

Regularly check and process pending registrations in review mode

Test Before Disabling

Thoroughly test OIDC before disabling internal authentication

Next Steps

User Approval

Learn how to manage pending user registrations

Admin Panel

Explore all admin panel capabilities

Build docs developers (and LLMs) love