Skip to content

Deep Linking — Getting Users Where They Actually Want to Go

Start here. This is the main entry point for all deep-linking documentation. The per-method detail pages in explanation/deep-linking/ assume you have read this page first.

Intended Audience

This page is written for everyone on the team — no engineering background required. If you have ever wondered why clicking a library link sometimes drops you on the homepage instead of the article you wanted, this is for you.

Engineers looking for implementation details should continue to the method-specific pages linked in Deep Dive by Authentication Method. Product managers, support staff, and anyone evaluating whether deep linking is supported for a given integration will find the overview table and TL;DR sufficient.

TL;DR

  • Deep linking means a user who clicks a link to a specific Statista page ends up on that page after logging in — not on the homepage.
  • The core challenge is that authentication systems redirect users away and back; the original destination can get lost in that round-trip.
  • The solution is always the same three steps: store the destination → authenticate → deliver to destination.
  • Support varies by auth method: OpenAthens Keystone, EZproxy (OverDrive mode), and Shibboleth are fully covered; enterprise connections work if the initiating link is built correctly.

What Is Deep Linking?

Imagine a researcher at Enormous State University. They are browsing their library's discovery portal, they find a paper — Müller et al., 2023, exactly what they need, and click the link. Their browser disappears into a flurry of login screens for a few seconds — and then deposits them on the Statista homepage. The report is nowhere in sight.

This is the problem deep linking solves. According to the OpenAthens glossary, a deep link is: "a link that can send the user straight to the signed-in version of a page." The key word is straight — not to the homepage, not to a generic landing screen, but directly to the resource the user actually clicked.

The challenge is that authentication systems are good at verifying identity. They are considerably less good at remembering why the user showed up in the first place. Deep linking is the set of techniques that bridge that gap: store the intended destination before authentication starts, survive the login round-trip, then land the user exactly where they wanted to be.

Which Authentication Methods Support Deep Linking?

Not all of our authentication integrations handle deep linking the same way. Here is a quick overview:

Authentication Method Deep Linking Support Notes
OpenAthens Keystone (OIDC) ✅ Fully supported Implemented in oa-deeplink.ts. Target is stored in a cookie before auth and consumed after.
EZproxy (OverDrive mode) ✅ Fully supported Implemented in BANGAuthenticate.dll. The URL parameter is transformed to a path-relative value and forwarded as __sso_redirect on the Auth0 redirect URL.
Shibboleth (SAML) ✅ Supported by protocol SAML RelayState carries the target URL through the round-trip. The Shibboleth SP on our server handles this natively.
Enterprise connections (Auth0 self-service SAML / OIDC) ✅ Supported by protocol Auth0's state parameter survives the OIDC round-trip. Requires the initiating link to carry the target.

How Deep Linking Works (The Simple Version)

Every deep-link implementation, regardless of authentication method, follows the same three-step pattern:

1. Store the destination
   Before redirecting the user to the login page, record the URL they
   originally wanted to visit — in a cookie, a session, or the auth request itself.

2. Authenticate
   The user logs in normally. The destination is kept safe on the side.

3. Deliver
   Once authentication succeeds, read the stored destination and redirect
   the user there instead of the default landing page.

The details differ by authentication method — where the destination is stored, what survives the protocol round-trip, and who is responsible for the final redirect. The pages below explain each method in depth.

Deep Dive by Authentication Method

Common Best Practices

These apply regardless of authentication method:

  • Always validate the target URL. An unvalidated redirect destination is an open redirect vulnerability. Only accept URLs that belong to a domain you control, and strip them to a path-relative form before storing.
  • Give the cookie (or session entry) a short TTL. Authentication round-trips complete in seconds. Five minutes is more than enough.
  • Fall back gracefully. If no target URL is present, redirect to the homepage rather than failing the whole authentication.
  • Use federation entityIDs in links, not internal subscriber IDs. EntityIDs are the common currency understood by discovery systems, link resolvers, and redirectors across the academic ecosystem. Internal IDs are opaque outside your system.

See Also

Protocol background

Understanding the underlying protocols helps make sense of why deep linking is solved differently for each auth method.

Last updated: March 24, 2026 at 10:39
By: Axel Tetzlaff