Identity Risk & OAuth Monitoring

Track impossible travel, session hijack signals, and risky OAuth scopes across your workspace. If a term is unfamiliar (for example OAuth scope, workspace, or idempotency key), open the Glossary.

Workspace routes:

• #/identity-risk
• #/oauth-risk

Both routes now open on Overview first screens before moving into deeper review sections. The change is presentation-only; the existing alert, event, revocation, and OAuth-risk endpoints did not change.

Quick start (10 minutes)

1. Send one identity event into the workspace.
2. Open #/identity-risk and refresh alerts.
3. Verify summary counters update.
4. Open one alert detail and confirm event context.
5. Export one alert EvidencePack (Dralvia's exportable evidence report).

Deep dive setup flow (GUI + API parity)

Prerequisites

• Active workspace API key.
• Identity event source (IdP/SIEM) able to send JSON events.
• Operator account with identity monitoring permissions.
• Active workspace sign-in session for dashboard access.

Do workspaces need to install anything?

• No local agent install is required for Identity Risk.
• You only need to stream identity/auth events from your IdP, SIEM, or auth gateway to POST /api/identity/events.
• Optional response actions (like session revoke) are handled by authorized Dralvia support operators.

Exact fields to fill

• Event payload: tenant_id, user_id, session_id, ip_address, event_type, optional geo/time/device fields.
• Optional revoke action payload: target identity/session fields required by your workspace policy.

Step-by-step flow

1. API: POST /api/identity/events with one known test event.
2. GUI: refresh #/identity-risk and check alert list.
3. API parity: GET /api/admin/identity/alerts?limit=100.
4. GUI: open summary cards and filter by severity/type.
5. API parity: GET /api/admin/identity/summary?window_hours=24.
6. Export alert evidence from UI and confirm pack metadata.

Expected result

• New event is accepted and reflected in alerts/summary.
• Filters and aggregate metrics align between UI and API.
• Evidence export is available for incident documentation.
• #/identity-risk now separates Alerts, Events, and Revocations instead of stacking those jobs on one page.

Rollback path

1. Remove or disable the test event source in your sender pipeline.
2. If a test revoke was executed, restore access/session according to IAM policy.
3. Annotate test artifacts so analysts ignore them in active triage.

Annotated screenshot

Figure: Triage identity alert, validate session context, and export evidence.

Impossible travel alerts

Boundary classification: add-on security module.

Dralvia expands this module only when customer demand, evidence quality, support readiness, and clear operating limits are in place.

Use the standard Dralvia evidence workflow and TicketBridge handoff for escalations where this module produces reviewable evidence.

Integration boundary: identity event ingestion, OAuth risk review, alert review, revocation audit visibility, and standard evidence handoff.

Setup

1. Feed login events into /identity/events (payload includes user ID, IP, geo, device, timestamp).
2. Ensure your IdP or SIEM exports geo/IP metadata so Dralvia can calculate travel distance.
3. Enable identity telemetry via your workspace settings (contact support if you don’t have access).

Investigate

1. Open Identity Risk Dashboard (#/identity-risk).
2. Use filters (workspace, severity, alert type) to focus on active issues.
3. Click an alert to view the two sessions that triggered the impossible travel. You’ll see geo coordinates, device details, and time delta.
4. Take action (force password reset, kill sessions, isolate host) and note the response in TicketBridge.
5. Use Download EvidencePack on an alert to export a signed record for audits or external ticketing.

Session revocation

• Authorized Dralvia support operators can revoke sessions when your workspace requests it.
• Each revocation is recorded and visible in the Recent Revocations table in #/identity-risk.
• Audit access: GET /admin/identity/revocations.

Contact Dralvia support to request a session revoke.

OAuth scope monitoring

• Dashboard route: #/oauth-risk
• API parity: GET /api/admin/oauth/risks?limit=100
• Data source: unified/web URL scans that include OAuth consent URLs and scope extraction.

Can workspaces use it directly?

Yes. Workspace operators can use #/oauth-risk with their normal workspace sign-in session.

Do workspaces need to install anything?

No endpoint/host agent install is required for OAuth Risk.

What must be enabled first?

1. Your workspace must be able to run scans (/scan or /unified/scan) against OAuth consent URLs.
2. Your workspace account must have access to identity/OAuth monitoring pages.
3. Your workspace sign-in session must be active (dashboard is not available anonymously).

Quick usage flow

1. Scan one OAuth consent URL through your normal scanning flow.
2. Open #/oauth-risk and start on Overview.
3. Filter by severity (high / medium) and then open Risks to review scopes.
4. Use GET /api/admin/oauth/risks for SIEM export/automation parity.

• The dashboard lists recent OAuth consent URLs with high-risk scopes (e.g., offline_access, https://mail.google.com/ send permissions).
• The detector also flags fake-host OAuth/OpenID authorize pages that reference a known provider brand on a different domain, even when the scopes themselves are sparse.
• Each entry shows the app, user, requested scopes, and whether the scope matches your allowed list.
• Entries can now also carry redirect-host and provider-mismatch context when the scanned URL used OpenID redirect parameters such as openid.return_to or hid a nested authorize target inside an encoded payload.
• Use this to train users and revoke consents that grant more power than necessary.

API access

• GET /admin/identity/alerts?severity=high returns the same data you see in the UI.
• GET /admin/oauth/risks lists recent high-scope consents; integrate it with your SIEM for automated enforcement.
• GET /portal/identity/alerts/<id>/evidencepack downloads a signed EvidencePack for a workspace-scoped alert.

Best practices

• Combine identity alerts with EDR telemetry so you can isolate a host quickly if both fire at the same time.
• Feed this data into your IAM governance reviews (monthly/quarterly) to spot risky app usage trends.
• Educate users: if they see unexpected consent prompts, they should cancel and notify security immediately.

Who this is for

This guide is for workspace owners, workspace admins, and security operators who need clear, repeatable steps without support intervention for day-to-day execution.

Role-based start here

• Workspace Owner: Start with Before you start, then complete Step-by-step and Known limits and rate limits.
• Workspace Admin: Focus on Step-by-step, What each button does, and API and automation.
• Security Analyst: Start at Day-2 operations and Troubleshooting, then use API error quick reference.
• Integrator/Engineer: Start at API and automation, then validate with Step-by-step and FAQ.

Before you start

Use this short checklist before making changes:

1. Confirm you are signed into the correct workspace account.
2. Confirm your role includes the permissions needed for this page.
3. Confirm your browser session is fresh (if pages behave unexpectedly, sign out/in once).
4. Confirm required prerequisites (API keys, agent enrollment, license, upstream integrations) are already in place.

Step-by-step

Follow this sequence for predictable results:

1. Open the workspace from the workspace menu.
2. Start on Overview and confirm current posture before opening deep lists.
3. Open Alerts, Events, or Revocations depending on the operator job you are doing.
4. For OAuth review, open #/oauth-risk, use Overview for filter/posture context, then move into Risks.
5. Run the available refresh action for the section you are using.
6. If behavior is not as expected, use Troubleshooting below before repeating actions.

Day-2 operations

After initial setup, keep this surface healthy with a simple routine:

1. Daily: verify data freshness and error banners.
2. Weekly: review trends, limits, and failed actions.
3. Monthly: review permissions, keys/tokens, and stale entities.
4. After any incident: capture evidence and update your internal operating notes.

What each button does

Button labels can vary by module, but behavior is consistent:

• Refresh: reloads the latest data from backend APIs without changing configuration.
• Save: persists workspace-scoped configuration changes.
• Run/Probe/Validate: executes a non-destructive health or verification action.
• Download: fetches workspace-scoped artifact(s) (for example bundle, checksum, signature, or report).
• Verify: checks integrity/consistency and returns pass/fail details.
• Enable/Disable: toggles module behavior for your workspace; audit evidence should be recorded.

If a button appears disabled, check role permissions, required fields, and workspace license/feature entitlement first.

Self-check playbook

Use this 5-step isolation flow before escalating:

1. Configuration: confirm required inputs are present and formatted correctly.
2. Permission: confirm your role can perform the action (401/403 usually indicates authz/authn mismatch).
3. License/feature: confirm the feature is enabled for your workspace plan and module toggles.
4. Quota/rate limit: check for 429 responses and cooldown windows.
5. Service health: if you see 5xx, retry once after 30-60 seconds and capture exact error text.

If still failing, escalate with workspace ID, UTC timestamp, route, action, payload shape (no secrets), and screenshot/error response.

Troubleshooting

Use this quick triage order to reduce time-to-fix:

1. Auth/session: refresh token by signing out/in.
2. Workspace context: confirm you are in the correct workspace.
3. Inputs/config: verify required fields and formats.
4. Quota/license: confirm limits and feature entitlement.
5. Service health: retry after short delay if backend is transiently degraded.

For escalation, include workspace ID, timestamp (UTC), route name, action attempted, and full error message.

API and automation

Everything in this page should remain workspace-scoped. If your team prefers automation, use the corresponding API endpoints with the same guardrails as the UI:

• Use authenticated requests bound to your workspace context.
• Use idempotency/retry controls where available.
• Validate outcomes in the UI after automated runs.

If your endpoint mapping is not obvious, start from Help Center and follow the linked API docs.

GUI -> API quick map

GUI action	API endpoint	Expected outcome
Ingest identity session events	POST /api/identity/events	New events processed and risk detection updated.
Review alert list	GET /api/admin/identity/alerts?limit=100	Returns latest workspace identity alerts.
Review risk summary	GET /api/admin/identity/summary?window_hours=24	Returns aggregate risk metrics.
Request revoke for risky identity/session	Contact Dralvia support	Authorized support operators execute the revoke and it is logged in revocations.

Copy-paste curl examples

BASE_URL="https://dralvia.tech"
API_KEY="YOUR_TENANT_API_KEY"

curl -sS -X POST "$BASE_URL/api/identity/events" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: $API_KEY" \
  -d '{"events":[{"user_id":"user-42","session_id":"sess-42","ip_address":"203.0.113.10","event_type":"login","tenant_id":"tenant-demo"}]}'

curl -sS "$BASE_URL/api/admin/identity/summary?window_hours=24" \
  -H "X-API-Key: $API_KEY"

Postman collection notes

• Keep a reusable event payload template with tenant_id, user_id, session_id, and ip_address.
• Add requests for summary and alerts to validate ingestion output.
• Keep one revoke request template ready for incident response.

Idempotency and retry guidance

• Use stable session_id + event timestamp in automation to reduce duplicate ingest noise.
• Retry ingest with exponential backoff on transient failures.
• For revoke, verify target state before repeating to avoid unnecessary repeated actions.

Next best actions

After finishing this page, continue with related workflows so your workspace setup stays end-to-end complete:

• EDR response and host actions
• Web Access Protection and dry-run events
• EvidencePack verification and transparency log
• Risk economics and plan recommendation
• Autonomous readiness and probes

FAQ

Q: I clicked save but nothing changed. A: Refresh once, confirm permissions, and verify required fields.

Q: Why do I see missing API key/unauthorized errors? A: Confirm your workspace API key/session is valid and mapped to the correct workspace scope.

Q: Can non-admin users use this page? A: Usually read-only access is possible; write actions require workspace-admin or equivalent roles.

Next steps

After finishing this guide:

1. Validate the result in the related dashboard/workspace.
2. Export or capture evidence if this affects compliance/incident operations.
3. Share the same runbook internally so other operators follow identical steps.
4. Return to Help Center for adjacent workflows.

API error quick reference

Use this matrix when a UI action fails with an HTTP/API error.

Error	Meaning	What to do now
401 Unauthorized	Session token is missing/expired or request is not authenticated.	Sign out/in, refresh once, then retry. Confirm your session is active in the correct workspace.
403 Forbidden	You are authenticated but your role is not allowed to perform this action.	Confirm your role includes the required permission for this button/action. Ask workspace admin to grant access.
404 Not Found	The route/resource does not exist in current workspace context (or feature not enabled).	Confirm URL/route, workspace context, and feature availability. Refresh and retry; if persistent, capture timestamp and route and contact support.
429 Too Many Requests	Rate limit/quota window was exceeded.	Wait for cooldown/reset window, retry once, then reduce burst traffic/backoff if automated.
500 Internal Server Error	Backend failed unexpectedly while processing the request.	Retry after 30-60 seconds. If still failing, escalate with workspace ID, UTC time, route, action, and full error text.

Known limits and rate limits

These limits can vary by plan and feature, but behavior is consistent:

• Burst traffic can trigger 429 Too Many Requests.
• Workspace quotas apply per feature/module and reset on configured windows.
• Repeated retries without backoff can extend recovery time during saturation.

Recommended operator behavior:

1. Retry once after cooldown for 429 responses.
2. Use exponential backoff in automation.
3. Monitor usage/quota dashboards for sustained high utilization.
4. Request quota review when normal workload regularly approaches limits.