Skip to main content
Version 0.3Draft

Security signals and risk scoring

What are security signals and risk scoring?​

LuxID evaluates every authentication attempt against a range of contextual security signals and derives a qualitative risk indicator for each sign-in event.

Planned - not yet available

The contextual risk-scoring engine described on this page - the luxid_risk_level / luxid_risk_score ID Token claims and the automatic step-up / block actions - is a planned feature on the LuxID backlog and is not live yet. The Friendly Captcha bot protection and the email-validity / disposable-email checks described below are in production. Confirm the current status with LuxID before building against the risk claims.

This risk indicator is surfaced as a custom claim in the ID Token, giving Partner applications a real-time signal about the trustworthiness of each authentication.

Risk scoring operates transparently: it does not change the authentication flow or require any action from the user in most cases. When LuxID assesses an attempt as high risk, it may step up MFA requirements or block the attempt automatically. Partners can also act on the risk claim independently.

Security signals​

LuxID draws on a range of contextual signals at each sign-in attempt. The specific signals, how they are weighted, and the thresholds at which they trigger an outcome are operational and are not published - this prevents attackers from optimising their techniques to evade detection. The subsections below describe the signal categories at a conceptual level only.

CAPTCHA - friendly captcha​

LuxID uses Friendly Captcha (opens in a new tab), POST Luxembourg's approved privacy-first bot-protection solution. Friendly Captcha is GDPR-aligned, does not track users, and does not require user interaction in normal cases.

Where Friendly Captcha can be triggered:

Decision logic: When the LuxID web page loads, it asks the server whether captcha is required for the current context. If the context is assessed as risky, captcha is enabled for the requested page. Captcha may also auto-activate in response to abusive patterns such as brute-force or credential-stuffing attempts. The exact activation logic is operational and tuned over time - it is not publicly documented to prevent attackers from optimising around it.

Successfully completing a Friendly Captcha challenge does not by itself lower the risk assessment; it confirms human presence but other signals continue to be evaluated.

Contextual and behavioural signals​

In addition to bot protection, LuxID assesses each attempt against contextual signals such as the network it originates from, how it compares with the user's established sign-in history, characteristics of the requesting device, and whether the interaction pattern looks human or automated. A known, consistent context lowers the risk assessment; an anomalous or automated one raises it.

LuxID does not publish the individual signals, the threat-intelligence sources it consults, or the weighting between them. These signals are used solely for session risk assessment - LuxID does not build cross-application user profiles for advertising.

Email validity and disposable email rejection​

LuxID performs validity checks on the email address at registration and on any email-change request:

  • Syntactic validity - the email must conform to standard format (RFC 5322 plus practical relaxations).
  • DNS validity - the domain must have a valid MX record so the address is at least mail-deliverable.
  • Disposable-email rejection - email addresses on known disposable or throwaway providers may be rejected with an error message asking the user to use a stable address.

This applies symmetrically to:

From the Partner's perspective, no extra configuration is required - LuxID enforces these checks centrally. Partners that consume the email_verified claim from LuxID can trust that the email is syntactically valid, has a deliverable domain, and is not on a known disposable-mail provider.

Risk indicator claims​

The result of the signal evaluation is surfaced as a qualitative risk indicator in the ID Token. A luxid_risk_level claim conveys a categorical assessment (for example "low", "medium", or "high"). A companion luxid_risk_score claim may also be present where Partner configuration enables it; treat it as an opaque LuxID-internal value rather than a published, fixed scale.

Use the categorical luxid_risk_level for your application logic rather than reasoning about any underlying numeric value, whose scale LuxID does not publish and may recalibrate.

Example ID Token with the risk claim​

{
  "iss": "https://login.luxid.lu",
  "sub": "a3f2c1d8-9b4e-4a2f-8c1d-3e7b9a2f1c4d",
  "aud": "app_mypost_prod",
  "iat": 1748477100,
  "exp": 1748480700,
  "auth_time": 1748477100,
  "acr": "urn:luxid:acr:level:substantial",
  "amr": ["pwd", "otp"],
  "email": "utilisateur@example.lu",
  "email_verified": true,
  "luxid_risk_level": "low"
}

A higher-risk sign-in carries "luxid_risk_level": "high" in the same position.

LuxID automatic actions​

LuxID's risk evaluation maps to qualitative outcomes, applied automatically before an attempt reaches the token issuance stage:

OutcomeLuxID action
AllowProceed normally. The risk claim is included in the token.
Step upMay present a step-up MFA challenge if a stronger factor has not already been completed.
BlockThe sign-in may be blocked entirely pending manual review.

LuxID's automatic actions are the first line of defence. Partner-side logic using the risk claim provides a second layer.

Partner use cases​

Require step-up for high-value transactions​

Your application can use the luxid_risk_level claim to gate sensitive operations such as payments, address changes, or data exports:

function authoriseTransaction(idTokenClaims, transactionValue) {
  const riskLevel = idTokenClaims.luxid_risk_level;

  if (riskLevel === 'high') {
    return { allowed: false, reason: 'elevated_risk' };
  }

  if (riskLevel === 'medium' && transactionValue > 500) {
    // Trigger step-up: redirect to LuxID with acr_values=urn:luxid:acr:level:substantial and prompt=login
    return { allowed: false, reason: 'step_up_required' };
  }

  return { allowed: true };
}

Block access on high risk​

For applications requiring high assurance, reject tokens where luxid_risk_level is "high" and log the event for investigation:

function validateRisk(idTokenClaims) {
  if (idTokenClaims.luxid_risk_level === 'high') {
    logger.warn('High-risk authentication accepted by LuxID', {
      sub: idTokenClaims.sub,
      risk_level: idTokenClaims.luxid_risk_level,
      auth_time: idTokenClaims.auth_time,
    });
    throw new AccessDeniedError('Risk level too high for this application.');
  }
}

Event: user.risk.escalated​

Planned, not yet available

This event is part of the planned Event Hub catalogue. Today the Event Hub emits only ClaimValuesChanged (pull delivery); user.risk.escalated is not emitted yet. See Events and Event Hub for the current state, and confirm availability with LuxID before building against it.

When emitted, a user.risk.escalated event will be raised on the Event Hub when LuxID's risk engine escalates a session to high risk during or after authentication. This event may arrive for sign-in attempts that LuxID ultimately allowed (because the user passed step-up MFA) or blocked.

{
  "event_type": "user.risk.escalated",
  "event_id": "evt_0d1e2f3a-4b5c-6d7e-8f9a-0b1c2d3e4f5a",
  "occurred_at": "2026-05-22T03:22:00Z",
  "application": {
    "id": "app_mypost_prod",
    "name": "MyPost"
  },
  "subject": {
    "sub": "a3f2c1d8-9b4e-4a2f-8c1d-3e7b9a2f1c4d",
    "email": "utilisateur@example.lu"
  },
  "context": {
    "ip_address": "198.51.100.88",
    "user_agent": "python-requests/2.31.0"
  },
  "data": {
    "risk_level": "high"
  }
}

Treat the event as informational for investigation and alerting. Do not implement business logic that depends on parsing LuxID-internal risk detail, as the underlying signals and their representation may evolve and are not published.

Once this event is available, you will be able to subscribe to user.risk.escalated events with LuxID to receive these alerts. See Events and Event Hub.

Configuration​

Requesting the risk claim​

The risk indicator (luxid_risk_level, and luxid_risk_score where enabled) is included in the ID Token subject to Partner configuration. No special scope is required.

If your claims template (configured with LuxID) explicitly restricts claims, ensure the risk claim is not excluded.

Partner-side thresholds​

LuxID does not expose per-Application risk threshold configuration in the Console - LuxID applies its automatic step-up and block logic platform-wide. Partner applications implement their own logic against the qualitative luxid_risk_level they receive.

A reasonable starting point is to require step-up for "medium" on high-value transactions and to reject access for "high". Adjust based on your application's risk appetite and fraud observation.

Security and privacy notes​

Risk claims are advisory. LuxID includes the risk claim in tokens after the authentication has completed. A luxid_risk_level of "high" in a token means LuxID assessed the session as risky but the user ultimately authenticated (perhaps after step-up MFA). Your application should use this signal to apply additional controls, not assume LuxID has already blocked the threat.

Do not expose the risk claim to users

The risk claim is intended for server-side logic. Do not surface it in your UI or error messages - doing so could help attackers tune their techniques to avoid detection.

Contextual signals are privacy-preserving. The signals LuxID evaluates are used solely for session risk assessment, compared against the user's own history, and not shared with Partners or third parties for profiling purposes.

Risk signals and GDPR. The contextual signals LuxID evaluates are used solely for risk assessment and are not stored as part of the user's profile. The derived risk indicator is included in the token under LuxID's legitimate interest basis (GDPR Article 6(1)(f)) for platform security.

Detection-model confidentiality. The specific signals and threat-intelligence sources used by LuxID are not disclosed publicly. Partners should not attempt to replicate or reverse-engineer LuxID's risk model.

Updated 2026-06-05
On this page