JanssenProject / JanssenProject/jans

feat(jans-fido2): operational alert hooks for native passkey rollout failures

Open
#14,609 0 comments 0 reactions 1 assignee Claimed by @imran-ishaq View on GitHub
comp-jans-fido2 kind-feature
Dominant language
Java
Stars
647
Forks
173
Avg merge
1d 18h
Merged PRs (30d)
110

Description

**Is your feature request related to a problem? Please describe.**
Many native failures only appear *after* a release (wrong Play signing key, stale Apple CDN AASA, OEM-specific failures, WebView mismatch, third-party credential provider cancellations). Nothing in Jans proactively alerts on these; an operator finds out when users complain. The metrics subsystem records the raw signal and pre-computes aggregations, but there's no threshold/alert layer on top.

**Describe the solution you'd like**
Add operational alert hooks for thresholds/regressions computed from the (mobile-extended) metrics:
- `invalid_origin` spike after an app release; registration/auth failure spike for one `app_version` or one Android OEM; fallback spike after a passkey prompt; Play Services version cluster failures; AASA/`assetlinks.json` readiness degradation (from the readiness checker); MDS refresh stale/failed (from the attestation/MDS visibility work); `rpIdHash` mismatch spikes; WebView-origin failures above baseline.
- Deliver via **first-class integrations** rather than only the FIDO2 external-script hooks: webhook, OpenTelemetry event, Prometheus metric, and/or SIEM-friendly structured log. (Note: current counter/timer helpers largely *log* metrics; real OTel/Prometheus counters/histograms would make alerting robust.)
- Keep alerting opt-in and threshold-configurable.

**Describe alternatives you've considered**
- *Only expose metrics and let operators build their own alerts externally* — acceptable minimum, but misses the native-specific, ready-made thresholds that make this valuable.
- *Implement purely via `FIDO2_EXTENSION` scripts* — possible for customization, but alerting should be a first-class integration, not per-deployment scripting.

**Additional context**
Depends on the mobile-metrics extension (dimensions) and consumes the readiness-checker and attestation/MDS health signals.
Corbado article — https://www.corbado.com/blog/native-ios-android-passkey-implementation-challenges ;
ChatGPT analysis — https://chatgpt.com/share/6a5129bc-a8f4-83ea-8649-3e463e0a7db3

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.