entra app setup - Alshival-Ai/neural-labs GitHub Wiki

Enable Microsoft sign-in

Microsoft integration is optional. Neural Labs does not call Microsoft Graph to create or mutate an app registration; an Entra administrator performs these steps manually and then places the resulting values in the ignored root .env.

Use a single-tenant app registration for Neural Labs web login. Replace https://neural-labs.example.com with the instance's final HTTPS origin. Personal deployments can keep local email/password login and skip this guide.

Public MCP is disabled. You do not need to expose an API, add an mcp.access scope, enable public-client flows, or register a Codex callback for web sign-in. The retained future public MCP reference is separate.

1. Create the registration

In Microsoft Entra admin center → App registrations, create a registration for accounts in this organizational directory only. Record:

  • Directory (tenant) ID;
  • Application (client) ID.

Do not put either value in a public example file even though they are not passwords; deployment-specific identifiers still belong in instance state.

2. Add the web redirect

Under Authentication → Web, add exactly:

https://neural-labs.example.com/auth/microsoft/callback

Do not enable implicit ID-token or access-token grants. Neural Labs uses the authorization-code flow, PKCE, state, and nonce.

3. Create the confidential-client credential

Choose one method:

Certificate (preferred)

Create a certificate and keep its private key on the Neural Labs host. Upload only the public certificate under Certificates & secrets → Certificates. The Neural Labs credential must be a PEM bundle containing that certificate and the matching private key. Protect the bundle with mode 0600, encode it into the root .env, then remove the staging copy when it is no longer needed.

If the source is a PFX file, create a temporary PEM bundle with OpenSSL:

openssl pkcs12 -in neural-labs.pfx -clcerts -nodes -out neural-labs-credential.pem
chmod 0600 neural-labs-credential.pem
openssl base64 -A -in neural-labs-credential.pem

Place the single-line output in AZURE_CLIENT_CERTIFICATE_BASE64. That value and the original PEM contain private-key material and must be handled as secrets.

Client secret

Create a client secret under Certificates & secrets → Client secrets and copy its value immediately into AZURE_CLIENT_SECRET in the root .env; do not store it in Git or a shell profile. Record its expiry in the operator's secret-management system so it can be rotated before expiration.

4. Complete Neural Labs configuration

Set the final public origin, intended administrator email, tenant ID, client ID, authority host (https://login.microsoftonline.com for the public cloud), and one credential in the root .env. Set NEURAL_LABS_MICROSOFT_AUTH_ENABLED=true, keep NEURAL_LABS_MCP_ENABLED=false, and run bin/neural-labs up for an initial installation. On an already configured instance, use Settings → Authentication to save the credential and enable Microsoft: saved settings override .env. Microsoft buttons appear automatically when an effective credential exists and Microsoft web login is enabled.

After the first administrator signs in, rotate credentials and provider switches from the administrator-only Settings app inside /workspace. Saved configuration overrides environment fallback values.

5. Verify sign-in before changing local access

Open /login in a separate browser session and choose Microsoft. Confirm the expected tenant and approved Neural Labs identity. The configured initial administrator email controls first-account claiming for Microsoft too; other new users remain pending until approved.

Existing local users should link Microsoft from Settings → Security while signed in. Matching email addresses do not automatically merge identities. Keep local login available until an active administrator has linked and tested Microsoft. You can then enroll a passkey.