Skip to Content

Ensure OAuth client compliance with AdminUI

Want to ensure your OAuth clients meet best security practices? Do you want to ensure all admins create clients consistently across your organization? Then the AdminUI client security compliance feature is for you. It includes built-in best-practice rules for OAuth and FAPI. You can even create your own to match your requirements. With the AdminUI configuration validation feature, you limit your exposure to poorly secured clients. 

Why client compliance matters

Client configuration is easy to get almost right. A redirect URI changes, a legacy grant type hangs around, or a security setting gets missed during a busy release. Each choice can look harmless on its own, but together they can leave applications exposed or make it harder to show that your clients meet the standards your team has agreed to follow.

Compliance validation works best when it is part of the existing administration workflow rather than a separate review left until later. Timely feedback helps administrators fix problems before production, gives security teams a clearer view of the client estate, and makes secure configuration easier to maintain as applications and standards evolve.

Meet AdminUI Compliance Validation

AdminUI Compliance Validation checks client configuration against a defined ruleset. The check runs whenever a user changes a client. If AdminUI finds an issue, it displays a warning dialog that identifies the failed rule before the user continues.

There are two types of rules:

  • Compliance rules: if these fail, the client cannot be saved.
  •  Recommendations: if these fail, the client still saves but displays a warning.
Non Compliant Client, shows errors and recomendations to be made to the client configuration to ensure it meets the validation rules

Start with built-in rule sets


AdminUI includes two default rulesets: the OAuth 2.1 (draft) and Financial-grade API (FAPI) 2.0. Each ruleset applies requirements from its specification, and every rule links to the relevant specification section so users can understand why a check has passed or failed.

Some example rules that are included:

  • Only recommended grant types are used (not implicit, hybrid, or resource owner password)
  •  PKCE is enabled for AuthCode clients.
  • Authorization code clients have at least one redirect URI.

Get a view across your clients

The new Compliance Report, found in the client list tab in AdminUI, gives an overview of all clients and their compliance status; this could be:

  •  fully compliant
  • compliant with some recommendations
  • non-compliant.

This is a perfect way to get started to see what clients you currently have that could need some attention. What's even better is that this report works as an effective report to give any security auditors to demonstrate you are compliant.

 

Compliance report of all clients

How to get started

Compliance validation is included in all versions of AdminUI for IdentityServer from 14.0.0. By default, validation will be set to use the OAuth 2.1 (draft) ruleset. You can change the default ruleset on the Settings > Compliance tab.

NOTE: This is NOT a paid extra; it's included in your AdminUI license

With compliance checks built into the client configuration workflow, administrators can address issues as they make changes and use the Compliance Report to monitor the wider client estate. Upgrade to AdminUI 14.0.0 or later and start with the OAuth 2.1 (draft) ruleset, then adapt the rules as your organization’s requirements evolve.

Adapt the rules to your needs

You can override either default ruleset to change which rules are applied, adjust whether a failed check blocks saving or produces a recommendation, or replace the validation logic for an individual check.

If you want to fully customize validation, you can implement the base interface and write custom validation rules. This could include company-specific rules, for example, client name format rules. More information on how to implement custom rules can be found in the documentation or you can contact us for assistance.

Last updated: 11 November 2026

Paul is a Software Developer in the Identity Team at Rock Solid Knowledge.