Microsoft safelinks unlock the user before page load

I m facing a weird issue with microsoft safe links. When we send user unlock emails, microsoft changes the urls with its safe links and when a user clicks the unlock link from email microsoft opens the page in background first for security reasons, user being unlocked and token becomes invalid. So it shows unlock token is invalid when the page loads but user is already unlocked.

Is there anyone had the same issue?

Thanks.

Modify your authentication endpoint to handle preview traffic without burning the auth code. The request from safelinks / Exchange Online Protection won't include the same headers as a normal client request; review the your logs from instances where safelinks burned an auth code to get a sense for the kinds of requests you can reject as unauthorized. Ensure your endpoint is not completing the auth flow for HEAD requests (meaning return a 405 if the request's HTTP method is HEAD); if safelinks is also making GET requests, something like validating the UserAgent header before proceeding with the auth flow should probably work. You don't provide any info about your link structure or auth strategy beyond it involving some form of single-use token exchange, but you should also check the IETF RFC to confirm you're properly adhering to whichever protocol you're using.

Additional thoughts:

• The URLs in your emails should always be HTTPS links (not HTTP).
• You may lack the email sender reputation for the emails to be presumed safe; read up on strategies for developing a sterling email sender reputation.
• Your links may be presumed questionable/unsafe if the link's domain doesn't match the sender's domain.
• It's not a great solution for polished product offerings, but try including a plaintext (not hyperlinked) version of the URL in the email; most modern email clients will notice it's a link and automatically hyperlink it for the end user, but safelinks is probably scanning the raw email body for defined href attributes. Their URL parsing has historically been pretty primitive and a lot of people get around it by finding something that confuses safelinks' matching strategy (e.g., https://halon.io/blog/fooled-microsofts-safe-link-technology).
• Advise those users to add your domain to their permitlist ("whitelist") so safelinks will ignore your links.

In a Rails controller, you can add a guard like this:

class UserSessionsController < ApplicationController
  def magic_login
    # Prevent safelinks from prematurely burning access token
    return head(:method_not_allowed) unless request.get?

    # Fetch user and trigger whatever your normal login flow is
    user = fetch_user_by_access_token(params[:token])
    user&.login!
# ...

This is using ActionController::Head#head to return a 405 status with an empty body in response to anything that isn't a get request.