OIDC Login Failures

OIDC Login Fails for User Directory

If OpenID Connect (OIDC) login works when using a standalone OIDC directory in PrivX but fails when the user is part of another user directory type, such as LDAP or SCIM, the issue may be that the OIDC user isn't found in the PrivX user cache.

If your OIDC user login is successful when configured as standalone PrivX directory (OIDC directory type), but login fails when configured as part of other directory type (LDAP or SCIM user directory), one possible reason could be that your OIDC user is not found in user cache.

Possible causes include:

1. The LDAP or SCIM user hasn't been imported into PrivX.
2. The OIDC user's sub field doesn't match the cached user's external ID. This may happen due to custom field names or incorrect attribute mapping.

Potential Solution

1. Verify that the user appears in the PrivX directory listing.

2. Check the external ID mapping:

   • Some directory types, like Microsoft Graph API, automatically use the oid attribute from the OIDC idToken. No manual attribute mapping is needed in PrivX in this case.
   • For LDAP and SCIM directories, if you use custom field names for imported users, PrivX needs to know which field matches the OIDC subject field.

3. Ensure PrivX users have valid attributes:

   • A mapped username isn't required for OIDC login (only the sub field must match), but it's recommended for logging and usability. Non-OIDC directories required unique usernames.
   • For example, directory logins using SSH certificates will fail if a user lacks both username and unix_account (Unix username) attributes.
   • By default, LDAP users use the uid=principal mapping to derive the username from the uid field.

4. If using a native OIDC directory:

   • Check whether the OIDC server returns a username or email at login. If not, review the "Additional scopes" directory setting in PrivX.
   • By default, PrivX uses the openid scope. To retrieve profile information, add scopes like profile or email, based on your OIDC provider's documentation.

   For other directory types, defining openid scopes is unnecessary, since users' username and email are imported separately. Insted, just receive the OIDC subject field matching the user identifier in cache.

5. Attribute mapping examples:

   • To map a custom user identifier to the OIDC subject, use the format: attributeName=external_id. For example: userPrincipalName=external_id
   • In SCIM directories, internal attribute names may differ from protocol attribute names. For example: dn=external_id maps the SCIM userName field.

:::infoImportant: The user's external_id must be unique within the directory. Otherwise, login will fail..:::

OIDC Login Button Not Visible on Privx Login Page

If you're using Azure or Oracle Cloud as your OpenID Connect (OIDC) provider, make sure you've configured the Additional issuer URL correctly.

To learn how to set this up in the OIDC directory settings, see OpenID Connect (OIDC) Authentication.

PrivX GUI Doesn't Load After OIDC Login

After entering valid OIDC credentials, you may experience one of the following:

• A browser error like ERR_CONNECTION_CLOSED
• No response or blank screen

You might also see log entries like this in the Nginx access logs:

"-" 000 0 "-" "-" "-"

This issue can occur if the request header size is too small.

Potential Solution

To fix it, increase the maximum request-header size in the Nginx configuration as follows:

1. Open the /etc/nginx/privx/privx-common.conf file.

2. Add the appropriate setting based on your Nginx version:

   • For Nginx 1.19.7 and later:

     large_client_header_buffers 4 8k;

   • For earlier versions:

     http2_max_field_size 8k;

3. Restart Nginx to apply the changes:

   sudo systemctl restart nginx

After restarting Nginx, try logging in again with OIDC to confirm if the problem has been fixed.