Descope SDKs

Integration Approaches

There are three common ways to integrate the Descope service into your application. Below is a comparison of the different integration approaches and when to use them.

App Client to Descope with FlowsApp Client to Descope (Client SDK, No Flows)App Server to Descope (Backend SDK)
DetailsCreate authentication flows and screens using Descope’s drag-and-drop visual editor. We strongly recommend using this approach to integrate Descope into your application.Integrate your application client to individual authentication methods supported by Descope.Integrate your application server with the Descope service.
Signup/Login ScreensDescope visual screen editorBuild on your ownBuild on your own
Authentication flowDescope visual workflowBuild on your ownBuild on your own
Session ManagementHandled by Descope Client SDKHandled by Descope Client SDKBuild on your own
Device Fingerprinting & User RiskDescope risk-based workflowsNot availableNot available
When to use?Choose this approach to go live with Descope in the fastest and easiest manner. Design authentication flows and screens directly in the Descope console. Deploy your app with a few lines of code.Choose this approach if you want to build authentication flows and screens on your own, but want to use the Descope SDK for session management. Descope Flows will not work with this approach.Choose this approach if you want to handle all frontend flows and logic – including session management – on your own. Descope Flows will not work with this approach.
Descope Flows
Client Guides
Backend Guides

SDK Overview

Descope offers both client and backend SDKs for many languages and frameworks. There are three ways to integrate the Descope service with your application. Based on your chosen approach, you will use only backend SDK or both client and backend SDK. The quick start guide covers the most common and recommended integration approach. The SDK guides cover the other approaches. Below is a quick summary of all the supported SDKs.

Descope Client SDKs

If you decide to integrate using either App Client to Descope with Flows or App Client to Descope (Client SDK, No Flows), then Descope Client SDK is used. If you decide to use App Client to Descope with Flows App, the Descope Client SDK is used to trigger different authentication flows. This is documented in the Quick Start Guide. If you decide to use App Client to Descope (Client SDK, No Flows) for integrating with Descope, Descope Client SDK can be used to integrate with any of the authentication methods supported.

SDKGithub Link
Web-JS SDKhttps://github.com/descope/descope-js/tree/main/packages/web-js-sdk
React SDKhttps://github.com/descope/react-sdk
Vue SDKhttps://github.com/descope/vue-sdk
Web Component SDKhttps://github.com/descope/descope-js/tree/main/packages/web-component
Swift SDKhttps://github.com/descope/swift-sdk
Flutter SDKhttps://github.com/descope/flutter-sdk
React Native SDKhttps://github.com/descope/descope-react-native
Kotlin SDKhttps://github.com/descope/descope-kotlin

Descope Backend SDKs

Descope Backend SDKs are most commonly used for JWT validation after the user authenticates with Descope. If you are using Descope Client SDK for integration App Client to Descope with Flows or App Client to Descope (Client SDK, No Flows), then the only purpose of using the Backend SDK is for JWT validation as shown in the Quick Start Guide.

In case you chose App Server to Descope (Backend SDK) then the backend SDK will be your main point of integration for all authentication calls for different authentication methods. The SDK documentation for each SDK will demonstrate how to implement authentication methods like magic link, OTP etc using approach 3.

SDKGithub Link
Python SDKhttps://github.com/descope/python-sdk
Go SDKhttpss://github.com/descope/go-sdk
Node SDKhttps://github.com/descope/node-sdk
PHP SDKhttps://github.com/descope/descope-php
Java SDKhttps://github.com/descope/descope-java