Topic guide · 3 min read
Information security for identity systems
Short answer
Identity systems need stronger protection than the applications that trust them: keep signing keys in HSMs or protected key stores, allow only TLS 1.2 and 1.3, isolate and strongly authenticate admin access, patch quickly, keep secrets out of code and logs, and rehearse what you will do if a key or admin account is compromised.
Key takeaways
- Whoever holds your IdP's signing key can sign in as anyone, everywhere that trusts it.
- Identity servers are internet-facing by design; patch them on a short cycle.
- Have a written plan for key compromise: rotate, publish new metadata, revoke sessions.
Identity providers, authorization servers and directories are high-value targets. Compromise one and you do not need to attack each application: forged tokens and assertions open them all. Attacks on token signing infrastructure and on identity provider admin accounts are well documented in incident reports, so protecting these systems deserves its own plan.
What are the crown jewels?
Signing keys, administrator accounts, the user directory and federation configuration.
| Asset | If compromised | Protection |
|---|---|---|
| Token / assertion signing keys | Forge sign-ins for any user | HSM or cloud KMS, no export, access logging |
| IdP admin accounts | Add trust, disable MFA, mint tokens | Phishing-resistant MFA, separate admin accounts, JIT elevation |
| Directory | Change passwords, groups | Tiered admin model, monitoring |
| Federation configuration | Add a rogue IdP or SP | Change control, alerts on new trusts |
| TLS private keys | Intercept traffic | Managed certificates, short validity |
Which transport settings are required?
TLS 1.2 and 1.3 only, modern cipher suites, HSTS and correct certificates.
The history of SSLv3, TLS 1.0 and 1.1 is in our POODLE article. Add HSTS and other headers to sign-in pages with the Security Header Builder, and see HSTS on Jetty-based servers for product-specific notes.
How should tokens be issued and verified?
Sign with strong asymmetric algorithms, publish keys through JWKS, verify with pinned algorithms, and keep lifetimes short.
RFC 8725, the JWT best current practices, summarizes what matters: explicit algorithm allowlists, audience checks, no none, careful handling of kid, jku and x5u, and different validation rules for different token types. Inspect tokens your systems issue with the JWT Decoder.
How do I handle secrets?
In a secrets manager, never in code, never in logs, rotated on a schedule and on staff changes.
Client secrets, SCIM bearer tokens, LDAP bind passwords and API keys all count. Scan repositories for leaked secrets. Prefer credentials that need no stored secret: workload identity, mTLS with managed certificates, private_key_jwt with keys in a KMS.
What belongs in the incident plan?
Steps for a compromised signing key, a compromised admin account and a compromised federation partner.
- Key compromise: generate a new key, publish it, remove the old key from metadata and JWKS, notify partners, revoke sessions and refresh tokens.
- Admin compromise: disable the account, review recent admin actions (new trusts, MFA changes, app registrations), roll back, rotate any secrets they could read.
- Partner compromise: suspend the trust, review sign-ins from that partner, restore with new keys.
Rehearse at least the first one. Many teams discover during a drill that nobody knows how to update metadata at fifty relying parties.
Questions
How often should signing keys be rotated?
Many organizations rotate token signing keys at least yearly, and some much more often with automated JWKS rollover. More important than frequency is being able to rotate quickly and safely when needed.
Should identity servers sit behind a web application firewall?
A reverse proxy or WAF that allowlists the protocol endpoints you use adds useful defense in depth. It does not replace patching or correct configuration.