A deep link that dumps a logged-in user at login is broken
They were already signed in. The email link opened your app and dropped them on the login screen anyway. That is not caution—it is a broken handoff between intent and session.
Deep links must respect an existing session when the target only needs that assurance level. Reserve forced re-auth for high-risk actions. Measure success as landing on the intended object, not merely opening the app. A login wall for an already authenticated user is a product defect.
The link that forgets who you are
A logged-in customer taps a universal link from email: order details, a permit status, a shared cart. The app opens. The splash passes. They land on the login screen—or a marketing home—while another tab or the system account store still holds a valid session. They did not sign out. Your deep link simply failed to carry intent through the auth gate.
Take a field technician who gets a push at 7:10 AM: "Your first job moved to 8:30—tap to see the new address." She has used the app every day this week. The tap opens a password screen. She does not remember the password because she never types it; biometrics handle that inside the app. She calls dispatch instead, and the notification that was supposed to save a phone call created one.
A deep link that dumps a logged-in user at login is broken. It is not a security feature. It is a drop in trust at the exact moment you asked them to come back.
For: strict gates feel safer
There is a real case for caution. Token handoff across apps, webviews, and OS link handlers is where session bugs and open-redirect classes live. Teams that have been burned by link-parameter injection sometimes overcorrect: every cold start must re-authenticate; every universal link must land on a chooser; every web URL must ignore existing cookies until password entry.
That posture can be correct for high-risk actions—changing payout destinations, approving wire instructions, viewing sealed records. It is the wrong default for "view the order you already own" and "continue the application you already started." Security review should classify link targets by risk, not apply one hammer.
Caution also has a legitimate shape when the link itself carries a credential. A magic sign-in link is a login token, not a pointer to a record. Keep the two separate: object links should point at the record and lean on the existing session, while one-time login links should never be reused as navigation, and consuming one should not silently end a session the user has open in another client.
Decision guide
Forced re-auth vs session resume
| Consideration | Forced login always | Resume when session suffices |
|---|---|---|
| Low-risk view | Friction on every email tap. | Open the object if session is valid. |
| High-risk change | Appropriately cautious. | Still challenge; do not skip step-up. |
| Analytics | App opens look healthy. | Object-landed is the real metric. |
| User trust | App feels forgetful. | App remembers the job. |
| Security review | One hammer for all links. | Risk table per target type. |
A deep link that dumps a logged-in user at login is broken.
Against: login walls that ignore a live session
If a session is already valid for the required assurance level, the deep link should resume into the target screen after the same checks you would run for in-app navigation. Requiring a fresh login because the entry point was a link trains users to hate your email program and to paste passwords more often—not a security win.
Universal links and app links that open the app but discard the path are equally broken: home screen with no toast is still a failed handoff. Log the intended path, restore it after auth if auth was truly required, and never claim success in analytics when the user saw login instead of the object.
The common causes are mundane. The link router runs before the session store finishes loading on cold start, sees no user, and redirects. Or the router only knows the login screen as a fallback, so any missing parameter becomes a login wall. Or an email tool rewrites the link for click tracking and the app no longer recognizes the domain. Each of these is fixable in a sprint once someone looks.
How the work moves
Deep-link cases to test before the campaign
- Warm + logged in
Should open the object without a login wall.
- Cold start + logged in
Session restore then object—not marketing home.
- Logged out
Login, then resume the intended path.
- Expired token
Re-auth, remember path, then object.
- No entitlement
Plain explanation—not a generic login loop.
Design the handoff on purpose
For each deep-link type, specify: required auth level; whether an existing session suffices; where to land if session is missing; where to land if session is present but lacks entitlement; how long the path is remembered across a forced login; and what the user sees if the object expired.
When entitlement is the problem, say so in plain language. "This order belongs to a different account—switch accounts?" or "This job was reassigned to another technician" is honest. A generic login screen for a user who is already signed in tells them nothing and invites a password reset that will not help.
Test on iOS and Android with warm app, cold start, logged-out, logged-in, and expired-token cases. Test the web equivalent when email chooses the browser, including the path where a webview checkout hands back into the app. Fix the cases where logged-in users bounce to login before you ship another campaign that depends on the link.
Mobile work for mobile applications earns its keep in these handoffs—the screens between marketing and the record.
Measure it, then give it an owner
Track deep-link success as landed-on-intended-object, not merely app-opened. Segment by logged-in at tap versus forced login. Watch support tickets that say the link sent me to sign in. Those tickets are defects with a marketing budget attached.
Make sure the link carries both the object ID and the campaign parameters through the handoff, so growth can attribute the visit without anyone being tempted to route everything through the home screen. If attribution only works when users land on home, the tracking is designed backwards.
Deep-link bugs fall between teams. Marketing owns the email, growth owns the attribution, security owns the auth policy, and each feature team owns its own screen. The login dump survives because every one of them can point at another. Give the link router one owner, the same way you would give checkout or sign-in one owner, and route every new link type through a short review: what object it opens, what assurance level it needs, and what happens when the session is missing or the object is gone.
That review takes ten minutes per link type and saves a campaign's worth of support tickets. Put the landed-on-object rate on the same dashboard as email open and click rates, so the team celebrating a strong click-through can also see how many of those clicks ended at a password screen.
Put this into practice
Pick your top five email or push destinations. Run the logged-in cold-start test on current production builds. File every login dump as a P1 for those destinations, with one engineer owning the link router rather than each feature team patching its own screen. Publish a short link-target risk table so security and growth stop arguing from different defaults.
We build mobile products where return paths respect the session you already earned. If your links keep forgetting logged-in customers—talk to us.
Related work: Workstep.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.