Risky Sign-in Detection

Overview

Risky Sign-in Detection reads authentication events from your identity provider and raises an alert when a sign-in pattern is not physically or behaviourally plausible. Every alert carries the numbers that produced it, so you can judge it rather than take it on trust.

It is an ingest-driven feature: Dralvia does not connect to your directory and does not read your users. You send sign-in events; Dralvia evaluates them.

What it detects

Two alert types are raised today. Both are deterministic — the same events always produce the same alert.

Impossible travel

Two sign-ins from locations far enough apart that the journey between them could not have happened in the time available.

Condition	Value
Minimum distance between the two sign-ins	500 km
Minimum implied speed to alert at all	600 km/h
Implied speed treated as high severity	900 km/h

Both events must carry latitude and longitude. Without coordinates the check is skipped rather than guessed at, so an event with no geolocation never produces a false alert.

The alert records the distance in kilometres, the hours between the two events, the implied speed, both locations, and whether the country changed. The explanation is written out in full, for example:

User j.smith would need to travel 4,812 km in 1.4h (≈3,437 km/h).

Session hijack

The same session observed with characteristics that changed when they should not have. Four signals are considered: the IP address, the user agent, the country, and the geographic position.

• One signal alone is not an alert when it is only an IP change with no country or geographic movement — that is ordinary network behaviour, and alerting on it would bury the real ones.
• Severity is high when the country changed, when position and user agent both changed, or when the user identity on the session differs.
• Otherwise the alert is medium.

Sending events

POST /identity/events

Accepts either a list of events or an object with an events list and an optional tenant_id. Up to 500 events are processed per request, and the endpoint is rate-limited to 240 requests per minute.

{
  "tenant_id": "your-workspace",
  "events": [
    {
      "user_id": "j.smith",
      "username": "[email protected]",
      "ip": "203.0.113.10",
      "country": "IE",
      "city": "Dublin",
      "latitude": 53.35,
      "longitude": -6.26,
      "user_agent": "Mozilla/5.0 ...",
      "timestamp": "2026-08-03T09:12:00Z"
    }
  ]
}

Events without a usable shape are counted as invalid and skipped; the response reports how many were saved, how many were invalid, and how many alerts were created, so a malformed integration is visible immediately rather than silently dropping data.

Reviewing alerts

Endpoint	Purpose
GET /admin/identity/alerts	Alerts, filterable by type
GET /admin/identity/summary	Counts by severity and type
GET /admin/identity/events	The underlying sign-in events
GET /admin/identity/alerts/{id}/evidencepack	An EvidencePack for one alert
GET /admin/oauth/risks	OAuth grant risk events

In the platform, the Risky Sign-in Detection module shows the same data with the contributing context attached to each alert.

Responding

POST /identity/revoke

Revokes a session for a user and records the action. user_id is required; a reason is optional and defaults to auto-revoke high-risk token.

The response reports a status of either revoked or simulated. simulated means the action was recorded but no upstream revocation was performed — typically because the identity provider integration is not configured. That distinction is deliberate: an action that did not actually reach your provider must never be reported as though it did.

Every action is written to the response-action audit trail and readable at GET /admin/identity/response/actions, scoped to your workspace.

Limitations and assumptions

• You supply the events. There is no directory connection and no user enumeration. Coverage is exactly what you send.
• Geolocation must be in the event. Dralvia does not resolve IP addresses to coordinates for this check, so impossible travel only evaluates events that already carry latitude and longitude.
• Two alert types today: impossible travel and session hijack. Other identity risk signals are not inferred.
• Revocation depends on your provider integration. Without it, actions are recorded as simulated, and the audit trail says so.
• Alerts are workspace-scoped. Cross-workspace access requires an internal role.