Blog | G5 Cyber Security

OpenID Provider Risks: Different Security Levels

G5 Cyber Security

TL;DR

Using the same OpenID provider for websites with varying security needs can be risky. It means a compromise of the provider could affect all your sites, even those needing higher protection. You need to carefully consider how you configure access controls and potentially isolate applications.

Understanding the Risk

OpenID Connect (OIDC) is great for single sign-on (SSO), but it introduces a dependency on the provider. If that provider is breached, or has vulnerabilities, all sites relying on it are potentially at risk. The severity depends on how you’ve set things up.

Solution Guide: Mitigating Risks

  1. Assess Security Levels: First, clearly define the security requirements for each website.
    • High Security: Sites handling sensitive data (financial info, personal health records) need strong authentication and authorisation.
    • Medium Security: Standard user accounts, basic content access.
    • Low Security: Publicly accessible information, minimal user interaction.
  2. Scope Management – Crucial! OIDC allows you to request specific ‘scopes’ (permissions) from the provider.
    • Never grant more scopes than necessary for each application.
    • For high-security sites, limit scopes to only essential user information and authentication. Avoid requesting profile details if they aren’t needed.
    • Example: A site needing just login might request the `openid` scope. A site needing name and email would add `profile` and `email`.
  3. Client Isolation: Treat each application as a separate client with its own configuration.
    • Register each website as an individual OIDC client within the provider.
    • Use unique Client IDs and secrets for each application. Do not reuse these!
  4. Conditional Access Policies: Many providers (like Azure AD, Okta) allow you to define policies based on user risk or device compliance.
    • Implement Multi-Factor Authentication (MFA) for high-security sites.
    • Block access from untrusted locations or devices.
    • Example (Azure AD PowerShell): 
    New-AzConditionalAccessPolicy -DisplayName "Require MFA for High Security App" -Users @("user@example.com") -Applications @("HighSecurityAppClientId") -Conditions @(@{ConditionType = "Location"; Operator = "Or"; Locations = @("UntrustedLocations")} ) -GrantControls @(@{AccessRequirements = @("MfaRequirement")} )
  5. Session Management: Configure appropriate session timeouts for each application.
    • High-security sites should have shorter timeouts.
    • Consider using Single Logout (SLO) to terminate sessions across all applications when a user logs out of one site.
  6. Regular Security Audits: Regularly review your OIDC configurations and provider security settings.
    • Check for misconfigurations or excessive permissions granted to clients.
    • Monitor audit logs for suspicious activity.
  7. Consider Separate Providers (If Feasible): For very high-security applications, using a dedicated OpenID provider can significantly reduce risk.
    • This adds complexity but provides stronger isolation.

By following these steps, you can minimise the risks associated with using a single OpenID provider for sites with different security levels.

Exit mobile version