Table of Contents
At Descope, we aim to meet developers where they are. That means offering a spectrum of integration options, so whether you want a fully hosted login page or complete control over every pixel and HTTP request, you’re covered.
But not every team, project, or product requires the same level of abstraction. That’s why Descope offers four primary ways to integrate authentication into your app:
Descope Flows are quick, complete, and easy to customize. The fastest way to launch secure auth with a visual editor and zero frontend code.
Bring Your Own Screen (BYOS) lets you use the power of Flows but present the UI your way. Keep the backend logic of Flows, but render everything using your own components.
Client SDKs hand you the instructions and components you need to build from scratch. Create the experience and orchestration yourself.
Backend SDKs/APIs allow you to tweak every detail, handling each step manually. Maximum flexibility, but also the most work.
These integration methods span from fast, no-code setup to full control over each screen and authentication function, so you can choose the right balance of development effort and customization.
In this blog, we’ll break down each approach, highlight pros and cons, share real-world usage examples, and help you choose the path that fits your team best.
Descope Flows
If your goal is to get your auth working fast and securely, Descope Flows are for you. You build authentication journeys in our visual editor, then embed them into your app via a web component or redirect users to our hosted page—no frontend code required.
It’s like using a ready-to-cook meal kit: the ingredients are prepped, the steps are laid out, and the result is impressive without requiring you to sweat over every detail.
With Descope Flows, you can customize each screen in your flow directly from the console, without writing a single line of code. Instead, you can drag, drop, and tweak your UI to pixel-perfect proportions.
Below are two real-world login screens. One’s minimal and modern, and the other has more calls to action and a denser layout. Both were built with Descope Flows, and fit natively into their respective applications.
Why developers choose Flows
Descope Flows offer the fastest, simplest, and most value-oriented approach. Many teams ship enterprise-grade experiences with flows on day one, and are able to iterate from there without ever redeploying code. Teams often start with a basic sign-up/login journey, then refine and expand it over time without writing new code. Product managers and designers can update screens, adjust logic, or test variants without looping in engineering for every tweak.
Because flows are dynamic and contextual, you can create flows that adapt based on risk score, device type, tenant, auth method, and more, without having to worry about orchestrating complicated UI for each option.
When to use
You need to support a variety of login methods (SSO, passwordless, passkeys, etc.) with minimal setup.
You want to build dynamic authentication that adapts based on context.
You want hands-on collaboration with PMs and designers in crafting and optimizing the user login experience.
You want a low-friction way to add auth to web or mobile apps.
Bring Your Own Screen (BYOS)
Descope Flows are designed to help you build fast, but we know many organizations have their own methods for achieving their specific branding or visual themes. That’s where Bring Your Own Screen (BYOS) comes in.
With BYOS, you keep the backend power of Descope Flows, like step orchestration, risk-based branching, and tenant-specific logic, but render every screen yourself. You build the UI in your own frontend, listen to events in the embedded Descope Flow Component, and plug in your components where ours would normally appear.
Why developers choose BYOS
BYOS isn’t the default choice, but it’s an important one. If your product has strict branding, accessibility, or regulatory requirements that outpace even a customizable visual editor, BYOS lets you meet those needs while still relying on Descope’s flow engine.
You’re opting into a bit more effort for the sake of full control over presentation: essentially designing the visual experience yourself while Descope handles everything behind the scenes.
What you’ll own
Frontend development for every screen: You’re writing and maintaining the UI, inputs, and outputs for every screen.
Keeping logic and UI in sync: Updates to your Flow logic must be reflected in your code, which means more coordination.
Your own hosting environment: Since you’re rendering the UI, you’re also the one hosting and deploying it.
When to use
Your app has strict compliance, accessibility, or branding rules that can’t be met via Flow styling.
You don’t expect the UI and screens in your flow to change often and have engineers dedicated to the frontend.
Client SDKs
Client SDKs are like being handed the building blocks and instructions so you can create from scratch. You choose the components and construct it yourself, but Descope still supplies the guidelines.
With Client SDKs, you build the UI and decide when to call auth methods like otp.signUpOrIn(), magicLink.update.email(), or webauthn.update() directly from the frontend. Descope handles session management under the hood.
Why developers choose Client SDKs
Developers reach for our Client SDKs when they want to call authentication methods inline with their existing logic, or they’re already collecting user input and just need a way to complete the authentication process. It’s also great for apps with highly dynamic frontends, where rendering decisions are deeply tied to user behavior or app state.
What you’ll own
UI and event handling: You’re building the full frontend experience, and deciding when to call each auth method or management function.
Flow coordination: There’s no Descope-managed Flow guiding users through each step—you determine the sequence.
Error and edge case handling: You’re on the hook for retries, invalid input, and error messaging.
When to use
You want to trigger specific authentication actions from within your app.
You’re already managing user input and want more flexibility over interaction patterns.
You want Descope to handle session management.
Backend SDKs/APIs
Descope’s Backend SDKs and REST APIs give you the most direct, programmatic access to the platform. This is the lowest level of integration: no Flows, no UI, and no session management. Instead, you write all the logic for how authentication works in your app, from start to finish.
This approach keeps Descope in the background as your Identity Provider, while you decide how and when to initiate authentication. You might use the backend SDK to send an OTP, validate a session token, create a user, or issue a magic link—all triggered from your own code and infrastructure.
It’s as flexible as it gets, but it’s also the most work.
Why developers choose Backend SDKs/APIs
Most developers don’t need this level of control: Flows or Client SDKs are more than enough for the majority of use cases. But when you’re working building for highly regulated environments, you might need to manage every step of authentication yourself in your backend. This approach is also the natural choice when auth isn’t triggered by a user in a browser, but is instead initiated by a server that doesn't require frontend input.
What you’ll own
Authentication orchestration: You’ll write code for the entire auth flow, from start to finish.
Session management: Validating, storing, and refreshing tokens is your responsibility.
When to use
You’re integrating auth into backend-heavy or server-initiated systems.
You need to control when and how tokens are created, validated, and revoked.
You’re migrating from a legacy auth system and need tight control over how Descope interacts with existing infrastructure.
Comparison Summary
Integration Option | Development Effort | UI Control | Best For |
|---|---|---|---|
Descope Flows | Low; abstracts complex coding into a drag-and-drop process. | Medium; you can style screens directly from the console UI. | Teams that want a quick, low-code solution. |
Bring Your Own Screen (BYOS) | Medium; abstracts workflows but requires some initial overhead to successfully scale. | Full; screens are fully built by your frontend team. | Teams with custom design needs but no desire to code auth logic. |
Client SDKs | Medium-high; invoke authentication functions directly from your frontend. | Full; screens are fully built by your frontend team. | Teams building custom UIs that want to directly call auth functions with built-in session management. |
Backend SDKs/APIs | High; you write all the authentication and session management logic. | Full; screens are fully built by your frontend team. | Teams that need full control over their auth from the backend. |
Making auth UX drag & drop simple
You shouldn’t have to wrestle with authentication to get your product into users’ hands. Whether you want a complete, hosted solution or fine-tuned control, Descope helps you start fast and scale with confidence.
Our recommendation? Start with Descope Flows. For most apps, they’re the perfect starter approach: quick, reliable, and easy to adjust as your requirements evolve. If you eventually want more control, you can always graduate to BYOS or our SDKs, bringing more of the effort in-house without tossing out all the convenience.
Auth UI doesn’t have to be a painful project your devs tackle at the eleventh hour. With Descope, you get the tools you need to serve up something secure, seamless, and speedy based on your unique needs and development resources.
Ready to see it in action? Sign up for Descope and set up your first login flow in minutes.
