# Identity observability essentials > Measure authentication, sessions, tokens, and permission checks with explicit reliability indicators, safe correlation, and actionable alerts. Canonical URL: https://www.devobs.io/articles/identity-observability-essentials/ By: Jonah Reed Published: 2026-10-11T04:35:47.994Z Updated: 2026-10-11T04:35:47.994Z Section: Identity Identity observability should connect authentication journeys, session lifecycle, token operations, and permission checks without collapsing reliability, user experience, and security into one success rate. Start by defining observation boundaries, recording explicit outcomes, and correlating related operations without collecting credentials or tokens. The design below is an application-level instrumentation plan—not a description of built-in Ory telemetry. ## Map the boundaries before choosing metrics Create an inventory of the operations your application depends on, including who owns each boundary and where you can observe its outcome. Ory’s documentation for Ory Network illustrates useful component boundaries: - **Identity and authentication:** Ory documents its Kratos-based identity service as API-first, with self-service registration, login, recovery, and multi-factor authentication (MFA). It also lists session lifespan, refresh, and revocation controls. Instrument both the user-facing journey and the application’s session-handling integration. [Ory Kratos documentation](https://www.ory.com/docs/network/kratos/intro) - **OAuth 2.0 and OpenID Connect:** Ory describes its Hydra-based Network service as an OAuth 2.0 and OpenID Connect provider with a headless API that can work with an existing user-management system. Keep the authorization-server integration distinct from the implementation that authenticates users. [Ory Hydra documentation](https://www.ory.com/docs/network/hydra) - **Fine-grained authorization:** Ory’s Keto documentation describes relationship-based permissions and inheritance through groups, roles, and hierarchies. Give permission checks their own observation boundary rather than treating login completion as the final access outcome. [Ory Keto documentation](https://www.ory.com/docs/network/keto) For each boundary, identify the initiating application action, downstream call, terminal result, and responsible team. Include session creation, validation, refresh, and revocation wherever your application uses them, plus the token operations it actually performs. Verify telemetry access separately for managed and self-hosted deployments. Confirm available signals, export paths, sampling controls, and retention rather than inferring them from product feature descriptions. ## Separate execution, decisions, and journey outcomes Use separate fields for technical execution and the result of the identity operation. A proposed classification is: | Observation | Technical outcome | Identity or journey outcome | | --- | --- | --- | | Authentication flow returns final success | Completed | Authentication succeeded | | Authentication returns an explicit rejection | Completed | Authentication rejected | | Permission evaluation returns deny | Completed | Access denied | | Permission evaluation times out | Timeout | Decision unavailable | | Login begins but no terminal event is observed by the deadline | Unresolved | Completion unknown | Treat an accepted password as an intermediate step when the flow still requires another factor. Define authentication success at the boundary where the required flow has actually completed. Do not automatically count an expected rejection as service malfunction. Conversely, do not relabel a dependency timeout as a policy denial just because the application ultimately refuses access. If the application fails closed, record that enforcement action separately from the unavailable permission decision. For authentication journeys, define a completion window. Label journeys without an observed terminal result as incomplete or unresolved; use “abandoned” only when your measurement contract defines that inference and its limitations. Keep decision correctness separate, too. A completed permission check does not establish that the configured policy expresses the intended access rules. Test known-allow and known-deny cases separately from operational completion. ## Define indicators with explicit denominators A service-level objective (SLO) specifies a reliability target. Google’s SRE guidance recommends expressing service-level indicators (SLIs) as the number of good events divided by the total number of events. For identity operations, explicitly define what counts as “good” for each indicator. [Implementing SLOs](https://sre.google/workbook/implementing-slos/) For every indicator, document: - The eligible operation and population. - The observation point and measurement window. - The numerator, denominator, and exclusions. - The deadline for a result. - How retries, missing results, and collection failures are handled. For example, define a **session-validation operational completion indicator** as: `eligible logical validations returning a defined valid/invalid result within the deadline / all eligible logical validations started` Measure this at the application boundary. Count expected invalid-session results as completed evaluations, while recording their rejection rate separately. Keep timeouts and internal errors in the denominator. Define the measurement cohort by operation start time, then evaluate it after every operation’s deadline has passed. Retain enough start-and-result bookkeeping to account for attempts without terminal events. Measure collection gaps separately and flag coverage as uncertain when the denominator cannot be trusted; do not infer a healthy indicator from an empty or incomplete feed. Assign one logical attempt identifier before retries begin. Count individual requests separately for dependency diagnosis, but do not let retries create additional logical attempts in the completion indicator or additional user attempts in the journey metric. Maintain separate latency measurements: - **Boundary latency:** Time from an application integration call to its result, including the retry behavior defined for that operation. - **Server-processing latency:** Processing time inside a component, where available. - **Journey duration:** Time from the defined user-journey start to completion. Do not substitute one for another. Choose targets from application requirements and measured baselines rather than adopting a universal “identity SLO.” ## Correlate metrics, events, and traces deliberately OpenTelemetry describes metrics as runtime measurements, logs as event recordings, and traces as the path of a request through an application. Use those complementary signals for different questions. [OpenTelemetry signals](https://opentelemetry.io/docs/concepts/signals/) A practical division is: - **Metrics:** How often does an operation occur, and how are latency and outcome rates changing? - **Structured log events:** What result did this logical operation produce? - **Traces:** Where did an observed request spend time or encounter an error? Define a small application event contract with fields such as `event_time`, `component`, `operation`, `technical_outcome`, `decision`, `reason_category`, and a duration whose start and end points are documented. Use bounded reason categories rather than arbitrary exception text. Represent an unavailable permission decision explicitly rather than encoding it as a denial. Add an opaque `journey_ref` or `attempt_ref` for correlation, and a trace identifier when available. These are proposed application fields, not an Ory event schema. Do not derive correlation references from credentials or tokens. Instrument boundaries you control: journey initiation, callback handling, session validation, token integration calls, and permission checks. Verify trace propagation at each integration; do not assume one trace will span every browser redirect, external provider, or managed-service boundary. Use bounded dimensions such as operation, component, and outcome in metrics. Keep user, session, tenant, and correlation identifiers out of metric labels; reserve necessary identifiers for access-controlled event records. ## Protect telemetry as a separate data surface OWASP distinguishes operational and security logging uses and recommends setting monitoring requirements according to information-security risks. It also identifies passwords, access tokens, session identifiers, and other secrets as data that should not be recorded directly without removal or protective handling. [OWASP Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) For this design, use a stricter field allowlist at the point of instrumentation. Exclude passwords, one-time codes, recovery codes, authorization codes, access tokens, refresh tokens, session cookies, and authorization headers. Disable indiscriminate capture of request bodies and query strings on identity paths. Add pseudonymous subject or tenant references only when a concrete investigation requires them. Treat those references as sensitive rather than assuming they are anonymous. Define separate access and retention rules for diagnostic telemetry and audit records. Where an audit trail requires complete coverage, do not use sampled traces as its substitute. Specify integrity protections and collection-failure behavior according to the records’ purpose and applicable obligations. ## Build distinct reliability and security views Organize dashboards and alerts around three questions: 1. **Reliability:** Are operations returning defined results within their deadlines? Track internal errors, timeouts, dependency failures, and latency. 2. **User experience:** Are journeys reaching completion? Track completion by flow, step progression, unresolved journeys, and end-to-end duration. 3. **Security investigation:** Are rejection, recovery, MFA-failure, or permission-denial patterns changing enough to warrant review? Review rates alongside volumes, baselines, and deployment context. Treat a denial spike as a reason to investigate—not as proof of an attack or an outage. For example, after a permission-model deployment, compare denial rates with check latency and evaluation errors. Route possible policy regressions to the policy owner while retaining a separate view of permission-service execution health. Attach each actionable alert to an owner and a first diagnostic step. Avoid a generic “identity failures increased” alert with no distinction between rejection, denial, timeout, and internal error. ## Validate coverage and collection failure paths Before relying on the dashboards, test the instrumentation deliberately: - Complete a successful authentication journey and session validation. - Trigger an expected credential rejection, invalid-session result, and permission denial. - Exercise a timeout, dependency error, and retry sequence. - Leave a journey incomplete and verify its classification after the observation window. - Inspect captured attributes for prohibited fields. - Interrupt telemetry delivery and verify that collection failure and uncertain indicator coverage are visible. For each test, check the event classification, metric increment, correlation behavior, and alert routing. Monitor delivery lag, dropped records, and collector health wherever those measurements are available. A useful starting deliverable is one boundary inventory, one event contract, one explicitly defined reliability indicator per critical operation, and a tested diagnostic path from an alert to relevant events and traces. Expand from there according to real operational questions. ## Source references - - - - - -