Streaming identity logs to your SIEM

X-AuthMantra-Signature: t=1772529240,v1=9f2c...
{"id":"evt_01","time":"2026-03-03T09:14:00Z","organization":"org_demo","actor":"asha@example.com","action":"user.sign_in","target":"mail","status":"success","ip":"203.0.113.7","detail":""}
✓ sample event, illustrative values

Most intrusions that matter involve an identity at some point: a stolen session, a reset password, a new authenticator added by someone who should not have added one. Your identity provider sees all of it first.

If those records only live inside the identity console, your security team finds out about them when somebody remembers to look. Streaming them into a SIEM turns them into something you can correlate with network, endpoint and application logs.

This article covers what to stream, what a useful event looks like, how to deliver it without losing or duplicating records, and which detections pay off first.

Which events actually matter

Not every log line deserves a place in the SIEM. Volume costs money and buries signal. Start with these groups, in roughly this order of value.

Authentication outcomes

• Successful and failed sign-ins, with the method used (password, TOTP, passkey, SMS code).
• Lockouts and repeated failures against one account or from one source.
• Sign-ins from a country or network never seen before for that person.

Credential and factor changes

• A new authenticator, passkey or security key enrolled.
• A factor removed or reset.
• Password reset requested and completed.

Privilege and configuration changes

• A role granted or revoked, especially admin and auditor roles.
• Changes to single sign-on connections, redirect URLs or signing certificates.
• API keys created, rotated or deleted.

Session events

• Sessions revoked, by the user or by an administrator.
• Step-up challenges passed or failed before sensitive admin actions.

Lifecycle events

• Accounts created, suspended or deactivated, whether by a person or by an HR feed.

Leave out noisy low-value events at first, such as every token refresh. You can add them later if an investigation shows you missed them.

What a good event looks like

A SIEM is only as useful as the fields you can search on. Aim for a flat, consistent structure that carries these items on every event:

• A unique event ID, used later for de-duplication.
• A timestamp in UTC, in ISO 8601 form.
• An event type, such as auth.login.failed or role.granted.
• The actor (who did it) and the target (who or what it was done to). These are often different people.
• Source IP address and user agent.
• The outcome (success or failure) and a reason code on failure.
• The tenant or organisation identifier, if you run more than one.

An example, as JSON:

{
  "id": "evt_01j9x2k7",
  "time": "2026-09-08T04:12:09Z",
  "type": "role.granted",
  "actor": {"id": "usr_2291", "email": "admin@example.org"},
  "target": {"id": "usr_8841", "email": "new.hire@example.org"},
  "detail": {"role": "it_admin"},
  "ip": "203.0.113.24",
  "outcome": "success"
}

Two habits help later. Keep field names stable across event types, so a single query for actor.email works everywhere. And never put secrets, full tokens or password material in a log event.

Delivery: signed webhook or HTTP event collector

There are two common ways to push events out of an identity platform.

Signed webhook. The platform sends an HTTP POST to an endpoint you run. You verify each request before trusting it. This gives you full control: you can transform, filter, enrich and then forward to whichever store you use.

HTTP event collector. Some log platforms expose an ingestion endpoint that accepts events directly with a token. Splunk's HTTP Event Collector is one such mechanism. Here the platform posts straight to your log platform and you do not run a receiver at all.

The trade-off is simple. A direct collector has fewer moving parts. A webhook receiver adds a component to operate, but lets you drop fields, mask data and fan events out to more than one place.

Verifying a signed webhook

A webhook endpoint is a public URL, so anyone can post to it. The signature proves the sender holds the shared secret.

AuthMantra sends one header, X-AuthMantra-Signature, in the form t=<unix seconds>,v1=<hex>, where v1 is an HMAC-SHA256 of the string <t>.<raw request body> using the secret shown once when you create the destination. Each delivery also carries a unique X-AuthMantra-Delivery id.

import crypto from "node:crypto";

function verify(rawBody, headers, secret) {
  // Header looks like: t=1760000000,v1=9f2c...
  const parts = Object.fromEntries(
    String(headers["x-authmantra-signature"] || "")
      .split(",")
      .map((p) => p.split("=", 2)),
  );
  const ts = Number(parts.t);
  const sig = parts.v1 || "";

  // 1. Replay protection: reject old or future timestamps.
  if (!ts || Math.abs(Date.now() / 1000 - ts) > 300) return false;

  // 2. Recompute the HMAC over "<t>.<raw body>".
  const expected = crypto
    .createHmac("sha256", secret)
    .update(`${ts}.${rawBody}`)
    .digest("hex");

  // 3. Constant-time comparison.
  const a = Buffer.from(expected);
  const b = Buffer.from(sig);
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}

The body is JSON with a source, the destination sink id and an events array. Each event has id, time, organization, actor, action, target, status, ip and detail.

Delivery is at least once and in order, so de-duplicate on the event id.

Three details are easy to get wrong:

1. Sign and verify the raw bytes of the body. If your framework parses the JSON and you re-serialise it, the bytes change and the signature fails.
2. Compare in constant time, not with ==.
3. Include the timestamp in the signed string and reject anything outside a small window, commonly five minutes. Otherwise someone who captures a valid request can replay it later.

Keep the secret in a secrets manager, and plan for rotation: accept two secrets for a short overlap period.

Retries and idempotency

Networks fail. A sender that cares about not losing audit events will retry, which means your receiver will sometimes see the same event twice. Design for it:

• Return a 2xx status only after the event is durably stored or queued. Return 5xx when you could not.
• De-duplicate on the event ID. A simple key-value store with a seven-day expiry is enough.
• Do not rely on order. Use the event timestamp for sequencing, and expect small inversions.
• Alert on silence. If no events arrive for an hour during working time, either your tenant is quiet or the pipeline is broken. Find out which.

Also decide what happens to events during your own outage. A queue between the receiver and the SIEM absorbs short interruptions.

Detections worth building first

You do not need a large rule library. These few catch a lot:

1. Admin role granted outside change windows, or granted by an account that does not normally grant roles.
2. New factor enrolled shortly after a password reset for the same account. This is a classic account takeover pattern.
3. Many failures then a success for one account within a short interval.
4. Impossible travel or first-seen country for privileged accounts only, to keep noise manageable.
5. Single sign-on configuration changed, particularly a new redirect URL or certificate.
6. API key created for a privileged service identity.
7. Step-up failures repeated against one administrator.

Write each rule down with an owner and a first-response step. A detection with no runbook is only a notification.

Retention

India's CERT-In directions of 28 April 2022 ask covered entities to keep certain logs for 180 days and to report specified incidents within six hours.

Whether and how that applies to your organisation, and which logs count, is something to confirm with your compliance counsel.

Practically, set SIEM retention for identity events to at least that period, and keep the original raw events, not only the parsed copies.

How AuthMantra fits

AuthMantra provides an audit log with export, a live audit feed, and streaming to a SIEM through either a signed webhook or Splunk HTTP Event Collector. If you use something else, the same design notes above apply.

What to do this week

• Pick the five event types from the groups above that you cannot see today.
• Stand up one receiver or collector in a test environment and send a handful of real events.
• Verify signatures and timestamps; test a replayed request on purpose.
• Build two detections from the list, with a named owner each.
• Confirm retention settings against your own counsel's reading of the CERT-In directions.

For the wider picture of how identity logs support audits, see audit and DPDP readiness.