Security & Identity Templates

Security and identity diagram templates — OAuth flows, zero-trust architectures, SSO, incident response, and threat models to document how your systems stay safe.

7 templates

About security diagrams

Security and identity diagrams show who can reach what, how they prove it, and what happens when something goes wrong. They cover OAuth 2.0 and OpenID Connect token flows, SAML and OIDC single sign-on, zero trust access checks and role-based permissions. They also cover SIEM log pipelines, STRIDE threat models and the incident response lifecycle.

Security architects, AppSec and IAM engineers use them in design reviews and threat modeling. SOC teams use them to document detection and escalation. Developers use them to integrate SSO correctly, and compliance teams use them to support audits such as SOC 2 or ISO 27001. Platform teams use them to explain why a service needs a new scope or role before access is granted.

A good security architecture diagram draws trust boundaries explicitly: the public internet, the edge, internal services and third-party providers. It names the identity provider as the source of truth for users. It shows each token in the flow, who issues it, who validates it and where it is stored. In a threat model, every threat maps to a mitigating control. Keep real secrets, internal hostnames and IP ranges out of any diagram you share widely.

Which template should you pick?

  • Pick OAuth 2.0 Authorization Code Flow Diagram when an app needs delegated API access and readers must see each endpoint and token.
  • Pick SSO Architecture Diagram (SAML & OIDC) when users sign in once through an identity provider and reach several service provider apps.
  • Pick Zero Trust Architecture Diagram when every request to repos, databases and internal apps is checked against identity and policy, with no trusted internal network.
  • Pick Threat Model Diagram (STRIDE) when reviewing a design for spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege.
  • Pick Incident Response Flow Diagram or SIEM Architecture Diagram when documenting how threats are detected, escalated, contained and reviewed.

Or generate one from a prompt

  • “OAuth 2.0 authorization code flow with PKCE for a single-page app: user, SPA, Auth0 authorization server, token endpoint, access and refresh tokens, resource API.”
  • “Zero trust access for remote employees: Okta identity provider, device posture check, policy engine, identity-aware proxy, MFA, micro-segmented internal apps, central logging.”
  • “STRIDE threat model for a payments API: mobile client, API gateway, auth service, payments service, card vault, trust boundaries, and mitigations for each threat.”

Paste any of these into the AI diagram generator to get an editable, animated diagram in seconds.

Tips for customizing security templates

  • Tag each component with its trust zone, for example Browser (internet), Gateway (edge) or Ledger (internal), so boundary crossings stand out.
  • Name each token where it appears, such as authorization code, access token, refresh token or ID token, and note how long it lives.
  • Add PKCE to OAuth flows for mobile and single-page apps, since those clients cannot keep a client secret.
  • In the RBAC Permission Model Diagram, list the real permissions each role gets, such as read, write or delete. Keep admin rights in one clearly marked role.
  • Before sharing, replace real client IDs, secrets, internal hostnames and IP ranges with placeholders.

Learn more: Flow chart examples, including a login flow

Browse other categories