Auditing Identity Configuration Changes

Identity configuration is production behavior.

A changed redirect URI can break login. A new client secret can open a path that was not reviewed. A modified claim rule can change what downstream applications believe about a user. An IdP setting can decide whether users are created at first login or only after provisioning. These are not just administration tasks. They are security-relevant changes to the system that issues identity tokens, controls tenant routing, and connects enterprise directories to applications.

That is why identity operations need more than a list of current settings. Teams need to know what changed, when it changed, who performed the change, and what the before-and-after state looked like. For regulated environments, incident response, and ordinary production hygiene, the audit trail is the part of the identity platform that turns configuration from “someone changed something” into evidence that can be reviewed.

Configuration changes are security events

In ProAuth, the Management API is used to manage and configure the ProAuth server, including customers, subscriptions, tenants, identity providers, client applications, certificates, custom views, and related configuration. Those objects influence the authentication path that users and client applications experience.

Several examples are worth treating as audit-relevant by default:

Configuration area	Change to review	Why it matters
Tenants	Tenant options, issuer behavior, tenant routing, login audit settings	A tenant defines the context in which authentication runs. Tenant-specific endpoints, issuer behavior, and options can affect token validation and login flow behavior.
Client apps	Redirect URIs, secrets, public/confidential client settings, restrictions, scopes, resources, assigned tenants	A client application controls where users can return after login and what a client is allowed to request.
IdP instances	Active state, assigned tenants, authority, callback path, client credentials, auto-user creation	A federated IdP instance decides which upstream directory participates in login and how ProAuth maps that login into the tenant.
Claim rules	Active state, filters, transforms, created claims, token destinations	Claim rules process ProAuth claims and federated claims before tokens are issued. Small changes can affect ID tokens, access tokens, or both.
SCIM provisioning	SCIM endpoint ownership, user and group synchronization behavior, attribute mappings	SCIM writes users, groups, profiles, and memberships into ProAuth in the context of a specific IdP instance.

The point is not that every configuration change is suspicious. The point is that these changes affect trust boundaries. They deserve the same operational discipline as firewall rules, production deployment settings, and database access changes.

What ProAuth records

ProAuth includes database auditing for specific entities. Audit log entries are written to audit tables in the configuration database and in user store databases. For the configuration database, ProAuth also provides a built-in audit trail viewer with a diff view.

An audit trail entry records the core facts needed for review:

flowchart LR
    actor["User or application<br/>performs a configuration mutation"]
    entity["Audited database entity<br/>for example tenant, client app, IdP, claim rule"]
    entry["Audit trail entry"]
    reviewer["SystemAdmin or<br/>AuditTrailReader reviews"]

    actor --> entity
    entity --> entry
    entry --> reviewer

    entry -. contains .-> timestamp["timestamp"]
    entry -. contains .-> action["action<br/>Added, Modified, Deleted"]
    entry -. contains .-> area["area<br/>entity type"]
    entry -. contains .-> user["ProAuth user id"]
    entry -. contains .-> beforeAfter["original and current content"]
    entry -. contains .-> signature["certificate-backed signature"]

The entry includes an identifier, timestamp, category, area, action, user, data source, signature public key information, signature, original content, and current content. For database audit entries, the area identifies the entity type. The action records whether the audited change added, modified, or deleted a record. Original content is not available for newly created entities, and current content is not available for deleted entities.

The signature matters. ProAuth signs each audit trail entry with a certificate stored in the internal certificate store; changing the audit trail entry invalidates the signature. That does not replace approval workflows, but it does give reviewers a stronger basis for trusting that the recorded entry has not silently changed after the fact.

Keep audit access narrow

Audit entries contain sensitive information. ProAuth documentation therefore limits audit trail viewing to users and applications with either the SystemAdmin role or the AuditTrailReader role. The AuditTrailReader role exists so teams can grant read access to audit trail data without granting full system administration permissions.

That separation is useful in practice. An operations engineer may need to change a tenant or client application. A security reviewer may need to read the audit trail. Those should not always be the same permission. Separating change authority from review authority makes audits less performative and more useful.

It is also worth remembering that audit trails are evidence, not authorization policy. They show what happened. They do not prove that the change was approved, tested, or linked to the right customer request. That context still belongs in the change ticket, pull request, service desk record, or runbook step that authorized the work.

API-first management needs change governance

The Management API is useful because identity configuration can be automated. Customer onboarding, client application setup, IdP configuration, certificates, custom views, tenant options, and related objects should not depend only on manual clicks when the organization needs repeatability.

Automation does not remove governance. It changes where governance has to live.

For human changes, the review path may be an Admin UI workflow plus an approval ticket. For automated changes, it may be a pipeline, a service principal, and a versioned configuration file. In both cases, the same questions should be answerable after the fact:

• Which tenant, client application, IdP instance, claim rule, or SCIM-related object changed?
• Who or which application performed the change?
• What was the previous value?
• What is the current value?
• Was the change expected for the customer, rollout, incident, or maintenance window?
• Which downstream behavior could be affected: login routing, token claims, provisioning, MFA, redirects, or client access?

ProAuth’s audit trail can help with the first four questions because it records the actor, action, area, timestamp, and before-and-after content. The last two questions usually require operational context. Good teams connect both sides: ProAuth records the change, and the change process records the reason and intended impact.

A practical review rhythm

Audit trails become more useful when review is routine, not only forensic.

For normal operations, review identity configuration changes that affect tenant routing, client application access, IdP assignments, claim rules, and SCIM provisioning behavior. These are the areas where a small setting can alter who can log in, what tokens contain, which users exist before login, or which application receives a callback.

For incident response, start from the symptom and work backward:

• If a customer reports login failures, review recent tenant, IdP instance, redirect URI, and client application changes.
• If an application receives unexpected claims, review claim rule changes and client application claim-related settings.
• If users appear, disappear, or change group membership unexpectedly, review SCIM synchronization activity and the IdP instance connected to that provisioning path.
• If an auditor asks who accessed audit data, verify that audit trail read permissions are assigned only to principals that need them.

The most useful audit review is specific. “Check the audit log” is too broad when the system is under pressure. “Review modified client applications and claim rules for this tenant since the start of the incident window” is actionable.

Treat the audit trail as part of the operating model

Identity governance is often described in policy language, but it succeeds or fails in operational details. Can a reviewer see the old and new value? Can they tell which entity changed? Can they separate a planned customer onboarding change from an unexpected production mutation? Can they read the audit trail without becoming a system administrator?

ProAuth gives teams the technical basis: audited database changes for specific entities, a configuration audit trail viewer with diffs, signed audit trail entries, and restricted audit trail access. The operating model around it should add the missing human context: approval, reason, customer impact, and follow-up.

That combination is what makes identity configuration auditable in practice. The platform records what changed. The team records why it changed. Together, they make production identity changes reviewable instead of anecdotal.

For implementation details, see the ProAuth documentation for Auditing, the Management API, Client Applications, Federated Identity Providers, Claim Rules, and SCIM.