OAuth-Only Authentication

As of v1.0.16, the platform formally hard-disables password-based user registration. This page explains what that means, why it was done, and what you need to know as an operator or developer.

What Changed

The endpoint POST /api/auth/register now returns an HTTP 410 Gone response unconditionally. It will not create users, it will not accept request bodies, and it will not return any data. The response is permanent and intentional.

Additionally, there is no Credentials provider configured in src/platform/auth/providers.ts, meaning there is no email/password login path anywhere in the application — not just registration, but sign-in as well.

Why OAuth-Only?

Managing passwords introduces a class of responsibilities that OAuth delegates to a dedicated identity provider:

• No password storage — The platform never stores, hashes, or rotates user passwords.
• No credential exposure — There is no risk of leaked password hashes from a database breach.
• Reduced attack surface — Brute-force, credential-stuffing, and account-takeover vectors tied to passwords do not apply.
• Centralised identity management — Organisations can enforce their own SSO policies, MFA requirements, and access revocation through their OAuth provider.

How Authentication Works

All users authenticate exclusively through a configured OAuth provider. The auth flow is:

1. User clicks Sign In.
2. User is redirected to the configured OAuth provider (e.g. Google, Microsoft Entra ID, GitHub, etc.).
3. The OAuth provider authenticates the user and returns an authorization code.
4. The platform exchanges the code for tokens, creates or retrieves the user session, and redirects the user into the application.

No passwords are collected or stored at any point.

Impact on Integrations

If any of the following exist in your environment, they must be updated:

• External systems calling POST /api/auth/register — These calls will now receive 410 Gone. Update those integrations to use your OAuth provider's user provisioning APIs instead.
• Email invitation links pointing to /api/auth/register — These links will no longer work. Remove them or replace them with OAuth-based onboarding flows.
• Scripts or automation that create users via the register endpoint — Migrate to provisioning users through your OAuth provider's admin APIs or SCIM integration.

If You Need Password Authentication

Password-based authentication is not supported in the default platform configuration. If your deployment requires it, the following changes are necessary:

1. Add a Credentials provider in src/platform/auth/providers.ts. Refer to the NextAuth.js Credentials provider documentation for implementation guidance.
2. Implement the register endpoint in src/app/api/auth/register/route.ts, including secure password hashing (e.g. bcrypt), input validation, and duplicate-user handling.
3. Review your security posture — enabling password auth reintroduces password storage, reset flows, and related attack vectors that will need to be addressed.

Recommendation: Unless there is a hard business requirement for password authentication, the OAuth-only model is the more secure default and should be maintained.

Endpoint Reference

POST /api/auth/register

Property	Value
Status	Permanently disabled
HTTP Response	410 Gone
Authentication required	No
Request body accepted	No

Example response:

HTTP/1.1 410 Gone

This endpoint will not be re-enabled in future versions without an explicit opt-in configuration change.