Forem: Cara Jung

Pick Your Auth: An Interactive Guide

Cara Jung — Mon, 13 Apr 2026 16:00:00 +0000

Most auth tutorials focus on how authentication works such as how to drop in a component, spin up a dev server, and get a login screen running. There's no shortage of guides that tell you which method to use for your use case. What's missing is the hands-on part: actually experiencing each flow the way your users do, so you can feel the friction, see the session it produces, and make an informed decision from the ground up.

Magic link or passkey? Social login or OTP? The answer changes depending on whether you're building a consumer app, a fintech product, a B2B SaaS, or an internal tool. The choice is a product decision that affects activation, security posture, compliance, and long-term maintainability.

To tackle this dilemma, I built an interactive demo called Auth Decision Kit that lets you try three Descope auth flows live: magic link, social login, and passkey. This demo focuses on how each approach fits different product contexts and the tradeoffs you need to consider.

Demo: auth-decision-kit.vercel.app
GitHub: github.com/carasjung/auth-decision-kit

Each method has five tabs:

01 Auth Flow
Authenticate for real using a live Descope integration. See the actual UX users experience.

02 Session Inspector
After authenticating, inspect every claim in your JWT payload. Each field is annotated with what it means, why it matters, and when you'd use it.

03 Decision Matrix
Green / yellow / red ratings across six product contexts: B2B, consumer app, developer tool, internal tool, fintech, SaaS, and mobile-first.

04 Failure Simulator
Trigger each failure mode and see the Descope error code and the correct handling code.

05 Code
Copy-ready implementation snippets for Next.js

The Session Inspector: JWT Breakdown

One of the most useful things I learned building this is how different the JWT payload looks depending on which auth method you used and why they matter for your backend logic.

After a magic link auth, your session contains authenticationMethod: "magiclink" and verifiedEmail: true. The email verification is implicit, clicking the link is proof of inbox access. This is a meaningful signal for risk scoring and it also shows that magic link is a single factor (access to your inbox). For products that require two factors like healthcare and fintech, magic link on its own won’t satisfy.

After social login, you get the provider's access token nested under oauth.google.accessToken (or whichever provider). You also get externalIds.google, a stable provider-specific user ID that won't change even if the user changes their email address on Google's side. That's the field you want for account linking. Since you get free profile data, this is effective for consumer and developer tools.

After a passkey auth, the amr (Authentication Methods References) claim contains "hwk" (hardware key) and "user". This is the claim compliance teams care about. It's proof that a hardware-bound credential was used, not just a password or a link. Passkey is also the only method here where the private key never leaves the user’s device. Even a full Descope breach couldn’t expose user credentials.

The Decision Matrix

Here's a condensed version of what I found after thinking through six product contexts for each method:

Magic link is the sweet spot for B2B SaaS and early-stage products. Zero password management, implicit email verification, and simple implementation. However, it falls apart on mobile (context switch to email app kills conversion) and in high-security contexts where email as a sole factor isn't enough.

Social login is the fastest path to activation for consumer and developer tools. GitHub login in particular gives you free org and repo data via the OAuth token, which is useful for developer-focused products. Avoid it for fintech and banking where regulations often require you to own the identity directly.

Passkey is genuinely the best option for mobile-first and high-security context. Phishing-proof by design, the private key never leaves the device. The catch: users still need education on what a passkey is and you need a fallback for older browsers and lost devices.

Most products should offer at least two methods where one can be the default while the other an alternative. For instance, using magic link as the default and passkey as the upgrade path once users are comfortable.

The Failure Simulator

Auth flows break in predictable ways. Understanding those failure points from day one lets you design a seamless recovery experience so users can continue without friction and avoid escalating to support.

The failure simulator surfaces these scenarios using real Descope error codes and responses. While it doesn’t make live network calls, it replays actual API error outputs so you can explore failure cases without having to intentionally break a real session.

Magic links expire (Descope's default is 2 minutes). When they do, the onError callback fires with error code E011303. Your UI should catch this and offer to send a new link, not show a generic error message.

Social login gets cancelled. Users click "Continue with Google," see the permissions screen, and hit Cancel. That fires E062503. The right response is to return the user silently to the login screen and treat a cancellation as a choice, not an error.

Passkeys on new devices fire E083002 (WebAuthn NotAllowedError). The recovery flow is: fall back to magic link or OTP to verify identity, then offer to enroll a passkey on the new device. This is also why you should never make passkey the only auth method since you always need a fallback for device loss.

Stack and Setup

Next.js 15 with App Router
Descope Next.js SDK (@descope/nextjs-sdk) for auth flows and session management
Framer Motion for tab transitions
Tailwind CSS for layout

The entire setup is about 800 lines of TypeScript across nine files. All core data (steps, session highlights, decision matrix scores, failure scenarios, and code snippets) lives in a single lib/auth.ts file. Adding a new auth method requires only a single entry point, keeping the system easy to extend.

To run it yourself:

git clone https://github.com/carasjung/auth-decision-kit
cd auth-decision-kit
npm install
cp .env.local.example .env.local
# add your NEXT_PUBLIC_DESCOPE_PROJECT_ID
npm run dev

You'll need a free Descope account. Once you’ve created your account, grab your Project ID from app.descope.com/settings/project and configure a sign-up-or-in flow with whichever methods you want to test.

From Demo to Decision

There are plenty of great auth demos that show how things work. This one focuses on how to choose between them.

Auth is infrastructure and like many infrastructure decisions, the cost of getting it wrong rarely shows up immediately. It appears later through conversion drop-offs, security tradeoffs, compliance constraints, and migrations.

While modern tools make it easier to support multiple methods and evolve your approach over time, the decision of what to use and when still requires good judgement upfront. This project is designed to help make that choice more intentional.

The live demo is at auth-decision-kit.vercel.app and the full source is on GitHub.

What Predicts a Hit? I Trained 3 ML Models to Find Out

Cara Jung — Mon, 06 Apr 2026 07:00:00 +0000

In many entertainment adaptation decisions, content selections are still instinct-driven. Maybe a producer was vibing with a story or overheard their Gen Alpha nephew mentioning a GOAT title. This subjective approach has often led to expensive missteps and wasted resources for studios when the feature or show turns into a flop.

As someone who has worked in the breeding ground of popular webcomics, I asked: what if there was a system that could measure “success potential” of IPs based on real user behavior? Using ML, I wanted to see if I could build a forecasting model that could rank unadapted titles by their predicted commercial success.

The Data

For my endeavor, I worked with three datasets:

Source material metadata of roughly 1,500 titles that included engagement metrics such as views, likes, subscribers, genre, release schedule, and creator usernames
Produced show metadata of 1,977 titles including ratings, watcher counts, genre, episode count, and cast
Historical webcomic adaptation records of 424 cross-referenced titles that went from source material to screen, with data pulled from both sides

Before any modeling, I ran exploratory data analysis on all three and found a few things:

Engagement metrics (likes, views, subscribers) were strongly correlated with each other and overall popularity
Genre and tags correlated with watcher counts in the produced show data
Creator frequency showed no statistically significant impact on adaptation success, which directly contradicted what studios commonly assume

Engineering the Target Variable

One hurdle I ran into was that I couldn't directly measure adaptation “success" from the source material side alone. So I engineered a composite Popularity Score by normalizing and combining views, likes, and subscribers into a single metric representing audience appeal, which became the target variable for prediction.

For the produced show data, I created a parallel score using rating and watcher count.

Since correlation analysis confirmed that source popularity and show popularity moved together in historical adaptations, I used source popularity as a proxy target.

Simple vs Complex Models

I implemented three models: Random Forest, XGBoost, and Ridge Regression. If you worked with ML models, there’s an expectation that the more complex models will win. However, this wasn’t the case. Ridge Regression became the unexpected underdog model that won:

I cross-validated all three models to reduce overfitting and validate stability.

Likes = Success

Using standardized coefficients for feature importance in the Ridge model, the ranking was as follows:

Likes (strongest predictor by a significant margin)
Views
Subscribers

The factors that studios often focus on such as creator reputation, genre, rating, and engagement rate showed weak or no statistical significance.

I validated this further using Mann-Whitney U tests comparing adapted titles against the general pool. Adapted titles showed significantly higher “likes” than non-adapted ones and the difference was meaningful.

Feature Importance for Ridge regression(standardized coefficients)

So why “likes”?

One interpretation is that likes are intentional. A view can be passive while a subscription can be habitual. But giving a “like” is an act of emotional investment and this behavior is exactly what translates from IP to screen.

The Output

The final model produced a ranked list of the top 10 unadapted webcomic titles by predicted success, along with contextual signals for each including genre appeal, subscriber trends, engagement consistency, and creator track record.

Qualitative review of the top 10 confirmed alignment with the engagement patterns seen in historically successful adaptations. Cliff's Delta calculations showed that the predicted top titles had significantly higher likes than past adaptations.

Limitations on the Model

Part of doing good data work is being honest about the limitations. There were a few things that fell short:

Small adaptation dataset. 424 entries is workable, but more data would reduce overfitting risk and better generalization.
Proxy target variable. Using source popularity instead of actual show performance is a justified simplification, but it means the model can't fully capture real-world production quality, casting, or distribution reach.
Categorical features dropped. Creator and genre have too many levels and their coefficients dominated the model without adding significance. Excluding them improved interpretability but at the cost of losing some nuance.

What I'd Do Next

If I extended this project, I'd rethink how signal is captured and focus on the following:

Use NLP for deeper context
- Synopsis embeddings or sentiment analysis on reader reviews could capture thematic richness that raw engagement metrics miss.
Take a hybrid ranking approach
- Combining regression with a learning-to-rank algorithm could improve recommendation quality at the top of the list, where small differences actually matter.
Longitudinal validation
- The real test is tracking what happens when predicted titles actually get produced. Building a feedback loop into the model would sharpen it over time.

Final Thoughts

The core insight here doesn’t only strictly apply to entertainment. It can apply to decisions that are being made by intuition or legacy practice. As the models showed, behavioral signals from real users outperform assumptions about what will succeed.

Likes beat creator prestige. Engagement beat genre conventions. The audience’s preferences, not the ones from industry decision makers, predicted outcomes more reliably.

Whether you're choosing which content to produce, which features to build, or which markets to enter, the same principle applies. The answers are within the data, but we often overlook the right signals.