OpenID Connect (OIDC)

fDeploy Server supports OpenID Connect (OIDC) in two ways:

1. External identity provider — Users can sign in via an external provider such as Microsoft Entra ID, Auth0, Okta, or any OIDC-compliant identity provider
2. Built-in OIDC server — fDeploy Server also acts as its own OIDC server (powered by OpenIddict) for API client integrations

External identity provider

How it works

When configured, an additional sign-in button appears on the login screen (e.g., “Sign in with Microsoft Entra ID”). Clicking this button redirects the user to the external identity provider for authentication. After successful authentication, the provider redirects back to fDeploy Server, which automatically provisions a user account and signs the user in with a session cookie.

The entire OIDC flow is handled server-side using the Authorization Code flow. The SPA does not need to handle tokens or redirects — it simply navigates to the external login endpoint and waits for the session cookie.

Configuration

External OIDC authentication is configured in the fDeploy Server appsettings.json file:

"OidcSettings": {
  "Enabled": true,
  "DisplayName": "Microsoft Entra ID",
  "Authority": "https://login.microsoftonline.com/{tenant-id}/v2.0",
  "ClientId": "your-application-client-id",
  "ClientSecret": "your-client-secret"
}

Setting	Description
Enabled	Set to true to enable external OIDC authentication. When false, the OIDC sign-in option is hidden from the login screen
DisplayName	The label shown on the sign-in button (e.g., “Microsoft Entra ID”, “Auth0”, “Okta”)
Authority	The OIDC authority URL of your identity provider
ClientId	The application (client) ID registered with your identity provider
ClientSecret	The client secret for the registered application. Once saved, the client secret is masked and cannot be retrieved from the server

Setting up your identity provider

When registering fDeploy Server as an application in your identity provider, configure the following redirect URI:

https://your-fdeploy-server/signin-oidc

Replace your-fdeploy-server with the actual hostname of your fDeploy Server instance.

Microsoft Entra ID

1. Go to the Azure Portal → Microsoft Entra ID → App registrations
2. Select New registration
3. Set the redirect URI to https://your-fdeploy-server/signin-oidc (type: Web)
4. Under Certificates & secrets, create a new client secret
5. Copy the Application (client) ID, Directory (tenant) ID, and the client secret value
6. Configure appsettings.json with authority https://login.microsoftonline.com/{tenant-id}/v2.0

Auth0

1. Go to Applications → Applications in the Auth0 Dashboard
2. Create a new Regular Web Application
3. Set the Allowed Callback URL to https://your-fdeploy-server/signin-oidc
4. Set the Allowed Logout URL to https://your-fdeploy-server/
5. Copy the Domain, Client ID, and Client Secret
6. Configure appsettings.json with authority https://your-domain.auth0.com

Signing in

1. Navigate to fDeploy Server in your browser
2. Click Sign in with {DisplayName} (the button text matches the configured DisplayName)
3. You will be redirected to the external identity provider
4. After authenticating, you are redirected back to fDeploy Server and signed in

User provisioning

When a user signs in via an external OIDC provider for the first time, fDeploy Server automatically creates a local user account linked to their external identity. The user’s name, display name, and email are populated from the claims returned by the identity provider.

OIDC users appear in the user management area with OIDC as their authentication source. Administrators can assign roles to OIDC users through the user management interface.

Note

Passwords are not managed by fDeploy for OIDC users. Authentication is always delegated to the external identity provider.

Built-in OIDC server

fDeploy Server also acts as an OpenID Connect server, exposing standard OIDC endpoints for API client integrations:

Endpoint	Path
Authorization	/connect/authorize
Token	/connect/token
User Info	/connect/userinfo

Supported flows

• Authorization Code Flow with PKCE — the recommended flow for browser-based applications. PKCE (Proof Key for Code Exchange) is required for all authorization code grants.
• Client Credentials Flow — for machine-to-machine communication and API integrations
• Refresh Token Flow — for obtaining new access tokens without re-authentication

Registered scopes

Scope	Description
openid	Required for OpenID Connect
profile	User profile information
email	User email address
roles	User role assignments
offline_access	Enables refresh tokens

Security

• PKCE is enforced for all authorization code grants to prevent authorization code interception attacks
• Tokens are signed using the fDeploy Server certificate from the certificate store
• Access tokens have a limited lifetime and can be refreshed using refresh tokens