Skip to content
Docs

RADIUS, Magic Link & Push MFA Authentication Guide

This page shows how authentication actually works in Mideye — step by step, with sequence diagrams. For component descriptions, see System Architecture. For the full list of authentication types, see Authentication Types.

RADIUS authentication (SMS OTP)

Section titled “RADIUS authentication (SMS OTP)”

The most common flow. A VPN or firewall sends a RADIUS request to Mideye Server, which validates the password and delivers a one-time password via SMS.

UserVPN / FirewallMideye ServerMideye Switch 1. Login (username + password)2. RADIUS Access-Request3. Validate password vs LDAP/AD4. Request OTP delivery 5. SMS with OTP6. Enter OTP7. RADIUS Access-Request (with OTP)8. Validate OTP9. Access-Accept ✓Access granted
  1. User enters username and password in the VPN client.
  2. The VPN sends a RADIUS Access-Request to Mideye Server.
  3. Mideye Server validates the password against LDAP/AD or the local database.
  4. Mideye Server sends an OTP delivery request to Mideye Switch.
  5. The Switch routes the SMS to the user’s phone via telecom providers.
  6. The user enters the OTP in the VPN client.
  7. The VPN sends a second RADIUS Access-Request with the OTP.
  8. Mideye Server validates the OTP.
  9. If valid, a RADIUS Access-Accept is returned — access granted.

Touch authentication (push)

Section titled “Touch authentication (push)”

Touch replaces SMS codes with a push notification. The user taps approve or reject directly in the Mideye+ app — no code entry needed.

UserVPN / FirewallMideye ServerMideye SwitchPush ServiceMideye+ App 1. Login (username + password)2. RADIUS Access-Request3. Validate password vs LDAP/AD4. Request Touch notification5. Route to Push Service6. Push via APNs/FCM7. User taps Approve8. Approval response9. Forward result10. Touch accepted11. Access-Accept ✓Access granted
  1. User enters username and password in the VPN client.
  2. The VPN sends a RADIUS Access-Request to Mideye Server.
  3. Mideye Server validates the password.
  4. Mideye Server requests a Touch notification via Mideye Switch.
  5. The Switch routes the request to the Push Service in the cloud.
  6. The Push Service sends a push notification to the Mideye+ app (via Apple APNs or Google FCM).
  7. The user taps Approve (or Reject) in the Mideye+ app.
  8. The app sends the approval back to the Push Service.
  9. The result is forwarded through the Switch.
  10. Mideye Server receives the approval.
  11. A RADIUS Access-Accept is returned — access granted.

No code entry required. The VPN does not need to support challenge-response for Touch (authentication type 6).

Fallback behavior

Section titled “Fallback behavior”
  • Touch-Plus (type 7): If the phone isn’t reachable via push, falls back to Plus (manual TOTP from the Mideye+ app) or on-premise TOTP if configured.
  • Touch-Mobile (type 8): If push fails, falls back to encrypted SMS to the Mideye+ app. If the phone is completely unreachable, falls back to Plus or on-premise TOTP.
  • No Mideye+ app: Users without Mideye+ automatically get an SMS Magic Link instead of Touch.
Section titled “Magic Link authentication”

Magic Link provides MFA for web applications via REST API. Instead of entering a code, the user taps Accept or Reject — either via a Mideye+ push notification or by clicking a link in an SMS.

Your Web AppMideye ServerMASMideye SwitchUser's PhoneMideye+ pathSMS path 1. API call (/api/sfwa/auth)2. Create Magic Link session3. Send authentication request4a. Push notification4b. SMS with magic link5. User clicks link6. Result returned{"code":"TOUCH_ACCEPTED"}User approves or declines
  1. Your application calls the Magic Link API with the user’s phone number.
  2. Mideye Server creates a Magic Link session on MAS and waits for the user’s response.
  3. Mideye Server sends the phone number and authentication request to Mideye Switch.
  4. Switch determines how to reach the user:
    • 4a. If the user has the Mideye+ app, Switch sends a push notification directly.
    • 4b. If not, Switch delivers an SMS with a link pointing to MAS.
  5. If reached via SMS, the user clicks the link and opens the approval page hosted on MAS.
  6. MAS returns the result to the waiting Mideye Server, which returns it to your application.

API example

Section titled “API example”
GET /api/sfwa/auth?msisdn=+46701234567
Header: api-key: <your-api-key>


→ {"code":"TOUCH_ACCEPTED"}
→ {"code":"TOUCH_REJECTED"}
→ {"code":"USER_NOT_RESPONDED"}

See Magic Link API for full API documentation.

Assisted Password Reset

Section titled “Assisted Password Reset”

A dedicated flow for password resets that requires MFA verification and approval from a designated approver.

User (browser)Mideye ServerApprover (Mideye+) 1. Enter username2. Send OTP (SMS/push)3. Send approval push request4. Approve5. Enter new password6. Password changed in LDAP/AD
  1. User enters their username on the password reset portal.
  2. Mideye sends an OTP to verify the user’s identity.
  3. An approval request is sent to designated approver(s) via Mideye+.
  4. Once approved, the user can proceed.
  5. The user sets a new password.
  6. The password is changed in the connected LDAP/Active Directory.

Rate limiting is built in to protect against abuse.

On-premise TOTP (air-gapped)

Section titled “On-premise TOTP (air-gapped)”

For environments without internet access. Users authenticate with a TOTP code generated by an authenticator app or hardware token — no Mideye Switch or cloud services needed.

  1. User enters username and password.
  2. The VPN sends a RADIUS Access-Request to Mideye Server.
  3. Mideye Server validates the password against LDAP/AD.
  4. Mideye Server sends a RADIUS Access-Challenge asking for the TOTP code.
  5. User enters the current TOTP code from their authenticator app or hardware token.
  6. Mideye Server validates the code against the stored seed — entirely locally.
  7. If valid, a RADIUS Access-Accept is returned.

No network connectivity to Mideye services is required. See Authentication Types for setup details on on-premise TOTP tokens.

Next steps

Section titled “Next steps”