DEV Community: Mrunank Pawar

Add Authentication and MFA to Unreal Engine with Descope

Mrunank Pawar — Wed, 08 Apr 2026 16:55:57 +0000

This blog was originally published on Descope

Unreal Engine (UE) is widely known for its ability to create high-fidelity, immersive gaming experiences. Some of the most popular games today have been created with this more-than-capable engine, including games like Fortnite and Rocket League. Its visual scripting, robust C++ foundation, and cross-platform support make it a top choice for game development, from indie developers to AAA studios.

But building a great game isn't just about graphics or gameplay. When you start adding features like multiplayer, player profiles, cross-device syncing, and monetization, secure, seamless authentication becomes nonnegotiable. Making sure that only verified users can access key features or data is essential for both user safety and developer control. Descope is a flexible identity platform that allows developers to embed authentication and multifactor authentication (MFA) flows into their apps with minimal friction. With support for magic links, OTPs, and social logins, Descope makes it easier to build secure login flows that will feel like a natural part of your game.

In this tutorial, you'll learn how to add authentication and MFA to a UE game using Descope. Along the way, we'll cover the different approaches game developers typically consider when implementing authentication, walk through a real-world integration using Descope's OpenID Connect (OIDC) support, and demonstrate how to display user details and handle logouts in game.

Approaches to game authentication

Game developers generally have three options when it comes to implementing authentication. The first is to rely on a storefront's built-in identity system, such as Epic Games or Steam. These systems offer smooth onboarding within their ecosystems and can integrate well with features like matchmaking, achievements, and leaderboards. However, they also come with some trade-offs: limited customization, dependency on a single platform, and constraints around marketing access or monetization outside the store.

The second option is to purchase an authentication plugin from Fab, Epic Games' new unified marketplace for digital assets. While this can help to kickstart development, the quality and reliability of these plugins can vary. Many still require manual setup and ongoing maintenance or lack support for features like MFA. For teams working on production-grade titles, these limitations often become apparent late in development, right when integration changes are most costly.

Finally, you could opt to build your own authentication system from the ground up. This offers the most control but comes at a high cost in terms of engineering time, ongoing security maintenance, and compliance.

However, a custom authentication system does bring some advantages that the other options might not be able to offer:

Maintain consistent player identity across storefronts and devices
Implement subscriptions or microtransactions outside of the game platform
Get better user analytics and tracking
Reduce reliance on third-party platforms
Strengthen overall security with flexible MFA options

Descope helps you to bridge this gap by offering a secure, developer-first approach to authentication and MFA. This approach works across platforms, can be integrated into your game's UX, and doesn't require you to become an authentication expert.

In the following sections, you'll learn how to implement a secure, user-friendly authentication flow in Unreal Engine using Descope: from setting up your Descope project to integrating it with your UE game, configuring authentication flows, and adding multifactor authentication. By the end, you'll have a working login system with MFA, profile fetching, and logout functionality ready to plug into your own game.

Prerequisites

Before you get started, you're going to need a few tools and services downloaded, installed, and ready to go:

Unreal Engine v5.6+ (installed via the Epic Games Store launcher). Instructions for installing the full UE can be found here. The tutorial might work on an older version, but your mileage may vary.
Visual Studio or Visual Studio Community Edition, depending on your licensing needs.
A Descope account.

Visual Studio: specific modifications for Unreal Engine

Visual Studio's installer allows you to set up the IDE for different workloads or project types. If you've previously only used VS for Python projects, you'll have it set up in a particular way that won't work with UE, which requires a few specific components for it to fully work.

Launch the VS installer and click Modify to modify your installation of Visual Studio:

Under the Workloads tab, in the Desktop & Mobile section, you need to make sure that these three components are selected:

.NET desktop development
Desktop development with C++
WinUI application development

Still under Workloads, in the Gaming section, make sure that Game development with C++ is selected:

Once you've downloaded and installed all of the components, your Visual Studio environment is ready to go.

Note: If, for whatever reason, things don't seem to be working, or the installed version of UE is starting up with errors, consult the help pages on Epic Games' website to troubleshoot these errors.

Setting up Descope

Once you've set up your Descope account, you can start designing your authentication workflow.

First, log in to your Descope console via this link.

Navigate to Flows and then select Start from template.

The flow template library allows you to filter by use cases and methods. Select Enchanted Link and Social (OAuth/OIDC) for your methods, and MFA for your use case. Select the Sign up or in version of the templates that matched your selected filters.

You can rename your flow and give it a unique ID if you want. Once you're happy, click Create.

Once your new flow has been created, you can customize the flow to behave the way you want it. In this tutorial, we'll remove the social login buttons for Google and Apple, and add a Discord button instead.

Hover over the Welcome Screen element on the flow and select Edit.

Delete the Google and Apple social buttons, and drag in a Discord button from the sidebar.

Remember to save your flow once you're happy with the changes you've made.

Your custom authentication flow has now been set up and is ready to be used in your Unreal Engine project.

Creating your Unreal Engine game

With the prerequisites in place, the first step is to set up the new Unreal Engine project that you will add authentication to. Start off by opening Unreal Engine either from the Epic Games Launcher or from the installed location.

Then, create a blank game project and give it a name. This tutorial will use UNREAL_AUTH_DEMO as the project name. Make sure to select C++ as your project type.

If everything went well, you'll see an empty game world showing up in the editor:

If it didn't go well and your editor refused to start, now would be the time to consult the Setting Up Visual Studio page to see if you're missing any components that need to be installed first.

Otherwise, you're ready to create your menu component that will allow your users to sign up or in.

Create your main menu

In the UE editor, at the bottom, expand your Content Drawer. Create a UI folder under Content to keep things organized.

Add a User Interface widget blueprint:

Click User Widget as the parent class when prompted:

Name your widget something practical like LoginMenu:

Once you're in the designer, you're going to need the following on your menu blueprint:

Two buttons, one named SigninButton and another named SignoutButton.
Both buttons need to have the Is Variable option enabled.
A textbox named TextResult, also with Is Variable enabled.

Once your menu has been created, you should have a hierarchy that looks similar to this:

And while your menu might look slightly different, it should look similar to this:

This menu is now ready to be displayed in your UE level.

Display your menu

Now that you have a login menu, you'll want it to appear when your game starts.

In the UE editor:

Create a new empty level (for example, you can name it MainMenuLevel).
Open the level blueprint.
On Begin Play, add a Create Widget node, select your LoginMenu widget, then connect it to an Add to Viewport node.

Save your level blueprint, exit the blueprint editor, and click Play from the level editor to see your new menu inside the level:

Create your custom login widget class

Next, you'll add some simple C++ logic to connect to the menu.

Create a new C++ class (UserWidget parent) and name it LoginUIWidget.

Wire up basic button click events to confirm your UI is responding.

Update LoginUIWidget.h to declare the buttons, text block, and click handlers:

#pragma once

#include "CoreMinimal.h"
#include "Blueprint/UserWidget.h"
#include "LoginUIWidget.generated.h"

UCLASS()
class UNREAL_AUTH_DEMO_API ULoginUIWidget : public UUserWidget
{
    GENERATED_BODY()

public:
    virtual void NativeConstruct() override;

    UFUNCTION()
    void OnSigninClicked();

    UFUNCTION()
    void OnSignoutClicked();

protected:
    UPROPERTY(meta = (BindWidget))
    class UButton* SigninButton;

    UPROPERTY(meta = (BindWidget))
    class UButton* SignoutButton;

    UPROPERTY(meta = (BindWidget))
    class UTextBlock* TextResult;
};

Note the following:

Replace UNREAL_AUTH_DEMO_API with your actual project name and API.
Ensure the UButton and UTextBlock names match your blueprint widget variables.

Then update LoginUIWidget.cpp to register the button click handlers:

#include "LoginUIWidget.h"
#include "Components/Button.h"
#include "Components/TextBlock.h"

void ULoginUIWidget::NativeConstruct()
{
    Super::NativeConstruct();

    if (SigninButton) SigninButton->OnClicked.AddDynamic(this, &ULoginUIWidget::OnSigninClicked);
    if (SignoutButton) SignoutButton->OnClicked.AddDynamic(this, &ULoginUIWidget::OnSignoutClicked);
}

void ULoginUIWidget::OnSigninClicked()
{
    UE_LOG(LogTemp, Log, TEXT("Sign in button pressed!"));
    // login logic here
}

void ULoginUIWidget::OnSignoutClicked()
{
    UE_LOG(LogTemp, Log, TEXT("Sign out button pressed!"));
    // logout logic here
}

This test code does two things:

Hooks up the Sign In and Sign Out buttons
Logs a message to the UE output log when either button is pressed

Save these two files. Now, you'll need to reparent your existing login menu blueprint to use this new class's logic.

Reparent your login menu blueprint

Open up the LoginMenu blueprint from the content drawer. Then, select File > Reparent Blueprint. You'll be able to search for LoginUIWidget (the new class you just created) and then select it. This will reparent your blueprint's logic to the custom from earlier.

Note: At this point, you might run into an annoying bug that some people have with UE5 and VS 2022. If you do not see the class listed when you search for it, you'll need to do the following steps:

Close the Unreal Engine editor.

In Visual Studio, select Build > Build unreal_auth_demo or the project name you chose.

Wait for the build process to finish, and open the Unreal editor again.

Sometimes, you can use the build process without having to close the editor, and there are ways to fix it, but that's beyond the scope of this tutorial. In any case, if you've followed the steps, you should be able to reparent the blueprint to your custom class.

Save your blueprint once you've finished the reparent process.

Change your default level and test the button

Back in the editor, go to Edit > Project Settings, and then click Maps & Modes on the left sidebar menu. Change your Editor Startup Map and your Game Default Map to point to the MainMenuLevel you created.

Now, you can test your custom button code logic. Play the game using the same green play button from before, and click the Sign in button.

In your editor, you'll see a drawer called Output Log. Expand this drawer, scroll to the bottom, and see if your custom output message is there.

If you see the messages, that means your code is working.

Get some information from Descope

Before you can connect Unreal Engine to Descope, you need to gather some details about how the game will communicate with Descope during the login process. These details come from OAuth 2.0 and OpenID Connect (OIDC), which are the standards we'll use to handle authentication with Descope.

OAuth and OIDC

OAuth 2.0 is a protocol that lets an app (in this case, your game) request authorization for a user through a trusted provider like Descope. Instead of handling passwords directly, your game gets a temporary authorization code that can be exchanged for tokens.

OpenID Connect (OIDC) builds on OAuth 2.0 and adds identity information. That's how your game can get details like the player's username, email, or profile data.

In practice, this means your Unreal Engine project will:

Redirect the player to Descope's login page.
Descope will authenticate the user (e.g., via Discord login + MFA).
Descope will send your game back an authorization code.
Your game exchanges that code for tokens that prove the user is authenticated.

To make this work, your game needs some values from Descope's OIDC configuration.

Getting the OIDC Settings

In your Descope console:

Navigate to Federated Apps.
Click OIDC Default Application. (On the free tier, this is the only one available for editing.)
Scroll down to the SP Configuration section and note the following values:
- Client ID: identifies your Unreal Engine app to Descope.
- Authorization URL: the endpoint your game uses to start the login flow.
- Token URL: the endpoint your game calls to exchange the authorization code for tokens.
- Logout URL: the endpoint that clears the user's session when they sign out.

These values form the backbone of the login flow. In the next step, you'll wire them into the Unreal Engine code so the game can start and complete the OAuth process.

While you're on this screen, update the Flow Hosting URL to point to the custom flow you created earlier:

Modify your custom class

Next, let's update LoginUIWidget.h to declare the functions, variables, and UI bindings that power the authentication flow:

#pragma once

#include "CoreMinimal.h"
#include "Blueprint/UserWidget.h"
#include "LoginUIWidget.generated.h"

/**
 *
 */
UCLASS()
class UNREAL_AUTH_DEMO_API ULoginUIWidget : public UUserWidget
{
    GENERATED_BODY()

public:
    virtual void NativeConstruct() override;

    UFUNCTION()
    void OnSigninClicked();

    UFUNCTION()
    void OnSignoutClicked();

    UFUNCTION()
    void SetLoginState(bool bNewLoginState);

    UFUNCTION()
    void UpdateUI();

protected:
    UPROPERTY(meta = (BindWidget))
    class UButton* SigninButton;

    UPROPERTY(meta = (BindWidget))
    class UButton* SignoutButton;

    UPROPERTY(meta = (BindWidget))
    class UTextBlock* TextResult;

    // Login state
    UPROPERTY(BlueprintReadOnly, Category = "Login")
    bool bIsLoggedIn = false;

    // Descope OIDC Parameters
    FString ClientId;
    FString RedirectUri;
    FString RedirectLogoutUri;

    // Descope endpoint URLs
    FString AuthUrl;
    FString TokenUrl;
    FString LogoutUrl;
    FString UserInfoUrl;

    FString CapturedAuthCode;

    // PKCE values
    FString CodeVerifier;
    FString CodeChallenge;
    FString State;

    // Tokens
    FString IdToken;
    FString AccessToken;
    FString RefreshToken;

    void GeneratePKCEParameters();
    void StartOAuthLogin();
    void ListenForAuthCodeInBackground();
    void PerformSignout();
    void RevokeTokens();
    void ClearSessionData();

    // Fetching user data variables and functions
    FString UserEmail;
    FString UserName;

    UFUNCTION()
    void FetchUserProfile(const FString& Token);

    UFUNCTION()
    void ExchangeAuthCodeForTokens(const FString& Code);
};

At a high level, this header sets up:

UI hooks: SigninButton, SignoutButton, TextResult
Authentication state: bIsLoggedIn, tokens, and PKCE parameters
Core functions: StartOAuthLogin, ExchangeAuthCodeForTokens, FetchUserProfile, and PerformSignout
Networking: a socket listener (ListenForAuthCodeInBackground) to receive the redirect from Descope

With the header file in place, you can now implement the functionality in LoginUIWidget.cpp. This is where the actual behavior for our authentication flow lives—handling button clicks, generating PKCE parameters, launching the OAuth login, listening for the redirect from Descope, exchanging the authorization code for tokens, and finally fetching the user's profile information to display in the game.

The next code snippet is large, so it's recommended to copy the code directly from the Github repo, here. Just remember to update the following variables with the values you retrieved from Descope earlier:

ClientId
RedirectUri
RedirectLogoutUri
AuthUrl
TokenUrl
LogoutUrl
UserInfoUrl

Here are the most important parts of the .cpp:

PKCE support (GeneratePKCEParameters) for secure OAuth logins
Browser-based login (StartOAuthLogin) using the system browser
Local redirect listener (ListenForAuthCodeInBackground) to capture the authorization code and exchange it for tokens
Profile fetching (FetchUserProfile) to display the user's email and username
Thread safety and timeouts—runs the socket in a background thread, logs any errors to the UE output log

Finally, because this project uses new features like network sockets and HTTP calls, you'll need to enable the corresponding Unreal Engine modules in your project's build configuration. Open your project's build file (ProjectName.Build.cs) and add the required dependencies, as shown below:

using UnrealBuildTool;

public class unreal_auth_demo : ModuleRules
{
    public unreal_auth_demo(ReadOnlyTargetRules Target) : base(Target)
    {
        PCHUsage = PCHUsageMode.UseExplicitOrSharedPCHs;

        // PublicDependencyModuleNames.AddRange(new string[] { "Core", "CoreUObject", "Engine", "InputCore", "EnhancedInput" });
        PublicDependencyModuleNames.AddRange(new string[] { "Core", "CoreUObject", "Engine", "InputCore", "Networking", "HTTP", "Json", "JsonUtilities", "Sockets" });

        PrivateDependencyModuleNames.AddRange(new string[] { });

        // Uncomment if you are using Slate UI
        // PrivateDependencyModuleNames.AddRange(new string[] { "Slate", "SlateCore" });

        // Uncomment if you are using online features
        // PrivateDependencyModuleNames.Add("OnlineSubsystem");

        // To include OnlineSubsystemSteam, add it to the plugins section in your uproject file with the Enabled attribute set to true
    }
}

Build your code again using Build -> Build unreal_auth_demo. Once it's finished building, you can open up the Unreal editor again.

Testing it all

Once your editor is open, run the game using the green play button again.

Notice that your Sign Out button is not visible. This is because of the changes in the UpdateUI() method to show and hide the different buttons based on your logged-in state.

Click Sign In. A browser window will open with the following login UI:

This is the right authentication flow that you set up earlier on Descope's flow designer. Click Sign in with Discord.

The first time you sign in, Descope will ask for some extra information about you and verify your identity using MFA.

If you entered your number correctly, you should receive a verification code via SMS:

Once you've entered the code, your screen should look like this:

This process should only happen the first time you sign in with a new user. Click Submit to continue.

Discord will open up with the following dialog:

Click Authorize and you should see the following:

Descope will now call the configured callback URL (in your case, http://localhost:3000) to tell your server that the login was successful and to give you an authorization code:

In the background, your code will use the ExchangeAuthCodeForTokens and FetchUserProfile methods to fetch proper authentication tokens and to retrieve user information. Once that's complete, it will update the UI in your game:

Notice now that the Sign In button has been replaced with a Sign Out button.

Try giving that button a click:

You've now successfully integrated Descope as your auth provider for your Unreal Engine 5 game.

As mentioned before, all of the code used in this tutorial is available here.

Conclusion

Adding authentication and MFA to an Unreal Engine game doesn't necessarily mean writing your own identity system or locking yourself into a single storefront. With Descope, you can implement secure, flexible login flows, including social login and multifactor authentication, using modern standards like OIDC and PKCE.

In this tutorial, you built a working login system in Unreal Engine from the ground up. You integrated Descope with Discord for social login, captured the authorization code using a local socket, exchanged it for tokens, and fetched the authenticated user's profile to update your game's UI. You now have a foundation for cross-platform identity, security, and personalization inside your UE game.

Descope offers even more beyond what was covered here: drag-and-drop flow builders, passwordless authentication, risk-based access policies, and more. If you're building a connected game and want your auth system to scale with you, book a demo with Descope, or check out their documentation and explore how it can fit the identity strategy for your game or website.

The Developer’s Guide to JWT Storage

Mrunank Pawar — Mon, 06 Apr 2026 17:07:00 +0000

This blog was originally published on Descope

JSON Web Tokens (JWTs) are compact, self-contained tokens used to securely transmit information between parties while maintaining data integrity. Many authorization providers use JWTs to provide a tamper-proof way of identifying an authenticated user in an application and checking what they're authorized to do.

Unfortunately, securely storing JWTs is often overlooked, which can expose some serious vulnerabilities. For example, cross-site scripting (XSS) attacks can steal JWTs, letting malicious actors impersonate users and access sensitive data. Therefore, you need to store JWTs securely to protect users and potentially save your organization millions by preventing data breaches.

This guide will explore essential JWT security considerations, popular browser storage methods, and their benefits and drawbacks, best practices, and troubleshooting tips for working with JWTs. By the end, you'll be well-informed about the available JWT storage methods and choose the most appropriate solution for your use case.

Understanding JWT storage

JWTs are compact, self-contained tokens used to transmit user information in requests to a server. Given HTTP's stateless nature, once an application receives the token, it must be stored and used for subsequent API requests to the server.

The JWT lifecycle consists of three stages: creation, storage, and usage. First, an authorization server generates the JWT after the user is successfully authenticated. Second, the application stores the token, typically in the browser. Third, the application includes the token in the authorization header when making requests to the resource server, which verifies the token before processing the request.

Here's a diagram of the process:

Security is critical when storing JWT storage. Storing it improperly can lead to token theft, making it possible for attackers to impersonate users or elevate their privileges. Common attack vectors include the following:

Arbitrary signature attacks: Arbitrary signature attacks occur when servers fail to verify token signatures, allowing attackers to modify claims and escalate privileges or impersonate users. While this is primarily a server-side issue, secure JWT storage makes it harder for attackers to obtain a valid token to study and manipulate.
none algorithm attacks: The none algorithm attack happens when servers mistakenly accept unsigned JWTs due to the alg parameter being set to none. JWT storage is not entirely related to this attack. However, it's harder for attackers to put together a malicious token if they can't gain access to the valid one.
Algorithm confusion attacks: In algorithm confusion attacks, attackers exploit mismatches between the signing and verification algorithms, generating valid tokens with their own keys. If tokens are stored insecurely, attackers can more easily obtain them to study the algorithm used and attempt to craft tokens with manipulated algorithms and secrets.
Kid manipulation: Key ID (kid) manipulation exploits vulnerabilities in the kid parameter by injecting malicious commands into the token's key verification process. As with other attack vectors, kid manipulation is more straightforward if attackers obtain a valid JWT. However, the vulnerability needs to be fixed on the server side.
Brute force attacks: Brute force attacks target weak or simple symmetric encryption secrets, allowing attackers to generate malicious tokens by guessing the secret. Secure JWT storage is crucial in preventing brute-force attacks. If tokens are stored insecurely, attackers can easily obtain valid tokens to use as a reference when attempting to guess the secret.

To mitigate these risks, it's crucial that you implement proper server-side token verification, disable insecure algorithms, use strong encryption, and validate all parameters in the token. When storing tokens in a client-side application, you must do so securely to prevent unauthorized access to valid tokens, which attackers could study and manipulate.

Common JWT storage methods

Several options are available for storing tokens client-side in the browser. Each has its strengths and weaknesses, and you must assess your application requirements and decide which technique is best suited.

For example, session or in-memory storage might be ideal if user sessions are generally short and get logged out when they're done. However, you might consider cookies or local storage for longer-lived user sessions.

Local storage

Local storage provides a simple API for storing user data across sessions in the browser. Its simplicity and robustness across sessions make it a popular choice for storing JWTs in the browser. However, it's important to note that local storage is vulnerable to XSS attacks, where attackers can inject malicious scripts to access stored data, including JWTs. Make sure to implement appropriate safety measures to prevent this.

Run the following code to store a JWT in local storage after receiving it:

// Store JWT
localStorage.setItem('jwtToken', response.data.token);

// Use JWT in request
const token = localStorage.getItem('jwtToken');
const response = await fetch('https://example.com/api/data', {
    headers: {
        'Authorization': `Bearer ${token}`
    }
});

// Clear JWT (log out)
localStorage.removeItem('jwtToken');

Local storage has some pros and cons that you should carefully consider:

Pros:

Easy to implement
Accessible from JavaScript code
Accessible across browser tabs
Persistent between page refreshes
Generous storage limit (5MB)

Cons:

Vulnerable to XSS attacks
No automatic token expiration mechanism

Local storage is a popular choice for storing JWTs as it lets you persist tokens across pages and is easy to access from JavaScript. However, make sure you patch XSS vulnerabilities to prevent malicious actors from stealing tokens.

Cookies

Cookies offer additional security compared to other client-side storage options. They require server-side modifications to create secure cookies containing the token. When properly configured, cookies are less vulnerable to XSS attacks, but they can still be susceptible to cross-site request forgery (CSRF) attacks.

Use the HttpOnly flag to ensure client-side JavaScript cannot access the cookies. The Secure flag ensures the cookie is sent only over a secure channel that's not susceptible to man-in-the-middle attacks. Finally, the SameSite attribute can be used with other anti-CSRF strategies to help prevent CSRF attacks.

Here's a basic example of storing a JWT in a cookie using Express:

app.post('/login', (req, res) => {
    const token = generateJWT(user);

    // Insert the token into the `auth_jwt` cookie in the response
    res.cookie('auth_jwt', token, {
        httpOnly: true,
        secure: true,
        maxAge: 60 * 60 * 1000 // 1 hour
    });
});

Run the following code to make a request with the cookie in client-side JavaScript code:

const response = await fetch('/protected', {
    method: 'GET',
    // Set credentials to same-origin so cookies are included
    credentials: 'same-origin'
});

The following is to verify the token on the server using Express:

app.get('/protected', (req, res) => {
    const jwt = req.cookies.auth_jwt;
    if (!verifyToken(jwt)) {
        return res.status(401).json({ message: 'Token is invalid' });
    }

    // Continue processing the request here since the JWT is valid
});

Logging the user out involves simply clearing the cookie:

app.get('/logout', (req, res) => {
    res.clearCookie('auth_jwt');
    return res.status(200).json({ message: 'User logged out.' });
});

Consider the following pros and cons regarding cookie storage before using it for your JWTs:

Pros:

Enhanced security against XSS attacks (with HttpOnly flag)
Automatically included in requests
Built-in security features (Secure flag and SameSite attribute)
Server-side control over token storage lets the server revoke tokens if necessary before processing requests. This could happen if a user logs out of another system and a back-channel logout request is sent to the server.
Accessible across browser tabs
Persistent between page refreshes

Cons:

Vulnerable to CSRF attacks (mitigate with the SameSite attribute and anti-CSRF mechanisms)
Limited storage capacity (around 4KB)
Often requires additional server-side logic
Possibly tricky to work with when working across domains

Cookie storage is a great solution as it provides a good balance of security and functionality. However, remember to implement proper security measures, like using the HttpOnly, Secure, and SameSite flags, along with anti-CSRF mechanisms.

Session storage

Session storage is a JavaScript API in the browser that lets you persist data for a single page until it's closed. This means that the data stored is lost as soon as the page is closed. Also, if a user opens another page in a different tab or window, it will have its own session storage.

Session storage is slightly more secure than local storage, as session storage gets cleared when the page closes. However, session storage is still vulnerable to XSS attacks. Use the OWASP cheat sheet and a Content Security Policy to prevent these attacks. However, be aware that malicious browser extensions can still access session storage.

Here's how to use session storage for JWTs:

// Store JWT
sessionStorage.setItem('jwtToken', token);

// Retrieve JWT
const token = sessionStorage.getItem('jwtToken');

// Use JWT in request
const response = await fetch('https://example.com/api/data', {
  headers: { 'Authorization': `Bearer ${token}` }
});

// Remove JWT (logout)
sessionStorage.removeItem('jwtToken');

Before using session storage, consider the following pros and cons:

Pros:

Easy to implement
Accessible to client-side scripts
Automatic clearing of tokens when the page is closed
Generous storage limit (5MB)

Cons:

Vulnerable to XSS attacks
Lost token between page refreshes and tabs

Session storage offers a simple way to store JWTs and automatically clears them when the page is closed. Tokens are also accessible from client-side scripts. However, be sure to protect your app against XSS attacks to prevent stolen tokens.

In-memory storage

In-memory storage keeps the JWT in the web application's memory using a JavaScript variable or a web worker, rather than persisting it in browser storage. This approach is helpful in single-page applications (SPAs) where the page doesn't refresh often.

In-memory storage can be considered slightly more secure since the token is obscured from the attacker. Attackers can't use a standard browser API to retrieve it. However, with enough patience, an attacker could still figure out where the token is being stored and retrieve it through an XSS attack. Malicious actors can also try to access the in-memory JWT using a debugger. Similar to other storage techniques, having a well-defined Content Security Policy and implementing XSS preventive measures are vital.

The following snippet demonstrates how to store a JWT in memory using a JavaScript class with a private variable storing the JWT:

class TokenService {
    #token = null;

    setToken(newToken) {
        this.#token = newToken;
    }

    getToken() {
        return this.#token;
    }

    clearToken() {
        this.#token = null;
    }
}

const tokenService = new TokenService();

// Store JWT
tokenService.setToken(response.data.token);

// Use JWT in request
const response = await fetch('https://example.com/api/data', {
    headers: {
        // token is the global variable
        'Authorization': `Bearer ${tokenService.getToken()}`
    }
})

// Clear JWT (logout)
tokenService.clearToken();

In-memory might seem slightly more secure than some other methods, but it still has some cons, which might influence your decision to go with this approach:

Pros:

Harder to retrieve via XSS attacks
Accessible to client-side scripts
Automatic token clearing when navigating pages and tabs
No storage limitations

Cons:

Still vulnerable to sophisticated XSS attacks
Lost token between page refreshes and tabs

In-memory offers a balance between security and convenience. It's slightly harder to retrieve using XSS attacks, but you should still take preventive measures to prevent these attacks in the first place.

Best practices for JWT storage

Regardless of which storage method you use, there are some best practices you should follow to minimize authentication and authorization vulnerabilities in your application.

Encryption of stored tokens

Storing tokens unencrypted makes it possible for an attacker to decode the token and see what claims are associated with it. JSON Web Encryption (JWE) is a standardized method of encrypting JWTs. The encryption happens on the server before the token is sent to the client, and the encryption keys are kept on the server or in a dedicated key management service.

Since the client cannot access the encryption key, they cannot view any of the claims in the token.

Token expiration and rotation

JWT expiration times dictate when a token is no longer valid. Once a token expires, you must retrieve a new one using a refresh token. A refresh token is a token issued along with the original JWT that lets you request a new JWT when the current one expires. When issuing a new JWT using a refresh token, the authorization server first ensures the user's session is still active and then sends the new token if it is.

You can further enhance the security of your JWT and refresh token by rotating the refresh tokens. This means that every time you request a new JWT using a refresh token, a new refresh token is generated along with the new token and returned. The refresh token returned is the only valid token that can be used to get the next JWT. For a deeper look at this, check out The Developer's Guide to Refresh Token Rotation.

You should also set an expiration period for your refresh tokens, as this adds an extra layer of security. Even if the attackers can access the refresh token, they might not use it in time.

Handling of token revocation

If a server uses only the JWT expiry time claim to determine whether a token has expired, then a token can still be valid after a user is logged out or blocked from an application. While shortening the JWT expiry time can help minimize the risk, there's still a window of time where a token is valid after the user's session has ended.

By implementing a blocklist, the server can use the token's expiry time and the blocklist to determine if the token is valid. When a user logs out or their account is banned, the authorization server sends a back-channel logout request to other servers, indicating that this user's session has ended. Each server can use this event to update its blocklist with the user's details. Then, when another request is sent using that user's JWT, it can get picked up as invalid even if it hasn't expired yet.

While most applications are okay with a JWT lasting a little longer than a user session, some might require stricter security. Implementing token revocation lets you derive the benefits of JWT while offering an efficient way of immediately blocking tokens.

Protection against XSS and CSRF attacks

Every storage method discussed in this article can be prone to XSS and CSRF attacks.

To prevent XSS attacks, use cookie authentication so JavaScript can't access the JWT. However, if your frontend JavaScript needs access to the JWT, you can implement a Content Security Policy to restrict which scripts can run on the page.

If you use cookie authentication, ensure your cookies are set up correctly. They should be HttpOnly and marked as Secure. Additionally, configure SameSite to restrict when the cookie gets sent in requests from third-party URLs. Other anti-CSRF mechanisms, like anti-forgery tokens, can also help secure against CSRF attacks.

There's no perfect solution when it comes to XSS and CSRF attacks. Assess your requirements, decide which storage mechanism you will use, and then cater to the vulnerabilities that come with that method.

Troubleshooting common issues

JWTs can be challenging to troubleshoot when things go wrong. The following are some useful tips for troubleshooting JWT issues.

Debugging JWT storage issues

If you're struggling to figure out if the JWT is being stored successfully or not, use the Application tab in your browser's developer tools to analyze the local storage, session storage, and cookies associated with the current page:

If the token appears in your chosen storage mechanism, verify that the token is in the correct format. It should consist of three parts separated by dots.

You can also monitor the lifecycle of the token logging messages. This can help identify where the token is not being processed or stored correctly in your code.

Handling token expiration elegantly

Tokens expire, so make sure you implement refresh tokens and use them to retrieve new tokens when the old ones expire.

When using refresh tokens, it's better to proactively refresh a token before it expires by monitoring its expiry time and triggering a refresh a few seconds before the expiry time. Otherwise, you might send a token that's still valid for a split second when the request is sent, but it expires when the server receives it.

If a refresh request fails, retry it as a network issue could be the cause. If it fails again, redirect the user to the authentication screen with a message notifying them that they must log in to continue using the application. This makes your application more robust when it encounters authentication errors.

Dealing with cross-domain storage hurdles

Cookies are typically associated with a specific domain, and the browser sends the cookie only when a request is made to that particular domain. However, what if your application needs to make requests to multiple domains using the same token? For example, an application's frontend might be on a different domain than the API.

If so, you should consider a backend-for-frontend (BFF) for your application. A BFF consolidates all those API calls to different services into a single service. This way, your cookie needs to be configured only for your BFF's domain. The BFF can then proxy the request to the appropriate service with the JWT.

JWT storage on mobile

Until now, you've seen how JWTs can be stored in a browser context. But what about mobile apps? Many apps need to access restricted APIs that require authentication.

JWT storage solutions like HttpOnly cookies work well in a web application but are more complex in mobile apps, given the absence of browser-specific mechanisms like cookie management. Your app would need to manually store the cookie and attach it to every request to the API. When storing the cookie, you also need to make sure it's secure and not accessible by other apps or the end-user.

Fortunately, mobile platforms offer secure storage to store sensitive secrets like JWTs. On Android, you can use Keystore to encrypt JWTs, which you can then store using SharedPreferences. Similarly, iOS lets you use Keychain to encrypt and store secrets on the user's device. Using these services is similar to how you'd store JWTs in local storage on the web: after the user logs in, retrieve the JWT and store it.

When storing JWTs in a mobile app, remember that these devices are more prone to theft, so create short-lived JWTs that get rotated often using refresh tokens. You could even store a session identifier instead of the JWT in the mobile app. With a session identifier, the app makes a request to the server, which does a database lookup to retrieve the associated JWT and validate it.

While slightly more complex to set up, this approach makes it even harder for a malicious user to access the underlying JWT since it's stored and accessed on the server. This solution also gives you more control over mobile app sessions since you can terminate a session with immediate effect, unlike JWTs, which only end a session when they expire (or are added to a blacklist, as discussed above).

Conclusion

In this guide, you've discovered how local storage, session storage, cookies, and in-memory storage can be used for storing JWTs securely in web applications. The guide discussed the security implications of each approach and some pros and cons. You were then introduced to some best practices that should be followed regardless of your storage method. These include encrypting the JWTs, expiring tokens and rotating their refresh keys, handling token revocation, and protecting against XSS and CSRF attacks. Finally, the guide also provided insights into securely storing JWTs in mobile applications.

JWTs are one of the most popular forms of authentication in modern systems. As new use cases emerge, JWTs are tweaked to work in those scenarios. For example, JWTs were initially designed to be stateless, meaning servers could verify a token without looking it up in an external system. However, some use cases require immediate token revocation, which brought about stateful JWT authentication, where the server also stores information about the token to verify it's still valid.

The stateless nature of JWTs has also made them a popular choice when building scalable applications since each server can verify the token by decoding the token passed in requests. JWTs and their use cases are evolving constantly, and it's crucial that you continuously reassess your application's authentication configuration, including how you store JWTs in applications, to ensure no new security vulnerabilities or loopholes appear.

Adding Authentication and SSO to a Streamlit App

Mrunank Pawar — Fri, 03 Apr 2026 17:07:00 +0000

This blog was originally published on Descope

Streamlit makes it simple to turn Python scripts into shareable data apps. As these apps move from personal notebooks to team and company use, adding secure authentication and single sign-on (SSO) becomes essential. Authentication protects sensitive data and gates features by user identity. SSO lets people sign in once and move across apps without repeating logins.

In this tutorial, you'll use Descope, a drag & drop CIAM platform to add:

Single sign-on
Social login
Role-based access control (RBAC) to a Streamlit app.

Prerequisites

Before diving into the integration process, ensure you understand the basics of Python and Streamlit. You also need a Descope account, but don't worry if you don't have one yet—you'll learn how to set one up shortly. The free tier will be sufficient for you to follow along.

Creating a project in Descope

The first step is to connect your Streamlit app with Descope by creating a project in the Descope console.

Go to the Descope sign-up page and register for a free account (or log in if you already have one).
From the top-left menu in the console, select + Project to create a new project.

Your project dashboard is the hub where you'll:

Create and manage projects
Assign user roles
Configure authentication flows
Adjust project-level settings

In Settings > Project, you'll see your Project ID. This is a unique identifier that links your Streamlit app to Descope.

Best practice: Never paste this ID directly into your code. Instead, store it securely as an environment variable or in .streamlit/secrets.toml. Later in this tutorial, we'll show you how to use it safely inside your app.

Creating a Streamlit app

With your Descope project set up, let's move to the Streamlit side. We'll start with a bare-bones app and then integrate authentication step by step.

Create a new directory for your app. Optionally, set up a Python virtual environment inside it.
Install Streamlit with the following command:

pip install streamlit

In the new directory, create a file called app.py and paste the following code:

import streamlit as st

st.title("Demo App")
st.write("This is a demo app with Descope-powered authentication and SSO")

You need a project ID to initialize Descope, so copy yours from the console settings, create a .streamlit/secrets.toml file in the root directory of your app, and include the project ID, like this:

Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zm47gp82oqbzwm28qihp.png)

Implementing OAuth social logins in Steamlit

Before diving into enterprise SSO, let's start with something many users expect out of the box: social logins. OAuth providers like Google or GitHub let people sign in with accounts they already trust. This removes friction during signup and reduces the need to manage yet another password.

By adding OAuth, your Streamlit app instantly feels more professional and user-friendly—and when paired with SSO later, you'll cover both casual and enterprise login scenarios.

Configuring Descope as a federated identity provider for Streamlit

In this section, we walk you through setting up Descope as a federated identity provider (IdP) for Streamlit and seamlessly integrating Google login with the application you created earlier.

In the Descope console, go to: Build > Authentication Methods > Social Login (OAuth/OIDC)

Here you'll see a full list of supported providers. Select Google for this example:

Note: The Descope console provides an authentication account for all common social logins. There's also an option to specify a different account for authentication if you prefer.

Next, configure the redirect URL. This is the location users will return to after completing authentication. Since we're working locally, set it to your app's address, http://localhost:8501, in the configuration provided, like this:

Remember, you can also provide the redirect URL programmatically in your Streamlit code for added flexibility later.

Integrating Descope with your Streamlit app as its OAuth provider

Now let's wire your app to Descope so it can trigger the OAuth login flow and handle the response.

Install its Python SDK to facilitate the interaction:

pip install descope

You need a project ID to initialize Descope, so copy yours from the console settings, create a .streamlit/secrets.toml file in the root directory of your app, and include the project ID, like this:

DESCOPE_PROJECT_ID = "XXXXX"

Initialize Descope in your app:

import streamlit as st
from descope.descope_client import DescopeClient

DESCOPE_PROJECT_ID = str(st.secrets.get("DESCOPE_PROJECT_ID"))
descope_client = DescopeClient(project_id=DESCOPE_PROJECT_ID)

st.title("Demo App")
st.write("This is a demo app with Descope-powered authentication and SSO")

Create a "Sign in with Google" button that launches the OAuth flow using the descope_client.oauth.start() method:

# … collapsed repeated code
descope_client = DescopeClient(project_id=DESCOPE_PROJECT_ID)

st.warning("You're not logged in, pls login")
with st.container(border=True):
    if st.button("Sign In with Google", use_container_width=True):
        oauth_response = descope_client.oauth.start(
            provider="google", return_url="http://localhost:8501"
        )
        url = oauth_response["url"]
        # Redirect to Google
        st.markdown(
            f'<meta http-equiv="refresh" content="0; url={url}">',
            unsafe_allow_html=True,
        )

st.title("Demo App")
# …

When clicked, this button triggers the OAuth flow. Descope generates a Google sign-in URL and redirects the user there.

Your Streamlit app should now look like this:

Click the Sign In with Google button, and you are redirected back to the app with a code query parameter after successfully authenticating via Google. This flow is known as the authorization code flow. In the next step, you'll exchange the returned code for a token that authenticates your users.

You can use the Streamlit st.query_params method to capture the code from the URL, and the descope_client.sso.exchange_token() method to trade it for a token. Along with the token, Descope also provides user data and a refresh token that renews the short-lived session token. By storing this information in Streamlit's session_state, you can persist authentication details across multiple runs and conditionally display your app's content only when a valid token is present.

To persist tokens and user data, update your code as follows:

import streamlit as st
from descope.descope_client import DescopeClient
from descope.exceptions import AuthException

DESCOPE_PROJECT_ID = str(st.secrets.get("DESCOPE_PROJECT_ID"))
descope_client = DescopeClient(project_id=DESCOPE_PROJECT_ID)

if "token" not in st.session_state:
    # User is not logged in
    if "code" in st.query_params:
        # Handle possible login
        code = st.query_params["code"]
        # Reset URL state
        st.query_params.clear()
        try:
            # Exchange code
            with st.spinner("Loading..."):
                jwt_response = descope_client.sso.exchange_token(code)
            st.session_state["token"] = jwt_response["sessionToken"].get("jwt")
            st.session_state["refresh_token"] = jwt_response["refreshSessionToken"].get(
                "jwt"
            )
            st.session_state["user"] = jwt_response["user"]
            st.rerun()
        except AuthException:
            st.error("Login failed!")

    st.warning("You're not logged in, pls login")
    with st.container(border=True):
        if st.button("Sign In with Google", use_container_width=True):
            oauth_response = descope_client.oauth.start(
                provider="google", return_url="http://localhost:8501"
            )
            url = oauth_response["url"]
            # Redirect to Google
            st.markdown(
                f'<meta http-equiv="refresh" content="0; url={url}">',
                unsafe_allow_html=True,
            )
else:
    # User is logged in
    try:
        with st.spinner("Loading..."):
            jwt_response = descope_client.validate_and_refresh_session(
                st.session_state.token, st.session_state.refresh_token
            )
            # Persist refreshed token
            st.session_state["token"] = jwt_response["sessionToken"].get("jwt")
        st.title("Demo App")
        st.write("This is a demo app with Descope-powered authentication and SSO")
        st.subheader("Welcome! you're logged in")
        if "user" in st.session_state:
            user = st.session_state.user
            st.write("Name: " + user["name"])
            st.write("Email: " + user["email"])
        if st.button("Logout"):
            # Log out user
            del st.session_state.token
            st.rerun()
    except AuthException:
        # Log out user
        del st.session_state.token
        st.rerun()

At this point, your app only displays content when a user is logged in. You've successfully implemented Streamlit authentication with OAuth, laying the foundation for full Streamlit SSO with enterprise providers like Okta in the next section.

Implementing SAML SSO in Streamlit

The Security Assertion Markup Language (SAML) is an open standard for exchanging authentication and authorization data between an IdP and a service provider (SP). In this setup, platforms like Okta act as the IdP, while your Streamlit app functions as the SP.

SAML SSO allows users to access multiple applications with a single login. This is especially valuable for organizations managing many apps, since it reduces friction for users and administrators alike.

In the SSO model, organizations that use your Streamlit app are represented as tenants. Each tenant groups users, permissions, and related configurations, giving you a way to handle enterprise customers with their own SSO setup.

Configuring Okta as the IdP and Descope as the SP

For this example, you'll use Okta as the IdP while Descope acts as the SP that integrates with your Streamlit app.

In the Descope console, create a new tenant: Go to the Tenants page and click + Tenant.

In the tenant Authentication Methods section, choose the SAML protocol. Enter your email domain in the SSO Domains field under Tenant Details.

Because Descope mediates communication between Okta and your app, the two need a secure, trusted connection. This connection is established by exchanging metadata XML documents between both platforms. The good news: Descope's built-in Okta integration makes this process much simpler.

Go to your Okta account and click Admin to access your admin dashboard:

Navigate to Applications > Applications and click Browse App Catalog to explore a comprehensive list of available integrations:

Search for Descope in the catalog and add the integration. This creates a new Okta app automatically.

In the General Settings tab, provide a label for your new Okta app.

Switch to the Assignments tab and assign users who should have access to your Streamlit app via SSO:

Switch to the Sign-On Options tab and select SAML 2.0. Copy the Metadata URL then paste it into your tenant's SSO configuration in Descope. Next, copy the ACS URL and Entity ID from Descope into the Advanced Sign-on Settings in Okta:

Expand the Attribute Statements section in Okta. Map the following values:
- firstName > user.firstName
- lastName > user.lastName
- email > user.email
- uid > user.id

These mappings define how user attributes are passed from Okta to Descope.

Back in Descope, update your tenant's SSO Mapping settings so attributes from Okta align correctly with Descope's schema.

Once this is complete, you've established a working SAML SSO configuration between Okta, Descope, and your Streamlit app.

It's worth noting that Descope also provides a self-service SSO configuration designed for multi-tenant environments. With this setup, each tenant can maintain its own SSO configuration, and tenant admins can manage their Descope SSO settings directly through your application.

To enable this, you can either:

Embed the out-of-the-box sso-config flow into your app's admin interface, or
Generate a configuration link that tenant admins can use directly.

For detailed implementation guidance, refer to the Descope documentation.

Implementing the SSO flow in Streamlit

Now that you've configured SAML SSO between Okta and Descope, the next step is to implement the flow inside your Streamlit app. This will let users authenticate through Okta and seamlessly return to your app. So let's add another button under the Sign In with Google button that starts the SSO flow when clicked.

First, you'll need your tenant ID from the Descope console:

Go to your tenant's settings.
Copy the Tenant ID.
Add it to your .streamlit/secrets.toml file with the DESCOPE_TENANT_ID key.
Update the st.container element in your code like this:

# … collapsed repeated code
TENANT_ID = str(st.secrets.get("DESCOPE_TENANT_ID")) # Get tenant ID from secret
# …
    with st.container(border=True):
        # … google button here
        if st.button("Sign in with SSO", use_container_width=True):
            sso_response = descope_client.sso.start(
                tenant=TENANT_ID, return_url="http://localhost:8501"
            )
            url = sso_response["url"]
            # Redirect to Okta
            st.markdown(
                f'<meta http-equiv="refresh" content="0; url={url}">',
                unsafe_allow_html=True,
            )
# …

Your Streamlit app should now look like this:

Click Sign In with SSO to go to Okta for verification. Sign in with one of the users you assigned earlier. After successful authentication, you're redirected back to your Streamlit app with a code query parameter—just like in the OAuth flow. Since you already implemented the code exchange, you'll be signed in automatically:

Managing authorization and user privileges

While authentication verifies the user's identity, authorization controls their access to resources and features based on predefined roles and permissions. The Descope console includes tools to manage user roles and permissions so you can enforce access control in your Streamlit app. After login, Descope returns role information you can use to tailor the UI and gate functionality.

All roles and permissions live under the Authorization page. A Tenant Admin role is created by default. Let's assign that role to a user and then conditionally display admin-only content in the app.

Go to the Users page, click the kebab menu of the user you want to update, and click Edit:

In the modal, select Tenant Admin in the Roles field and click Save:

Update your code to show an admin indicator:

# … collapsed repeated code
        if "user" in st.session_state:
            # …
            if "Tenant Admin" in user["roleNames"]:
                # Show admin-specific content
                st.success("ADMIN", icon="🤖")
# …

This should now be the view of the admin user when they're signed in:

This approach ensures that only authorized users see privileged features, improving both the security and integrity of your app.

You can find the full code on GitHub.

Streamlit SSO and authentication with Descope

You just wired Streamlit SSO with Descope end to end: created a Descope project, added OAuth social login, implemented SAML SSO with Okta, and gated features with roles. You now have a secure pattern you can reuse across Streamlit apps, from personal dashboards to multi-tenant products.

Ready to keep going? Use your Free Forever account to extend your app with passwordless options, adaptive MFA, and SCIM provisioning. Have questions or edge cases to discuss? Book time with the team for a focused walkthrough.

Next.js 14 Authentication and RBAC with App Router

Mrunank Pawar — Wed, 01 Apr 2026 23:44:55 +0000

This blog was originally published on Descope

Ensuring your application is secure through resilient authentication and authorization mechanisms is crucial in the Next.js 14 development process. This helps to ensure that only authenticated users can access the protected resources of your application and that each user can access only the resources they are allowed to access.

In this guide, you'll learn how to implement Next.js 14 authentication and role-based access control (RBAC) using the App Router and Descope. Whether you're building a new application or enhancing an existing one, this guide will equip you with the skills to create secure login and access controls.

In this guide

Set up Descope authentication in Next.js 14
Implement magic link login flows
Add role-based authorization (RBAC)
Protect routes with middleware
Manage user sessions and tokens

Understanding Next.js 14 authentication and RBAC

Before implementing Next.js 14 authentication, let's clarify the core concepts you'll work with in this tutorial.

Authentication vs. authorization

Both authentication and authorization are integral to developing a secure Next.js 14 application, but they serve distinct purposes. Authentication is the process of verifying a user’s identity and is typically achieved through a set of login credentials, such as email and passwords, magic links, passkeys or other auth methods. Authorization determines whether the authenticated user is allowed to access specific resources or perform certain actions. This tutorial implements both using Next.js 14 with App Router.

Want to learn more about the basics? See our complete guide: Authentication vs. Authorization: What's the Difference?

RBAC in this tutorial

This tutorial uses role-based access control (RBAC) to manage who can do what in the blogging app:

Editor role: Can create and edit posts
Admin role: Can view and publish posts

Instead of assigning permissions to individual users, you'll assign them to roles. Then you’ll assign users to roles. This makes managing permissions scalable as your app grows. To learn more about RBAC concepts, benefits, and implementation strategies, see: What Is RBAC: Your Simple Guide

Next.js 14 and App Router

Next.js 14 supports both client-side rendering (CSR) and server-side rendering (SSR), each with different implications for authentication and authorization:

Client-side rendering (CSR): The client renders content after the initial page load. This can cause a brief flash of unauthorized content before auth state is verified. You can improve UX with loading indicators or skeleton screens during auth checks.
Server-side rendering (SSR): The server handles rendering before sending the content to the client. This approach prevents unauthorized content flashes since the server clocks the request until it verifies the auth state.

Comparing frameworks? See our comparison: Svelte vs Next.js

This tutorial uses SSR with App Router, Next.js 14's file-system-based routing solution, to implement authentication that verifies on the server before rendering.

Setting up Descope for Next.js 14 authentication

Descope simplifies adding Next.js 14 authentication and authorization by offering an intuitive SDK and visual flows to build authentication screens.

Descope Flows is a visual no-code interface to build screens and authentication flows for common user interactions with your application, such as login, sign-up, user invites, and multi-factor authentication (MFA). This feature abstracts away the implementation details of authentication methods, session management, and error handling, allowing you to focus on building the core features of your application rather than handling these complexities.

Using Descope eliminates the need to write authentication and authorization logic from scratch, saving valuable development time and reducing the risk of security vulnerabilities. Descope's infrastructure ensures your application's authentication and authorization mechanisms are secure, scalable, and easy to maintain.

The following sections explain how you can implement these features in a Next.js application using Descope. To follow along, you need the following:

Creating a Descope project

To demonstrate Next.js 14 authentication with RBAC, you'll build a simple blogging application using the editor and admin roles described above.

To begin, you’ll need to create a new project. On the Descope Console, create a new project with the name descope-nextjs-auth-rbac:

Navigate to the project setup. Select Consumers under Who uses your application? and then click Next:

Select Magic Link for Which authentication methods do you want to use? and then click Next:

Skip the MFA method step and click Go ahead without MFA. You can always set this up later:

On the next page, you can view the flows generated for your project. Click Next to generate these flows:

Once the flows are generated, select Project from the sidebar and take note of your project ID, which you’ll use in the next step:

Next, you need to obtain a management key. Select Company from the sidebar, select the Management Keys tab on the Company page, and click the + Management Key button to create a new management key. Provide the key name and, under Project Assignment, select Use this management key for all the projects in the company. Click the Generate Key button and copy the value of your key:

Once you have the key, you can implement authentication for the Next.js application. You will come back to the console to set up the RBAC.

Exploring the starter template

This walkthrough uses a simple web app shell. To keep this guide focused on authentication and authorization, we've prepared a starter template for the blogging application. In this section, you'll clone and set up the template.

To clone the template to your local machine, execute the following command in the terminal:

git clone --single-branch -b starter-template https://github.com/kimanikevin254/descope-nextjs-auth-rbac.git

Navigate into the project directory and install all the dependencies:

cd descope-nextjs-auth-rbac && npm i

shell

Create a .env project in the root folder and add the following content, which defines the location of the SQLite database:

DATABASE_URL="file:./dev.db"

shell

Run a Prisma migration for the models defined in the prisma/schema.prisma file:

npx prisma migrate dev --name init

shell

Run the app with the command npm run dev and navigate to http://localhost:3000/ on your web browser. You should see a dashboard where the posts are displayed. At the moment, no posts are available:

Users are able to write posts by clicking the Start Writing button, which directs them to the Write a Post page that has a rich text editor:

At this stage, the template is ready, but don’t create any posts until you have implemented authentication and authorization.

Adding authentication to Next.js 14

This section walks you through implementing authentication in your Next.js 14 application using Descope. You'll use code examples and screenshots to guide each step.

Key steps

Install the Descope Next.js SDK
Wrap your app with Descope authentication
Configure the “sign up or in” function
Protect routes with authentication middleware
Test the authentication flow

To get started, execute the following command in the terminal to install the Descope Next.js SDK, which you’ll use to implement authentication:

npm i @descope/nextjs-sdk

javascript

Open the app/layout.js file and replace the existing code with the following to wrap the whole application with the Descope Auth Provider:

import { Inter } from "next/font/google";
import "./globals.css";
import { AuthProvider } from "@descope/nextjs-sdk";

const inter = Inter({ subsets: ["latin"] });

export const metadata = {
   title: "Descope - Next.js Auth",
   description:
       "Demonstrating how to add auth & RBAC to Next.js 14 with Descope",
};

export default function RootLayout({ children }) {
   return (
       <AuthProvider projectId={process.env.DESCOPE_PROJECT_ID}>
           <html lang="en">
               <body
                   className={`${inter.className} max-w-screen-lg mx-auto py-4`}
               >
                   {children}
               </body>
           </html>
       </AuthProvider>
   );
}

javascript

You will set the value of DESCOPE_PROJECT_ID in the .env file later on.

You can use the sign-up-or-in flow that you generated when configuring the project to allow the user to sign in to the application. The sign-up-or-in flow presents the user with a Welcome screen where they are prompted to provide their email address.

Once the user provides the email address and clicks the Continue button, a magic link is sent to the provided email address. Once the user clicks the magic link, Descope verifies the link, and the user is authenticated. The flow then checks if the user is new or returning. If the user is new, they are prompted to provide additional information(their name), and their details are updated.

Here’s a visual representation of the flow in practice:

Open the app/sign-in/page.js file and replace the existing code with the following:

"use client";

import { Descope } from "@descope/nextjs-sdk";
import axios from "axios";
import { useRouter } from "next/navigation";

export default function Page() {
   const router = useRouter();

   // Register user or redirect to home
   const handleEvent = async (event) => {
       try {
           if (event.detail.firstSeen !== true) {
               return router.replace("/");
           }

           // Register the user
           const { data } = await axios.post("/api/register", {
               descopeUserId: event.detail.user.userId,
               email: event.detail.user.email,
               name: event.detail.user.name,
           });

           if (data.error) {
               alert("Something went wrong");
           } else {
               return router.replace("/");
           }
       } catch (error) {
           console.log(error);
       }
   };
   return (
       <Descope
           flowId="sign-up-or-in"
           onSuccess={(e) => handleEvent(e)}
           onError={(e) => alert("Something went wrong. Please try again.")}
       />
   );
}

javascript

In the preceding code, once the user signs up or in successfully, the event data returned from this component is passed to the handleEvent function.

This function checks if the user is new by examining event.details.firstSeen. If the user is not new, they are redirected to the home screen. Otherwise, it sends a POST request to the /api/register endpoint with the user’s details to register the user. If the registration is successful, the user is redirected to the home page; otherwise, an error message is displayed.

The /api/register endpoint is defined in the app/api/register/route.js files, and it adds the user to the local database.

You also need to set up a middleware to enforce authentication for all the pages in this application. Create a file named middleware.js in the project root folder and add the following code:

import { authMiddleware } from "@descope/nextjs-sdk/server";

export default authMiddleware({
   projectId: process.env.DESCOPE_PROJECT_ID,
   redirectUrl: process.env.SIGN_IN_ROUTE,
});

export const config = {
   matcher: ["/((?!.+\\.[\\w]+$|_next).*)", "/", "/(api|trpc)(.*)"],
};

shell

This code uses the authMiddleware function provided by the Descope Next.js SDK to protect all routes and redirect unauthenticated users to the sign-in page.

Update the .env file with the following:

DESCOPE_PROJECT_ID=<YOUR-PROJECT-ID>
DESCOPE_MANAGEMENT_KEY=<YOUR-MANAGEMENT-KEY>

SIGN_IN_ROUTE="/sign-in"

javascript

Make sure to replace the placeholder values with the values you obtained earlier.

The authentication for your Next.js application is now complete.

Before you test it, open the app/write/page.js file. In this file, notice that the savePost function requires the Descope user ID. You can retrieve this using the hooks provided by the Next.js SDK.

Add the following import statement to the file:

import { useUser } from "@descope/nextjs-sdk/client";

javascript

Add the following statement that retrieves the user just before the savePost function:

const { user } = useUser();

javascript

You can now test the authentication flow.

On your browser, navigate to http://localhost:3000. You are redirected to http://localhost:3000/sign-in since you have not signed in. It should look like this:

Provide your email address, click the link sent to your inbox, and provide your name since this is the first time you’re signing in. Then you are redirected to the home page:

This confirms that the authentication is working as expected.

Adding authorization to Next.js 14

Currently, anyone can log in to the application, create posts, submit them for approval, and approve the posts. For this example, you want to specify that editors can write posts and then submit them for approval, and admins can publish the posts.

Key steps

Create roles and assign permissions in Descope
Control UI visibility based on user roles
Validate roles in API routes
Configure session tokens for authorization
Test role-based permissions

Before you implement this functionality, click the Start Writing button and create a few posts to test the application with:

Go to the Descope Console, select Authorization from the sidebar, and click the + Role button. In the Add Role modal, provide “editor” as the name and “Can write posts and submit them for approval” as the description. Then click the Add button:

Repeat the process to create a role for the admin. Provide “admin” as the role and “Can toggle a post’s published status” as the description.

Assign the “editor” role to the user who is logged in to the application. In the Descope Console, select Users from the sidebar to edit the user details:

On the user details modal, select + Add Tenant / Role, assign the editor role, and click Save:

Open the app/page.js file and add the following import statement:

import { useUser } from "@descope/nextjs-sdk/client";

javascript

Add the following code before the fetchPosts function.

const { user } = useUser();

javascript

This hook allows you to retrieve the user’s details.

Locate the following lines of code in the same file:

<Link
   href={"/write"}
   className="px-4 py-1 border rounded-lg bg-black text-white"
>
   Start Writing
</Link>

javascript

Replace it with the following to display only the Start Writing button to editors:

{
   user?.roleNames?.includes("editor") && (
       <Link
           href={"/write"}
           className="px-4 py-1 border rounded-lg bg-black text-white"
       >
           Start Writing
       </Link>
   )
}

javascript

Open the app/posts/[postId]/page.js file and add the following lines of code in their respective locations (indicated by the comments):

import { useUser } from "@descope/nextjs-sdk/client"; // After the import statement

const { user } = useUser(); // Before the return statement

javascript

Locate the following lines of code:

<Button
   variant="default"
   className="px-6 mt-6"
   onClick={() => togglePublishedStatus()}
>
   {post.published ? "Unpublish" : "Publish"}
</Button>

javascript

Replace it with the following to specify that only admins can publish/unpublish a post:

{
   user?.roleNames?.includes("admin") && (
       <Button
           variant="default"
           className="px-6 mt-6"
           onClick={() => togglePublishedStatus()}
       >
           {post.published ? "Unpublish" : "Publish"}
       </Button>
   )
}

javascript

For additional security, you also validate these roles in the API router handlers. In the lib folder, create a new file named descope.js and add the following code:

import { createSdk } from "@descope/nextjs-sdk/server";

export const descopeSdk = createSdk({
   projectId: process.env.DESCOPE_PROJECT_ID,
   managementKey: process.env.DESCOPE_MANAGEMENT_KEY,
});

javascript

This code initializes a Descope client instance and exports it for use in other parts of the application.

Open the app/api/posts/create/route.js file and add the following code just after const data = await request.json():

// Make sure the user has the editor role
const userRoles = descopeSdk.getJwtRoles(data.sessionToken);

if (!userRoles?.includes("editor")) {
   throw new Error("User is not an editor");
}

javascript

This code ensures that the user has the editor role. If not, it throws an error.

Remember to add the following import statement:

import { descopeSdk } from "@/lib/descope";

javascript

Open the app/api/posts/toggleStatus/route.js file and add the following code just after const data = await request.json() to throw an error if the user making the request does not have the admin role:

// Make sure the user has the admin role
const userRoles = descopeSdk.getJwtRoles(data.sessionToken);

if (!userRoles?.includes("admin")) {
   throw new Error("User is not an admin");
}

javascript

Remember to add the following import statement:

import { descopeSdk } from "@/lib/descope";

javascript

With the route handlers verifying the user roles, you need to make sure that the session token is passed in the request body. Start by opening the app/write/page.js file and retrieving the session token using the useSession hook:

const { sessionToken } = useSession();

javascript

Make sure the useSession hook is imported into the file:

import { useSession, useUser } from "@descope/nextjs-sdk/client";

javascript

Add the retrieved session token to the body of the POST request in the savePost function:

const { data } = await axios.post("/api/posts/create", {
   title,
   content,
   descopeUserId: user?.userId,
   sessionToken,
});

javascript

Open the app/posts/[postId]/page.js file and retrieve the session token using the useSession hook:

const { sessionToken } = useSession();

javascript

Make sure the hook is imported into the file:

import { useSession, useUser } from "@descope/nextjs-sdk/client";

javascript

Replace the togglePublishedStatus function with the following code that ensures that the session token is passed to the route handlers:

const togglePublishedStatus = async () => {
   try {
       const { data } = await axios.put("/api/posts/toggleStatus", {
           postId: params.postId,
           sessionToken,
       });

       setPost(data.data);
   } catch (error) {
       alert("Something went wrong");
       console.log(error);
   }
};

Now, all the authorization checks are complete. You can test to see if everything is working as expected.

Navigate to http://localhost:3000/sign-in and log in to the application. Since you assigned the editor role to the user, you can see the Start Writing button:

Click on a post to open the details page. However, you cannot see the Publish/Unpublish button since only admins are allowed to see it:

Now, go back to the Descope Console and assign the user the admin role.

Go back to the application and refresh the page. Since the user now has the admin role, they can see the button to Publish/Unpublish a post:

This confirms that the authorization flow is working as expected.

You can access the complete Next.js 14 authentication code on GitHub.

Next steps for Next.js 14 authentication

Your authentication system is production-ready. You can extend it by adding social logins, MFA, or additional roles—all without writing custom auth logic.

This flexibility is what makes Descope's CIAM platform powerful for production applications. Use no-code workflows to add authentication methods, configure authorization rules, and manage users at scale, so you can focus on your application's core features instead of authentication infrastructure.

Start building with a Free Forever account today. Have questions about implementing RBAC or Next.js authentication? Book time with our experts.

Adding Authentication and SSO to a Reflex App

Mrunank Pawar — Fri, 27 Mar 2026 19:56:05 +0000

This blog was originally published on Descope

Reflex is an open-source full-stack web framework written in and for Python that lets you build both frontend UI and backend logic in pure Python, i.e., you don’t need to manually write JavaScript or separately manage a React/Vue frontend and a separate backend.

By adding Descope to your Reflex application, you can immediately take advantage of a full-fledged identity platform—complete with passwordless authentication, MFA, passkeys, social login, enterprise SSO, and customizable user journeys.

This lets you keep writing your entire Reflex project in Python while relying on Descope to seamlessly deliver the advanced authentication and security capabilities needed for real-world, scalable applications.

Let’s begin!

Prerequisites

It’s helpful to familiarize yourself with Python and Reflex. You’ll also need a Descope account, but don’t worry if you don’t have one yet—you’ll learn how to set one up shortly. The free tier will be sufficient for you to follow along.

Create a Descope Project

The first step in connecting your Reflex app to Descope is to create a new Project in the Descope Console.

Go to the Descope sign-up page and register for a free account (or log in if you already have one).
From the top-left menu in the console, click + Project to set up a new project.

In Settings > Project, you’ll find your Project ID, which is a unique identifier used to link your Reflex app to Descope.

Best practice: Never paste this ID directly into your code. Instead, store it securely as an environment variable in a .env file. We’ll configure this later in the blog.

Create the Reflex app

With your Descope Project set up, let’s move to the Reflex side. We’ll start with a dashboard app template and then integrate authentication step-by-step.

Create a new directory for this app and clone the company dashboard template. Optionally, set up a Python virtual environment inside it.
Add reflex-descope-auth to the requirements.txt file. Note: This is the Reflex Descope Auth plugin, which uses standard OIDC protocols to handle the login process in a reliable, familiar way.
Now run this command to install all the dependencies using the command below:

pip install -r requirements.txt

Next, create a .env file and set these environment variables in the project.

DESCOPE_PROJECT_ID=<your-descope-project-id>
DESCOPE_FLOW_ID=<your-flow-id>
DESCOPE_LOGOUT_REDIRECT_URI=http://localhost:3000
SESSION_SECRET=<secure-random-secret>

You can generate a secret using Python’s secrets module:

python -c "import secrets; print(secrets.token_hex(32))"

This is what your project structure should look like:

.
├── .gitignore
├── app
│   ├── __init__.py
│   ├── app.py
│   ├── components
│   │   ├── __init__.py
│   │   ├── documents_table.py
│   │   ├── header.py
│   │   ├── key_metrics.py
│   │   ├── sidebar.py
│   │   └── visitors_chart.py
│   └── states
│       ├── __init__.py
│       ├── auth_state.py
│       └── dashboard_state.py
├── apt-packages.txt
├── assets/
├── .env
├── requirements.txt
└── rxconfig.py

Log in a user

In the app.py file, we’ll add a button that calls start_login, a built-in method that initiates the login flow and redirects users to the Descope authorization endpoint.

def index() -> rx.Component:
    """The main page, which serves as the login entry point."""
    return rx.el.div(
        rx.el.section(
            rx.el.div(
                rx.el.button(
                    "Login with Descope",
                    on_click=AuthState.start_login,
                    class_name=(
                        "mt-8 px-8 py-3 text-white bg-red-600 rounded-lg font-semibold "
                        "hover:bg-blue-700 transition-colors shadow-md"
                    ),
                ),
                class_name="flex flex-col items-start max-w-xl",
            ),
            class_name="container mx-auto flex flex-col lg:flex-row items-center justify-between gap-12 px-4 py-16",
        ),
        class_name="w-full bg-gray-50",
    )

The dashboard_page function defines the main authenticated dashboard view of the application. It’s registered as a Reflex page using the @rx.page() decorator with the root route (/).

When a user visits this page, the on_load parameter triggers the AuthState.check_login method to verify if the user is authenticated. If the user isn’t logged in, they’ll be redirected to the login flow automatically.

@rx.page(route="/", on_load=AuthState.check_login)
def dashboard_page() -> rx.Component:
    """The main dashboard page."""
    return rx.el.div(
        sidebar(),
        rx.el.main(
            header_bar(),
            rx.el.div(
                key_metrics_section(),
                visitors_chart_section(),
                documents_table_section(),
                class_name="p-6 space-y-6",
            ),
            class_name="w-full h-[100vh] overflow-y-auto",
        ),
        class_name="flex flex-row bg-gray-50 h-[100vh] w-full overflow-hidden",
        on_mount=DashboardState.load_initial_data,
    )

The callback page handles the authentication redirect after a user logs in. It’s defined using the @rx.page() decorator and mapped to the /callback route.

When the user returns to this route after completing authentication, the on_load parameter calls AuthState.auth_redirect. This method processes the login response, typically validating tokens, storing session data, and determining whether the login succeeded or failed.

@rx.page(route="/callback", on_load=AuthState.auth_redirect)
def callback() -> rx.Component:
    return rx.el.div(
        rx.cond(
            AuthState.error_message != "",
            rx.el.div(
                rx.el.h1("Login Failed", class_name="text-red-500"),
                rx.el.p(AuthState.error_message),
                rx.el.button(
                    "Try Again",
                    on_click=AuthState.start_login,
                    class_name="px-4 py-2 text-white bg-blue-600 rounded-md hover:bg-blue-700",
                ),
                class_name="flex flex-col items-center space-y-4",
            ),
            rx.el.div(
                rx.el.p("Processing login..."), class_name="flex items-center space-x-2"
            ),
        ),
        class_name="flex items-center justify-center h-screen",
    )

The auth_error page provides a dedicated route for handling login failures. It’s defined at the /auth-error path and serves as a fallback whenever something goes wrong during the authentication process. For example, if token validation fails, the user denies consent, or the callback flow encounters an unexpected error.

@rx.page(route="/auth-error")
def auth_error() -> rx.Component:
    return rx.el.div(
        rx.el.h1("Login Failed", class_name="text-red-500"),
        rx.el.p(AuthState.error_message),
        rx.el.button(
            "Try Again",
            on_click=AuthState.start_login,
            class_name="px-4 py-2 text-white bg-blue-600 rounded-md hover:bg-blue-700",
        ),
        class_name="flex flex-col items-center space-y-4 h-screen justify-center",
    )

We’ll also add additional routes to this file to handle page protection and move the dashboard to a dedicated page.

app.add_page(dashboard_page, route="/dashboard")
app.add_page(callback, route="/callback")
app.add_page(auth_error, route="/auth-error")

Define AuthState in Reflex

Authentication in Reflex is handled through reactive state classes. The reflex-descope-auth plugin provides a base class called DescopeAuthState, which already implements the full authentication lifecycle for you. By subclassing it, we can customize how our app handles redirects and session checks after a user logs in or out. The reflex-descope-auth plugin validates Descope tokens only once during finalize_auth. After that, Reflex simply stores the session in state and does not re-check the exp or rexp claims in the token automatically.

finalize_auth is a built-in method that completes the authentication process after the redirect from Descope, exchanges the authorization code for tokens, verifies ID token, and creates a session token for the user.

By using yield, Reflex processes each step reactively—first finalizing auth, then deciding the next redirect.

import reflex as rx
from reflex_descope_auth import DescopeAuthState


class AuthState(DescopeAuthState):
    @rx.event
    async def auth_redirect(self):
        yield DescopeAuthState.finalize_auth()
        if getattr(self, "error_message", None):
            yield rx.redirect("/auth-error")
            return
        yield rx.redirect("/dashboard")

    @rx.event
    def check_login(self):
        if not self.logged_in:
            return rx.redirect("/")

check_login() is a custom method that acts as a page guard for any route that should only be accessible to authenticated users. It works by:

Checking the reactive state variable self.logged_in (which is automatically managed by DescopeAuthState).
If the user isn’t authenticated (self.logged_in is False), it immediately returns a redirect to the homepage (/), which serves as the login page.

This ensures that only valid sessions can access private pages like /dashboard.

Implementing OAuth social logins, magic links, and SSO

Once your Reflex app is wired up with the Reflex Descope Auth plugin, adding new authentication methods becomes incredibly simple. Descope flows let you drag, drop, and configure options like OAuth social logins, magic links, and SAML/OIDC SSO without changing any of your Reflex code.

If you want users to sign in with Google, GitHub or any other providers, you can configure these OAuth providers in the authentication methods in the console and add the OAuth action in the flow. For passwordless experiences, you can switch to magic link login by adding the built-in magic link action in your flow. And when your app needs enterprise authentication, you can add a SSO action to the same flow.

If you’d like to try SSO end-to-end, you can spin up a tenant and walk through the setup using the Mock SAML Testing guide. And if your organization already uses a SAML IdP such as Okta, ADFS, or PingFederate, you can simply plug in its metadata URL in place of the mock provider.

With everything controlled through Descope’s visual flow editor, your Reflex integration remains the same, with the plugin automatically handling redirects and token exchange. Here’s an example flow that combines the social login, magic link and SSO authentication:

One of the biggest hurdles is enabling each customer to set up Single-Sign-On (SSO) with their own identity provider (IdP). Descope’s SSO Setup Suite simplifies how organizations configure Single Sign-On (SSO) for their tenants. Instead of manually exchanging metadata and troubleshooting IdP configurations, the suite offers a guided, self-service flow that allows tenant admins to set up and test their SSO integration (SAML or OIDC) end-to-end.

With built-in steps for attribute mapping, SCIM provisioning, and domain routing, it significantly reduces setup time and support overhead by empowering customers to get their SSO running smoothly with minimal developer involvement.

Displaying the user name and logging out a user

Once a user successfully signs in, we can use AuthState.userinfo to display the user’s profile details such as their name, while AuthState.logged_in tracks the current authentication status. userinfo comes from the JWT claims inside the session token. The plugin extracts claims from the token and userinfo simply reads from there. To be able to add custom attributes, you can define custom claims in Descope.

In the code snippet below, the header displays a personalized welcome message along with a Logout button when the user is signed in and AuthState.logout will allow the user to log out.

import reflex as rx
from app.states.auth_state import AuthState


def header_bar() -> rx.Component:
    """The header bar component."""
    return rx.el.div(
        rx.el.div(
            rx.cond(
                AuthState.logged_in,
                rx.el.div(
                    rx.el.span(
                        f"Welcome, {AuthState.userinfo.get('name', 'User').to(str).split(' ')[0]}",
                        class_name="text-sm font-medium text-gray-700",
                    ),
                    rx.el.button(
                        "Logout",
                        on_click=AuthState.logout,
                        class_name="px-4 py-1 text-sm text-white bg-red-600 rounded-md hover:bg-red-700",
                    ),
                    class_name="flex items-center space-x-4",
                ),
                rx.fragment(),
            )
        ),
        class_name="flex items-center justify-between h-12 px-6 bg-white border-b border-gray-200",
    )

The dashboard will then look similar to this:

Reflex SSO and authentication with Descope

With Descope, implementing authentication in a Reflex app becomes both simple and highly flexible. Descope’s flows let you design every step of the user journey without managing complex logic yourself. The Reflex Descope Auth plugin then brings these flows directly into your application, handling the redirects and tokens. Together, they give you a powerful, low-code way to add secure, customizable authentication to any Reflex project.

If you have any questions about Descope or a customer identity project we can help with, book a demo with our auth experts.

Add Authentication and SSO to Your Gradio App

Mrunank Pawar — Wed, 25 Mar 2026 20:46:42 +0000

This blog was originally published on Descope

Gradio is an open source Python package that allows you to create web-based interfaces for AI models, APIs, or any Python function. Its simplicity and flexibility make it a popular choice among developers who want to quickly prototype and deploy web-based interfaces without worrying about frontend development.

Secure authentication methods are needed for these applications to help prevent sensitive data and models from being exposed and ensure that only authorized users can access certain features. Descope is an authentication and user management platform that simplifies the process of adding secure authentication to your applications. It offers a range of authentication methods and out-of-the-box support for OAuth 2.0 and OpenID Connect (OIDC), which makes it easy to implement authentication in your Gradio app.

In this guide, you’ll learn how to integrate Descope authentication and single sign-on (SSO) into a Gradio application. You’ll add basic auth to your Gradio application using magic links and social login. You’ll also implement SSO into the application by configuring Descope to use Okta as an identity provider(IdP).

Why is adding SSO important for these types of apps?

Many Gradio applications are used for business-to-business (B2B) purposes, where different organizations need secure access to their machine-learning models or APIs. In such cases, SSO is essential for several reasons:

Seamless access: Employees can log in using their company credentials instead of managing separate usernames and passwords.
Improved security: SSO reduces password fatigue and minimizes security risks associated with weak or reused passwords.
Better user management: IT administrators can enforce access policies, control permissions, and revoke access centrally through identity providers like Okta or Azure AD.

Prerequisites

To follow this tutorial, you need the following:

A Descope account
An Okta developer account
Python 3 installed on your local machine
Git CLI installed on your local machine
A code editor and a web browser

Creating a Gradio application

To keep the focus on implementing authentication and SSO, the tutorial uses a prepared starter template that you’ll build on. To clone it to your local machine, execute the command below:

git clone --single-branch -b starter-template https://github.com/kimanikevin254/descope-gradio-auth-sso.git

The Gradio application you just cloned is mounted within a FastAPI application. This setup is necessary because Gradio only supports authentication with external OAuth providers, such as Descope, when it is mounted inside a FastAPI app.

Here’s an overview of the most important files in this project:

app/core/config.py: Loads environment variables and sets application configurations using Pydantic.
app/ui/gradio_apps/: Contains three simple Gradio applications:
- admin_dashboard.py: Displays user info and a logout button. In a real-world app, this would handle admin-specific features.
- user_dashboard.py: Similar to the admin dashboard but for regular users. This is where you would implement non-admin functionalities.
- login_page.py: A simple login page that prompts users to log in with a login button.
app/ui/gradio_mount.py: Defines the GradioMounter class, which mounts all Gradio apps to the FastAPI application.
.env.example: Defines the environment variables you will require in this project.

You’ll explore the other files later.

With the files cloned to your local machine, you can move on to setting up the application. Start by creating a virtual environment, activating it, and installing all the dependencies:

python3 -m venv .venv # Create the virtual environment

source .venv/bin/activate #Activate it

pip install -r requirements.txt # Install dependencies

Rename the .env.example file to .env:

mv .env.example .env

Run the application using the command fastapi dev app/main.py and navigate to http://localhost:8000/auth/ to view the login page created using Gradio:

To view the admin dashboard, navigate to http://localhost:8000/gradio/admin:

To view the user dashboard, navigate to http://localhost:8000/gradio/user:

As you can see, all the dashboards are publicly available, which poses some security risks. In the next sections, you’ll add authentication to protect them and authorization to make sure that only users with the appropriate role can access the admin dashboard.

Setting up Descope

To integrate Descope as an external OAuth provider for your Gradio application, you’ll need to apply some configurations in your Descope console.

Open your Descope console and create a new project by clicking the project dropdown and selecting + Project:

Provide a project name on the Create project form and click Create:

You need to define a flow that will support the authentication methods you require for this project: magic links, social login, and SSO. To simplify the process, this tutorial uses a preconfigured flow included in the starter template. You’ll find it in the root folder as sign-up-or-in.json. You only need to import it into Descope. To do this, navigate to Flows > sign-up-or-in and select Import flow / Export flow > Import flow inside the flow editor. This will allow you to upload the flow from your local machine:

The flow you just imported offers three login options on the welcome screen: magic link, SSO, and social login. If a user chooses the magic link, they receive an email with a link. Clicking the link prompts new users to provide extra details while existing users get a JWT and complete the process. For social login or SSO, users are redirected to their provider, and after successful authentication, they receive a JWT, ending the flow.

Authenticating with Descope

With Descope fully set up, you can now integrate it as a custom OAuth provider for your Gradio application. You’ll need to configure an OIDC app in the Descope dashboard to obtain the necessary endpoints and credentials for the authorization code flow.

Here are the required credentials:

Client ID: A unique public identifier assigned to the application
Client secret: A confidential key shared only between the application and the authorization server
Authorization endpoint: The URL that starts the authentication process
Access token endpoint: The URL used to exchange an authorization code for access tokens
User info endpoint: The URL that retrieves details about the authenticated user
Redirect URL: The destination where users are sent after completing authentication
JWKs URI: The URL where the authorization server’s public keys are stored for verifying tokens
Scopes: Permissions that define what data and actions the application can access on behalf of the user

You will define these in the .env file. Some values for the variables are already included in the starter template, as are common for everyone. To get the ones that are not provided, navigate to Applications > OIDC default application on your Descope console. Scroll down to the SP Configuration section, copy the value of the Client ID, and assign it to the OAUTH_CLIENT_ID variable in the .env file:

Make sure you also replace the placeholder inside the OAUTH_JWKS_URI's value with the same client ID.

The OAUTH_SCOPES variable in the .env file specifies the scopes your application will request from Descope. However, Descope does not include the descope.claims (user’s roles, permissions, and tenants) and descope.custom_claims (user’s custom claims) scopes in its response by default unless explicitly configured.

To enable these scopes, go to the OIDC default application details page. In the IDP Configuration section, add descope.claims and descope.custom_claims under Supported Claims. Make sure to save the changes:

To obtain the value for the OAUTH_CLIENT_SECRET variable, navigate to M2M > + Access Key on your Descope console. On the Generate Access Key page, provide a name for your key and select Generate Key. Copy the value of the generated key and assign it to the OAUTH_CLIENT_SECRET variable in the .env file:

You now have all the required values for implementing the authentication logic. Open the app/core/auth.py file and add the following method to the Auth class to initialize the OAuth client with the necessary settings:

# Initialize the OAuth client with settings
def init_oauth(self, settings):
   self.settings = settings
   self.oauth.register(
    name=self.settings.OAUTH_CLIENT_NAME,
    client_id=self.settings.OAUTH_CLIENT_ID,
    client_secret=self.settings.OAUTH_CLIENT_SECRET,
    authorize_url=self.settings.OAUTH_AUTHORIZE_URL,
    access_token_url=self.settings.OAUTH_ACCESS_TOKEN_URL,
    redirect_uri=self.settings.OAUTH_REDIRECT_URI,
    jwks_uri=self.settings.OAUTH_JWKS_URI,
    userinfo_endpoint=self.settings.OAUTH_USERINFO_ENDPOINT,
    client_kwargs={'scope': self.settings.OAUTH_SCOPES},
   )

Add the following methods to the same class. These methods will redirect the user to the authorization endpoint set up for the OAuth client and exchange the returned authorization code for an access token:

# Redirect to authorization endpoint
async def authorize_redirect(self, request: Request, redirect_uri: str):
   return await getattr(self.oauth, self.settings.OAUTH_CLIENT_NAME).authorize_redirect(request, redirect_uri)

# Exchange authorization code for access token   
async def authorize_access_token(self, request: Request):
   try:
    return await getattr(self.oauth, self.settings.OAUTH_CLIENT_NAME).authorize_access_token(request)
   except OAuthError as error:
    raise HTTPException(
        status_code=status.HTTP_401_UNAUTHORIZED,
        detail=f"OAuth error: {error.error}"
    )

Add the following method to the same class to retrieve the currently authenticated user from the session:

# Get the current authenticated user name
   def get_current_user(self, request: Request) -> Optional[str]:
    user = request.session.get("user")
    if user:
        return user['email']

This method helps check if a request is authenticated when accessing API routes. If the user is not authenticated, you can take appropriate action, such as redirecting them to the login page.

You’ll also need a method to protect Gradio apps by ensuring the user is authenticated and has the necessary roles. Add the following method to the Auth class:

# Authenticate user and authorize based on path and roles
# To protect Gradio app routes
def authenticate_and_authorize(self, request: Request) -> Optional[str]:
   path = request.url.path
   user = request.session.get("user", {})
   tenants = user.get('tenants', [])
   roles = set()

   if isinstance(tenants, dict):
    for data in tenants.values():
        roles.update(data.get('roles', []))

   # Avoid blocking the gradio queue requests
   if '/gradio_api/queue' in path and user:
    return user['email']

   if user and self.settings.ADMIN_ROLE in roles and path == self.settings.ADMIN_DASHBOARD_PATH:
    print('pass. returning', user['email'])
    return user['email']
   elif user and path == self.settings.USER_DASHBOARD_PATH:
    return user['email']
   else:
    return None

Add the following method to the Auth class to determine which Gradio app an authenticated user should see based on their roles:

# Determine the Gradio app to show the user based on their roles
def get_user_redirect_path(self, request: Request) -> str:
   user = request.session.get("user", {})
   tenants = user.get('tenants', [])
   roles = set()

   if isinstance(tenants, dict):
    for data in tenants.values():
        roles.update(data.get('roles', []))
   else:
    print('You have not set up tenants in your Descope account. You can only access the user dashboard since the roles needed to access the admin dashboard are set up via the tenant.')

   if not user:
    return self.settings.LOGIN_PAGE_PATH

   if self.settings.ADMIN_ROLE in roles:
    return self.settings.ADMIN_DASHBOARD_PATH
   else:
    return self.settings.USER_DASHBOARD_PATH

To ensure the OAuth client is correctly initialized when the application starts, open the app/main.py file and add the following code immediately after the middleware configuration:

# Initialize OAuth client
auth.init_oauth(settings)

Set up all the auth routes by adding the code to the app/api/routes/auth_router.py file:

# Redirect to OAuth login provider
@router.get('/login')
async def login(request: Request):
   redirect_uri = request.url_for('auth_callback')
   return await auth.authorize_redirect(request, redirect_uri)

# Handle OAuth callback after successful login
@router.get("/auth/callback", name="auth_callback")
async def auth_callback(request: Request):
   try:
    token = await auth.authorize_access_token(request)
    user = token.get("userinfo")
    request.session["user"] = dict(user)
    return RedirectResponse(url="/", status_code=HTTP_302_FOUND)
   except HTTPException as e:
    # Log the error
    print(f"Authentication error: {e.detail}")
    return RedirectResponse(url="/auth/error", status_code=HTTP_302_FOUND)

# Log out the current user   
@router.get('/logout')
async def logout(request: Request):
   auth.logout(request)
   return RedirectResponse(url="/", status_code=HTTP_302_FOUND)

# Authentication error page
@router.get("/error")
async def auth_error():
   return {"error": "Authentication failed. Please try again."}

This code defines routes that allow the user to log in, handle the OAuth callback, and log out of the application.

Set up the dashboard routes that will display the appropriate dashboards to the user based on their roles by replacing the existing route in the app/api/routes/dashboard_router.py file with the following:

# Main entry point, redirects based on user role
@router.get("/")
def index(request: Request):
   user = auth.get_current_user(request)
   if user:
    redirect_path = auth.get_user_redirect_path(request)
    return RedirectResponse(url=redirect_path, status_code=HTTP_302_FOUND)
   else:
    return RedirectResponse(url=auth.settings.LOGIN_PAGE_PATH, status_code=HTTP_302_FOUND)

# Routing endpoint for Gradio dashboards
@router.get("/gradio")
async def route_dashboard(request: Request):
   redirect_path = auth.get_user_redirect_path(request)
   return RedirectResponse(url=redirect_path, status_code=HTTP_302_FOUND)

Lastly, protect the Gradio dashboards by replacing the mount_admin_dashboard and mount_user_dashboard methods in the app/ui/gradio_mount.py file with the following:

# Mount the admin dashboard with authorization   
def mount_admin_dashboard(self):
   with gr.Blocks() as admin_dashboard_wrapper:
    admin_dashboard.main.render()

   self.app = gr.mount_gradio_app(
    self.app,
    admin_dashboard_wrapper,
    path=self.settings.ADMIN_DASHBOARD_PATH,
    auth_dependency=self.auth.authenticate_and_authorize
   )

# Mount the user dashboard with authorization
def mount_user_dashboard(self):
   with gr.Blocks() as user_dashboard_wrapper:
    user_dashboard.main.render()

   self.app = gr.mount_gradio_app(
    self.app,
    user_dashboard_wrapper,
    path=self.settings.USER_DASHBOARD_PATH,
    auth_dependency=self.auth.authenticate_and_authorize
   )

This code adds the auth_dependency parameter before mounting these apps, which runs before any Gradio-related route in your FastAPI app. This ensures that proper authentication and authorization checks are performed before displaying the dashboards.

You can now log in to the application using either magic links or social login.

Implementing SSO with OIDC using Descope

OIDC is an identity layer built on top of the OAuth 2.0 framework. It allows applications to authenticate users securely by delegating authentication to a trusted IdP, such as Okta. OIDC simplifies SSO by enabling users to log in once and access multiple applications without reentering credentials.

To implement SSO, you can configure Okta as the IdP and Descope as the authentication service. Start by launching your Okta admin dashboard and navigating to Applications > Applications > Browse App Catalog:

On the Browse App Catalog page, search for descope, and select Descope from the search results:

Select + Add Integration from the Descope app details page:

On the General Settings tab, leave everything as is and click Next:

On the Sign-On options tab, select OpenID Connect as the sign-on method:

Scroll down to the Advanced Sign-on Settings section, and in the Callback URL field, provide the value https://api.descope.com/v1/oauth/callback. This defines the URL where the user will be redirected after getting successfully authenticated by Okta. Save the changes by clicking Done at the bottom of the page:

You also need to assign users to the Descope app you just configured. This will ensure that only authorized users can authenticate via the app. To do this, go to the app’s details page and the Assignments tab and select Assign > Assign to Groups:

On the Assign Descope to Groups page, select the Assign button beside the Everyone group to allow all users in your organization to authenticate via the app, and select Done to save the changes.

Select the Sign On tab and take note of your OIDC client ID and secret:

Go to the Descope console to create a tenant that you will use with the Descope app you just configured in Okta. On your Descope console, navigate to Tenants > + Tenant, provide the tenant details on the Create Tenant form, and select Create:

Open the details page of the Tenant you just created, add your email domain under the Tenant Settings > Details section in the Email domain field, and save the changes:

Select Authentication Methods > SSO from the tenant details page sidebar, and under Authentication Protocol, select OIDC:

Under Tenant Details > SSO Domains, provide your email domain. This will help to determine which SSO configuration to load once a user chooses to authenticate using SSO:

Scroll down to the SSO configuration > Account Settings section and provide the required values as follows:

Provider Name: Okta
Client ID: The Client ID you obtained from the Okta dashboard
Client Secret: The client secret you obtained from the Okta dashboard
Scope: openid profile email
Grant Type: Authorization code

To obtain the values needed for the SSO configuration > Connection Settings section, you’ll need the OAuth endpoints from the Okta “well-known” configuration. Navigate to https://<YOUR-OKTA-INSTANCE>.okta.com/.well-known/openid-configuration on your browser, and take note of the issuer and authorization, token, user info, and JWKs endpoints.

Make sure to replace <YOUR-OKTA-INSTANCE> with the correct value, which is your organization’s Okta instance ID.

Head back to the Descope console, provide these values in the respective inputs under SSO configuration > Connection Settings, and save the changes.

SSO with Okta as the IdP is now fully configured.

Demonstrating the application

To run the application and confirm that everything is working as expected, use the command fastapi dev app/main.py and navigate to http://localhost:8000 on your browser. You will be redirected to the login page:

Click the Login button, and you’ll be redirected to Descope’s sign-in page, which is powered by the flow you configured earlier. You can sign in using any of the available methods:

After successful authentication, you’ll be redirected to the user dashboard. This is because you don’t have the appropriate roles to access the admin dashboard:

If you manually tried to navigate to http://localhost:8000/gradio/admin, you will get an error informing you that you’re not authenticated:

To check if a user with the appropriate role can access the admin dashboard, open the users’ page on the Descope console, edit your user to assign them the Tenant Admin role, and save the changes:

Now, go back to the app, log out, and log in again. You should be redirected to the admin dashboard:

Conclusion

In this guide, you learned how to integrate Descope as an OAuth provider for your Gradio application using OIDC. You also explored how to implement SSO with Okta as the identity provider and Descope as the authentication service. Additionally, you implemented role-based access control to protect Gradio app routes.

Descope is a drag-and-drop customer authentication and identity management platform. Our no- or low-code CIAM solution helps hundreds of organizations easily create and customize their entire user journey using visual workflows—from authentication and authorization to MFA and federated SSO. Customers such as GoFundMe, Navan, You.com, and Branch use Descope to reduce user friction, prevent account takeover, and get a unified view of their customer journey.

To learn more, join our dev community, AuthTown, and explore the Descope documentation.

Build a Custom Search Engine

Mrunank Pawar — Tue, 09 Aug 2022 12:15:00 +0000

Build a personalised search engine with Google's search API.

Just a heads up that this is not actually an entire search engine but you can definitely learn to play and customise this project as per your needs using Google's API

We are going to build a custom search engine using Google's Search API to fetch queries and display the most relevant search results.

To build this search engine, we're going to need:

HTML
CSS
Javascript
Repl.it account
Google account

We'll also be getting our hands on Google APIs, and you don't need to worry if you don't know about how you can use it, because we'll be taking you through that as well.

Getting Started

We are providing you the starter files for this project and fork it so you can make the changes and get started with building the search engine. The starter file includes the styles and preliminary code to help you kickstart this project.

Once this is ready, head on over to the index.html file and add the following between the <body> </body> tags:

<img src="brewgle.png" width="525" class="image">

<div class="search">
  <input type="text" id="search" class="input">
  <button id="submit" class="searchbtn" onclick="submit()">Search</button>
</div>

This will reference the image with it's corresponding styling! Feel free to add your own to make it personalized. Then, we are going to add a search input and button that calls submit() when clicked.

Now, we need to create a section for the content to appear! Add the following right below the </div>

<div id="buttons" class="buttons">
  <button id="allbutton" class="all" onclick="submit()"></button>
</div>
<div id="content"></div>

Finally, let's reference the javascript files to connect the queries to the web!

<script src="script.js"></script>
<script id="query" src="query.js"></script>

Google API

Supercool—the interface is now complete! Now let's fetch some queries. In your query.js file, you should see a function that calls submit(). Within that function, paste the following code:

document.getElementById('buttons').style.display = 'block';
document.getElementById('content').innerHTML = '';
var val = document.getElementById('search').value;
var newelement = document.createElement('script');
newelement.src = `https://www.googleapis.com/customsearch/v1?key=API_KEY&cx=003606982592251140240:5xbiwoxb3m0&q=${val}&callback=hndlr`;
newelement.id = 'mainscript';
document.body.appendChild(newelement);

Now, we need to set up the Google Search API! To get started, head on over to Google's Developer Portal and make sure that you are logged in. Once complete, scroll down to Get a Key and create a project called Search. Once you click next, copy your API key and click Done. In your query.js file, you will see a variable called newelement.src. Where it says API_KEY, paste in your API Key and you're good to go!

So what is this URL and why is it so long?

https://www.googleapis.com/customsearch/v1? lets us know that we are using the Google Custom Search API, the first version of it
key=API_KEY indicates the user of the API, as well as any limitations. For example, this will associate the number of queries per day with your account
&cx= associates any searches with a search engine Id
q=${val} is the actual query that a user inputs, which we will fetch from the submit() function in our HTML
callback=hndlr is used as a parameter that is called after the function is executed

Formatting Query Results

Now that this is completed, let's format our content. Head over to the script.js file and you should see a function called hdnlr(response). Inside this function, add the following code:

try {

} catch(error) {

}

Essentially, the function will try some code, and if it does not work, will catch & output an error. Within the try function, add the following code:

document.getElementById('content').innerHTML += `
  <div style="color: grey;">
    Wohooo! About ${response.searchInformation.formattedTotalResults} results in ${response.searchInformation.formattedSearchTime} seconds!
  </div>`

This fetches the amount of results and the time it took to retrieve, just like how you see on Google! Then, to fetch the actual information, add the following to your try function:

for (var i = 0; i < response.items.length; i++) { 
  document.getElementById('content').innerHTML += `
  <div style="align-items: center;">
    <br>
    <a style="color: grey; font-size: 12px; text-decoration: none;" href=${response.items[i].link} target="_blank">${response.items[i].link}</a>
    <a target="_blank" href=${response.items[i].link} style="text-decoration: none;">
      <h2 style="margin-top: 2px;">${response.items[i].title}</h2>
    </a>
    <div style="margin-top: -8px;">
      ${response.items[i].htmlSnippet}
    </div>
  </div>`;
}

Now, your code will fetch the link, title and htmlSnippet to display for each query. To output any errors, add the following to the catch function:

document.getElementById('content').innerHTML = 'error!';

And just like that, you've successfully fetched your meta data for each query! Now, click 'Run' at the top of your Repl and watch the magic happen!

If your code outputs an error, feel free to reference the final code!

Magic Time!

And that's it! If you click run and head to your replit link, you should see a full functional search engine at your service! Here's a link to the final code (excluding the API key) if you need any help!

Few important points to remember:

Please do not share your API key with anyone
Do not exceed 100 queries per day (Because Google provides only 100 free queries a day, or else you can exceed your limit by paying the extra charges)

Happy Hacking and join Hack Club TechBrewers for building more amazing stuff 🚀

A session on Introduction to SparkAR

Mrunank Pawar — Fri, 22 Oct 2021 16:43:12 +0000

I conducted a session on Introduction to Spark AR where we travelled through all the steps right from prerequisites to publishing an effect.

Most of the folks attending the session were new to Augmented Reality so they were quite interested to learn how it works and how they themselves can create their own AR Filter.

There were about 30-40 active folks who learnt something new in the session and also I got some requests

Also got some important reviews which will help me to improvise my upcoming events also shared about Hack This Fall 2.0 at the event which will be helpful for the students to kickstart their hackathon journey.

Create a simple Facebook and Instagram AR filter

Mrunank Pawar — Sun, 12 Sep 2021 15:59:45 +0000

Hello folks!

We all are using social media and have used various AR Filters which are available on Facebook and Instagram. Well, what if I tell you that we can create our own AR Filter and publish it so that everyone can use it.

This blog post will go through all the steps needed to create a simple AR Filter.

Step 1: Install SparkAR Studio and SparkAR player

Spark AR Studio: Spark AR Studio is the place where we will be creating the effect
Spark AR Player: Spark AR Player is the place where we will be testing our effect (Android and iOS)

Step 2: Keep your assets ready

I recommend that all the images you want in your effect must be ready in one folder so that it will be easy to just add those images as material later.

You can create the assets with the help of:

Photoshop
AR Library
Canva
Any editing app you wish to use

Step 3: Open Spark AR studio

Create a blank project

This is how our working environment looks like.

Step 4: Add a face tracker

By adding a Face Tracker to your effect you can track the face movement of the user.

Right-click in the scene panel and add a Face tracker.

Step 5: Add planes

Once again right-click in the scenes panel and add a plane to your project.
And drag it under the face-tracker. This will sync the plane with your face movement.

Step 6: Add material to the plane.

Click on the plane in the scenes panel
Now add material to your plane. (on the right side).

Try to rename the materials such that you will be able to understand them later.

Step 7: Adding texture to the material.

On the right side you will be able to see the texture.
Select your assets from the drop-down or by choosing the file.

Step 8: Adjustments

You can adjust the position of the plane by playing around with the x, y, and z axes.
You can also perform image transformations by changing the values.

Step 9: Testing

Now, we are ready with our filter and it's time for testing.
You can test it using Spark AR Player.

Step 10: Publish your effect

Now it's time for the world to use your AR Filter.
Click on the Publish button.
You have to provide the required details for publishing the filter and you're done from your side.

Note: Keep a small AR Filter demo video and also a logo for your AR Filter ready before clicking the Publish button

Congratulations, you can now create and publish your own AR Filters.

Thank you.

HackThisFall 2.0

Hey folks,
I am thrilled to inform you that I have been accepted as a “Hackathon Evangelist” for Hack This Fall 2.0!🎉

Super excited to bring a change and contribute to the hacker community in a meaningful way!🚀

🔗 Do register for Hack This Fall 2.0

Use the referral code HTFHE001 while registering.

See you there !!👋🏻

Hackathon Experience

Mrunank Pawar — Sun, 17 Jan 2021 04:40:27 +0000

My MLH Hackathon Experience :
-> My first hackathon I attended was SharkHacks and to be honest was really very nervous, I did not submit any project for it but tried to attend Workshops & Mini-events and at the closing ceremony I got an idea in my mind how to submit the projects. In the upcoming weekends I started attending the Hackathons and also submitted the projects and published demo videos on YouTube. Currently as I'm writing this post I'm also participating in MLH LocalHackDay : Build which is a weeklong event and it's great fun here.

Why MLH?
-> Major League Hacking Events are mostly during the weekends. These hackathons are for everyone may it be a newbie programmer or a seasoned player.
So if you are thinking of having something to do this weekend then why not participate in a Hackathon? And not to forget the connect and exposure we get by participating and demoing our projects is just wow.
Because of these hackathons we are able to work and complete a project within the deadline.
Major League Hacking Hackathons aren't just about coding but they have some awesome mini-events as well in which you can chill and have fun.
MLH also has some awesome swags like stickers, tees, postcards,etc. for their participants and demoers. And who doesn't love to have swags!

Hacktoberfest : The best experience

Mrunank Pawar — Fri, 16 Oct 2020 07:15:48 +0000

What I Learned From Hacktoberfest

It was my first time at the #hacktoberfest and really it was an amazing experience. I'm looking up to participating in upcoming Hacktoberfest now!! Thank you Digital Ocean for such a great adventure.