SSO with Duo (OIDC)

This guide walks through configuring Duo Single Sign-On as the identity provider for ProxCenter using OIDC. It complements the generic LDAP & OIDC page with Duo-specific values, screens, and the pitfalls customers most often hit.

It assumes you already have a Duo administrator account and that Duo Single Sign-On is enabled on your tenant. Duo SSO is included with Duo Premier and Duo Advantage; Duo Free / Duo Essentials do not include it.

Before you start

Two things must be correct on the ProxCenter side before you register anything in Duo:

1. NEXTAUTH_URL must hold your public FQDN. It is set at install time and shipped to Duo as the OIDC redirect_uri. If ProxCenter is behind a reverse proxy and you ran the installer on the host's internal IP, the variable is wrong and Duo will receive an IP it cannot reach. Edit /opt/proxcenter/.env so the line reads, for example:

   NEXTAUTH_URL=https://proxcenter.example.com

   Then restart the stack:

   cd /opt/proxcenter && docker compose up -d

   See Reverse Proxy and Public URL for the full procedure and the nginx headers that go with it.

2. The Redirect URI ProxCenter expects is:

   https://<your-public-fqdn>/api/auth/callback/oidc

   Keep this URL on hand, you will paste it into Duo in the next step. The path is fixed (/api/auth/callback/oidc), only the scheme and host change.

Step 1: Create the OIDC application in Duo

1. Sign in to the Duo Admin Panel at admin.duosecurity.com.

2. Go to Applications > Protect an Application.

3. Search for Generic OIDC Relying Party (sometimes labelled "Generic OIDC SSO" depending on your Duo edition) and click Protect.

4. On the application page, set:

   Field	Value
   Display Name	ProxCenter (shown to users on the Duo prompt)
   Redirect URIs	https://<your-public-fqdn>/api/auth/callback/oidc
   Grant types	authorization_code (default, leave as is)
   Response types	code (default, leave as is)
   PKCE	Optional. ProxCenter does not require it.

5. Under OIDC Endpoints, note the following three values, you will need them for ProxCenter:

   • Client ID
   • Client Secret
   • Discovery URL (looks like https://sso-XXXXXXXX.sso.duosecurity.com/oidc/<client_id>/.well-known/openid-configuration)

6. Under Settings > Policy, attach whichever Duo policy you want enforced (MFA, device posture, network restrictions). Duo's MFA prompt fires at the OIDC sign-in step, before ProxCenter even sees the user. This is the recommended way to add a second factor to OIDC accounts, since ProxCenter does not add its own 2FA on top of OIDC (why).

7. Save the application.

Step 2: Configure ProxCenter

In ProxCenter, sign in as a super admin and go to Settings > Authentication > OIDC.

ProxCenter field	Value from Duo
Provider Name	Duo (or any label, this is what shows on the sign-in button)
Issuer URL	The Discovery URL from Duo with /.well-known/openid-configuration removed. Example: https://sso-XXXXXXXX.sso.duosecurity.com/oidc/<client_id>
Client ID	Client ID from Duo
Client Secret	Client Secret from Duo
Scopes	openid email (lowercase, single space, no commas)
Email Claim	email
Name Claim	preferred_username (Duo's default; use name if you have mapped it explicitly)

Click Test Connection to verify ProxCenter can fetch Duo's discovery document. You should see the discovered authorization_endpoint, token_endpoint, and userinfo_endpoint. If the test fails here, the Issuer URL is wrong; double-check that you removed the /.well-known/openid-configuration suffix.

Toggle Enable OIDC on and Save.

Auto-provisioning

Leave Auto-provision users on first login enabled if you want Duo-authenticated users to be created in ProxCenter automatically on their first sign-in. The default role assigned to new users is viewer; raise it for individual users from the Users page after they log in once, or map Duo groups to roles via the Groups Claim + group mapping table.

Step 3: Test the sign-in

1. Sign out of ProxCenter.
2. On the sign-in page, click the Sign in with Duo button (the label reflects whatever you set for Provider Name).
3. You are redirected to Duo, complete the Duo prompt (password + push / TOTP / WebAuthn depending on your policy).
4. Duo redirects back to ProxCenter. On a first login a new local user is created and you land on the dashboard.

Audit log entries for OIDC sign-ins appear under Security > Audit with category auth and provider oidc.

Local admin escape hatch

ProxCenter keeps the local credentials form available even when OIDC is enabled. If your Duo tenant is down, sign in with the local super admin credentials from the same /login page. We strongly recommend enrolling that local account in TOTP 2FA so it is not protected by password alone.

Troubleshooting

id_token not present in TokenSet after the Duo prompt

The OIDC token endpoint returned a response without an id_token. The single most common cause is a typo in the Scopes field on the ProxCenter side. The value must contain the literal token openid, lowercase, space-separated. Open ID, OpenID, or openid,email will not work, Duo will treat the request as a plain OAuth2 flow and skip the id_token.

Correct value:

openid email

You can verify what is being sent by watching the URL on the Duo prompt page: the scope= query parameter on /authorize?... should contain openid%20email.

redirect_uri_mismatch or "Invalid redirect URI"

The URL registered in Duo does not exactly match what ProxCenter sends. Both must match scheme, host, port, and path with no trailing slash difference. ProxCenter always sends ${NEXTAUTH_URL}/api/auth/callback/oidc, so register that exact value in Duo.

If NEXTAUTH_URL was wrong at install time and you fixed it (see Before you start), update the Redirect URIs list in the Duo application to match the corrected value.

Sign-in works through the FQDN but breaks the internal IP

This is expected once NEXTAUTH_URL is the public FQDN. Session cookies are marked Secure and pinned to that host, so a direct HTTP connection to the internal IP cannot complete the login flow. Keep the public FQDN as the only entry point.

The reverse proxy returns 502 after enabling OIDC

If your nginx site config uses proxy_set_header Connection "upgrade" literally, the value upgrade is sent on every request and breaks plain HTTP fetches like the OIDC token POST. Use the standard map block at the top of nginx.conf instead:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

Then in your site config:

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;

This keeps the noVNC and xterm.js consoles working (they use WebSockets) and stops breaking regular OIDC requests.

unexpected iss value, expected undefined

Seen in the frontend container log when the Duo prompt completes but ProxCenter bounces you back to the login page. The OIDC provider was built without a canonical issuer to validate the id_token's iss claim against, because the manual override fields under Advanced Endpoints (Authorization URL, Token URL, Userinfo URL) were filled in. Clear those three fields in Settings > Authentication > OIDC and leave only Issuer URL populated. ProxCenter then falls back to .well-known/openid-configuration discovery and the iss check lines up.

Fixed in ProxCenter v1.4.2: the manual-override path now passes the configured Issuer URL through to NextAuth explicitly, so this error no longer surfaces even when all four fields are populated.

Enterprise Feature

OIDC authentication is available in the Enterprise edition.