Skip to main content

How it works

⚙️ How It Works

GuardianKey Auth Security operates as a real-time risk analysis system, capable of evaluating authentication attempts based on behavioral profiling, access context, and threat intelligence. The architecture consists of three main stages: event capture, risk processing, and automated response.

🛰️ 1. Event Capture

The protected application sends authentication events to GuardianKey via:

  • HTTP/REST API
  • UDP Packet (for high-performance environments)

Each event contains information such as:

  • Source IP address
  • Authentication result (success/failure)
  • Timestamp
  • Browser, OS, and device (via User-Agent)
  • User identifier

❗ GuardianKey does not collect passwords nor requires changes to the system's authentication flow.

🧮 2. Risk Processing and Analysis

Upon receiving the event, GuardianKey applies a proprietary probabilistic formula that calculates a risk score (0 to 100) by combining two axes:

  • Contextual Risk
    Based on deviations from the user's typical behavior (geolocation, device, ASN, time, etc.)

  • Threat Intelligence Risk
    Analysis of the IP origin against reputation lists, TOR networks, known attack IPs, etc.

The system also automatically detects brute-force attacks, progressively increasing the risk based on repeated attempts.

📤 3. Access Attempt Response

Based on the risk score and administrator-defined policies, GuardianKey returns a response recommendation to the application:

  • ✅ Accept
  • ✉️ Notify
  • ⚠️ Notify with action
  • ❌ Block

The client application can then act according to these recommendations — for example, requesting additional verification, notifying the user, or denying login.

The system can also send notifications via email or webhook, allowing the user to confirm if the access was legitimate, helping to train the model.

🔎 Behavioral Consolidation

GuardianKey maintains a behavioral database per user, per user group (authgroups), or per organizational unit, allowing risk handling segmentation and profile sharing between different systems if needed.

📌 Notes

  • The system does not rely on tokens, mobile apps, or conventional MFA methods.
  • It works transparently for the end user.
  • Processes events with both IPv4 and IPv6 addresses.
  • Provides reference APIs and SDKs in several languages (PHP, Python, Node.js, Java, Ruby, Lua, etc.).