Magic Link MFA: SMS & Push Authentication API Guide

Magic Link is Mideye Server’s passwordless authentication method for web applications. Instead of asking users to type a one-time code, Magic Link sends an approval request — either as a push notification to the Mideye+ app or as an SMS containing a clickable link. The user taps Accept or Reject, and your application receives the result via a simple REST API call.

What is Magic Link authentication?

Traditional MFA requires the user to copy a code from their phone into a login form. This works well for VPN clients that support RADIUS challenge-response, but it adds friction to web application logins.

Magic Link removes that friction. Your web application calls the Mideye Server REST API with the user’s phone number, and Mideye handles the rest:

If the user has the Mideye+ app, they receive a push notification and tap Approve or Reject.
If the user does not have the Mideye+ app, they receive an SMS with a link. Clicking the link opens a web page where they can approve or reject the login.

Either way, your application gets a simple response: accepted, rejected, or timed out. No RADIUS, no challenge-response, no code entry.

How does Magic Link work?

The authentication flow

Your web application calls the Mideye Server Magic Link API with the user’s phone number and your API key.
Mideye Server creates a Magic Link session on MAS (Mideye Application Service) and sends the authentication request to Mideye Switch.
Mideye Switch determines the best delivery method:
- If the user has Mideye+ activated, a push notification is sent directly to the app.
- If not, an SMS is sent containing a link that points to the MAS approval page.
The user responds:
- Push users tap Approve or Reject in the Mideye+ app.
- SMS users click the link, opening a web page where they tap Accept or Decline.
MAS returns the result to Mideye Server, which returns it to your application.

The entire flow typically completes in seconds. Your application makes one API call and receives one response — no polling, no webhooks, no complex integration.

The API

Magic Link uses a single REST endpoint:

GET /api/sfwa/auth?msisdn=+46701234567
Header: api-key: <your-api-key>

The response indicates the outcome:

Response code	Meaning
`TOUCH_ACCEPTED`	User approved the login
`TOUCH_REJECTED`	User rejected the login
`USER_NOT_RESPONDED`	User didn’t respond within the timeout

Each Magic Link endpoint in Mideye Server has its own API key, allowing you to integrate multiple applications with separate keys and configurations.

For full API documentation, see Magic Link API.

When should you use Magic Link?

Magic Link is designed for scenarios where RADIUS isn’t available or appropriate:

Web application MFA

Your web application authenticates users with username and password (or SSO), then calls the Magic Link API to verify the user’s identity with a second factor. This is ideal for internal portals, admin panels, and customer-facing applications that need MFA without a RADIUS integration.

Customer-facing portals

For public-facing applications where user experience matters, Magic Link provides a low-friction second factor. Users don’t need to install an app or type codes — they just click a link or tap a notification.

Step-up authentication

Use Magic Link for high-risk operations within an already-authenticated session. For example, a user is logged in but wants to approve a large transaction, change account settings, or access sensitive data. Calling the Magic Link API at that point adds a second factor without disrupting the user’s workflow.

Passwordless authentication

Magic Link can serve as the only authentication factor for low-risk applications. The user’s phone possession becomes the sole factor — suitable for scenarios where the application content isn’t sensitive but you still want to verify identity.

Magic Link vs RADIUS MFA

Aspect	Magic Link	RADIUS MFA
Protocol	REST API (HTTPS)	RADIUS (UDP) or RADSEC (TLS)
Best for	Web applications, portals, APIs	VPNs, firewalls, network equipment
Code entry	No — user taps Approve or clicks a link	Depends on auth type — some require code entry
Integration effort	Single API call	RADIUS client configuration
Challenge-response support	Not needed	Required for some authentication types
Works for	Any application that can make HTTP requests	Any device that speaks RADIUS

Most organizations use both: RADIUS for VPN and network access, Magic Link for web applications. Mideye Server handles both from the same server, with the same user database and policies.

Automatic delivery selection

One of Magic Link’s key features is automatic delivery selection. You don’t need to know whether the user has the Mideye+ app installed — Mideye handles it:

Users with Mideye+ receive a push notification. This is faster and more secure — the approval happens within the app, protected by biometric authentication (Face ID, fingerprint).
Users without Mideye+ receive an SMS with a clickable link. The link opens a secure web page hosted on MAS where the user approves or rejects.

This means you can integrate Magic Link once and it works for all your users, regardless of whether they’ve installed the Mideye+ app.

Fallback chain

If push delivery fails (phone offline, notifications disabled), Magic Link falls back to SMS delivery automatically. The user experience degrades gracefully rather than failing completely.

Security considerations

What travels over the network

The API call from your application to Mideye Server contains only the user’s phone number and your API key. No passwords, no session tokens, no sensitive application data.

The SMS message contains a link — not a code. The link points to a session-specific page hosted on MAS. The session expires after a configurable timeout.

Push notifications contain only a challenge identifier. The Mideye+ app fetches the details from the server and handles approval locally.

API key management

Each Magic Link endpoint has its own API key. Keys can be regenerated through the Mideye Server admin interface without affecting other endpoints. Use separate keys for separate applications to maintain isolation.

Replay protection

Each Magic Link session is single-use. Once a user approves or rejects, the session is closed. The link cannot be clicked again, and the same session ID cannot be submitted twice.

Data flow

Understanding where data goes during a Magic Link authentication:

Data	Where it goes	Stored?
Phone number	Mideye Server → Switch → SMS provider	Not stored after delivery (logs: 30 days)
Magic Link session	MAS (Mideye Cloud, Sweden)	Session duration only (logs: 30 days)
Push notification payload	Mideye Cloud → APNs/FCM → user’s phone	Not stored after delivery (logs: 30 days)
API key	Your application → Mideye Server	Stored on your server only
Authentication result	Mideye Server → your application	Logged on your server

Note: Operational logs (timestamps, delivery status, error codes) are retained for 30 days in centralized log analytics (Sweden) for monitoring and troubleshooting. These logs do not contain message content, OTP codes, or user credentials.

Next steps

Authentication Flows — Magic Link — Full sequence diagram
System Architecture — How MAS, Switch, and Server connect
What is RADIUS? What is RADSEC? — For VPN/network MFA instead of web apps
Data Residency — Where Magic Link data goes