Skip to main content

Magic Links solution guide

Magic Links in Entrust Identity as a Service (IDaaS) let users sign in or confirm email ownership using a single-use, time-limited link delivered by email instead of a password. This guide explains how Magic Links work, the problems they solve, when to use them, and how to integrate them with your existing IDaaS policies and authentication flows.

How it works​

A Magic Link is a unique, time-limited URL that IDaaS generates and sends to a user's configured email address. The link encodes a one-time token tied to the user and the requested action.

The flow works as follows:

  1. An administrator or IDaaS generates a Magic Link for a user (for registration, password reset, or authentication).
  2. IDaaS emails the link to the user's configured email address.
  3. The user opens the email and clicks the link.
  4. IDaaS validates the link — confirming it has not expired and has not already been used.
  5. If the link is valid, the user is authenticated or their action is completed, and they are redirected to the application or a configured redirect URL.

Magic Links are single-use. Once a user clicks the link or the lifetime expires, the link is invalidated and cannot be reused.

IDaaS supports three distinct Magic Link types, each designed for a specific stage of the user journey.

TypePurposeTriggered by
Registration Magic LinkCompletes initial user enrollmentAdministrator or automatic email on user creation
Password reset Magic LinkResets a user's password without requiring recovery stepsAdministrator or self-service request
Authentication Magic LinkAuthenticates a user as part of a sign-in flowUser selecting Magic Link as a second-factor option

Each type must be individually enabled in Policies > Authenticators > Magic Link and, for authentication, in the resource rule authentication flow.

Use Magic Links when you want to simplify user sign-in while still enforcing security policies.

Customer problemHow Magic Links helpTypical business outcome
High onboarding drop-off for new usersSend a registration link directly to the user email address so users can start enrollment quickly.Faster first successful sign-in and fewer incomplete registrations.
Help desk volume from password reset requestsSend password reset links without requiring users to complete complex recovery paths first.Lower help desk load and faster user recovery.
Friction in sign-in experiencesAdd Magic Link as an authentication option in flows so users can authenticate from their inbox.Higher sign-in completion rates for users who struggle with other authenticators.
Need to confirm email ownership during user actionsDeliver a single-use, time-limited link to the destination email.Better confidence that the user controls the target mailbox.
Poor continuity after registration or resetRedirect users to approved application destinations after link completion.Smoother end-to-end journeys and fewer dead-end user flows.

Common solution scenarios​

Use these scenarios to map Magic Links to real customer workflows.

Guided first-time onboarding​

Use administrator-initiated registration links for newly created users so they can complete initial setup with minimal friction. When a new user account is created, the administrator sends a registration Magic Link directly to the user's email. The user clicks the link and is taken through the enrollment flow without needing a temporary password.

To implement this pattern:

  1. In Policies > Authenticators > Magic Link, enable Registration Magic Link.
  2. Optionally, enable Automatically Email Magic Links to have IDaaS send the registration link automatically when a new user is created, rather than requiring the administrator to send it manually.
  3. Configure the Default User Email Attribute to ensure the link is delivered to the correct address.
  4. Enable user registration in Policies > Registration and set the registration period and required authenticators. See Configure user registration.
  5. To send a registration link to a specific user manually, go to Members > Users, click the actions menu next to the user, and select the email option. See Configure Magic Links for users.

Self-service recovery at scale​

Enable password reset links to reduce manual support interactions when users are locked out or have forgotten their password. An administrator sends a password reset Magic Link to the user's configured email address. The user clicks the link and resets their password without requiring help desk involvement.

To implement this pattern:

  1. In Policies > Authenticators > Magic Link, enable Password Reset Magic Link.
  2. Configure password reset policies to allow user-initiated or administrator-initiated resets. See Enable password reset.
  3. To send a password reset link to a specific user, go to Members > Users, click the actions menu next to the user, select the email option, and choose Password Reset as the link type.

Alternative authentication path​

Add Magic Link as a second-factor option in an authentication flow for applications where you want to offer an email-based alternative. When a user selects Magic Link on the sign-in page, IDaaS sends a link to their configured email address. The user clicks the link to complete authentication.

To implement this solution:

  1. In Policies > Authenticators > Magic Link, confirm Magic Link is enabled.
  2. Create or edit an authentication flow and add Magic Link as a second-factor authenticator. See Create authentication flows.
  3. Assign that authentication flow to the resource rule that protects the target application.
  4. Confirm the user has a Magic Link email address configured. See Configure Magic Links for users.

Post-action return routing​

Use redirect URLs to send users to a specific page in your application after they complete a registration or password reset Magic Link flow. This avoids leaving users on a generic confirmation page and improves continuity in the user journey.

To implement this solution:

  1. In Policies > Authenticators > Magic Link, enable Redirect Enabled.
  2. Click Add and enter the base URL of the destination page in your application. You can add up to 20 redirect URLs.
  3. When sending a Magic Link using the Administration API, include the redirect URL in the request. IDaaS validates the base URL against the allowed list and permits query parameters to vary, so you can pass route or state information to return users to a specific page. See Magic link events for API details.

Magic Links are one option in a broader authentication strategy.

  • Use Magic Links when you want quick access for users, faster onboarding, or simpler account recovery.
  • Use passkeys or other stronger authenticators when you need higher assurance and better protection against phishing.
  • Use resource rules and authentication flows to limit where and when Magic Links can be used.

Security considerations​

Keep the following in mind when deploying Magic Links.

  • Phishing risk: Magic Links sent by email carry inherent phishing risk. A user who forwards or exposes the email could allow an unintended party to complete registration, reset a password, or authenticate. For authentication Magic Links, limit use to lower-assurance applications and configure resource rules to route high-risk scenarios to authentication flows that require stronger authenticators, or to deny access before authentication begins.
  • Link lifetime: Set the shortest practical lifetime. Shorter lifetimes reduce the window of exposure if a Magic Link email is intercepted or delayed.
  • Redirect URL security: IDaaS validates the base redirect URL against the allowed list. Query parameters can vary, which lets clients pass route or state information so users return to a specific page after completing the Magic Link flow. Wildcards, custom paths, and custom ports are not permitted in the base URL. Restrict the allowed redirect URL list to known, trusted application destinations.
  • Redirect URL scope: The redirect URL feature is only available to users of the Administration APIs. Users authenticating through the standard portal are not affected.
  • Single-use enforcement: IDaaS invalidates a Magic Link after first use or expiry. Do not extend lifetimes unnecessarily to compensate for delayed email delivery; instead, investigate the underlying email delivery issue.

Limitations​

Be aware of the following constraints before implementing Magic Links.

  • Redirect URLs are only supported for users of Administration APIs, not for standard portal users.
  • IDaaS matches redirect URLs against the base URL only; query parameters can vary. Wildcards, custom paths, and custom ports are not permitted in the base URL.
  • You can configure up to 20 redirect URLs per tenant.
  • The redirect URL feature is disabled by default and must be explicitly enabled.
  • Magic Link authentication requires Magic Link to be enabled as a second-factor authenticator in the resource rule authentication flow for the target application.

Prerequisites​

Before you configure Magic Links, confirm the following.

  • You have administrator access to Policies > Authenticators in IDaaS.
  • Outbound email delivery is configured for your tenant so IDaaS can send Magic Link emails.
  • You have identified which Magic Link types (registration, password reset, authentication) you want to enable.
  • For authentication Magic Links, you have access to the resource rules for the target applications.

Implementation checklist​

Follow these steps to set up Magic Links.

  1. Set Magic Link policies at the tenant level, including the link lifetime, which Magic Link types to enable, and any allowed redirect URLs.
  2. Configure the email address used to send Magic Links — either a default user email attribute or per-user configuration.
  3. If you are enabling registration Magic Links, confirm that user registration is enabled in the user policy.
  4. If you are enabling password reset Magic Links, confirm that password reset is enabled and configured.
  5. If you are enabling authentication Magic Links, add Magic Link as a second-factor authenticator in the resource rule authentication flow for each target application.
  6. Optionally, customize the Magic Link email templates to match your organization's branding. IDaaS provides separate templates for registration, password reset, and authentication Magic Link emails. See Customize email templates.
  7. Test the end-to-end user journey for each enabled type:
    • Registration: Create a test user and confirm the registration link arrives, completes enrollment, and redirects correctly if redirect is enabled.
    • Password reset: Trigger a password reset and confirm the link arrives, resets the password, and expires after use.
    • Authentication: Sign in to a target application and confirm Magic Link appears as an option, delivers a link, and authenticates successfully.

API integration​

The Administration API lets you create, retrieve, and delete Magic Links programmatically. Use the API to automate user onboarding, integrate Magic Links into provisioning pipelines, or build custom portals that trigger Magic Links on demand.

OperationEndpointRequired permission
Create a Magic Link for a userPUT /api/web/v1/users/{userid}/magiclinkMAGICLINKS:ADD
Get the Magic Link for a userGET /api/web/v1/users/{userid}/magiclinkMAGICLINKS:VIEW
Delete the Magic Link for a userDELETE /api/web/v1/users/{userid}/magiclinkMAGICLINKS:REMOVE

The redirect URL feature — which returns users to a specific page after completing a Magic Link flow — is only available when creating Magic Links via the Administration API. See Limitations for redirect URL constraints.

To monitor Magic Link email delivery, subscribe to the magiclink.email.sent webhook event. This event fires each time a Magic Link email is sent and includes the Magic Link type, the destination email address, and the user ID. See Magic link events.

For full request and response schemas, see the Magic Link API reference.

Next steps​

After reviewing this guide, configure Magic Links for your tenant. See Configure Magic Links.