Google has prepared a roadmap to restrict third-party cookies in Chrome. Since 04 January 2024, Chrome has rolled out third-party cookie restrictions for 1% of stable clients and 20% of Canary, Dev, and Beta clients.
\nWhat does it mean for user authentication?
\nOn one hand, Google believes third-party cookies are widely used for cross-site tracking, greatly affecting user privacy. Hence, Google wants to phase out (or restrict) supporting third-party cookies in Chrome by early Q2 2025 (subject to regulatory processes).
\nOn the other hand, Google introduced Privacy Sandbox to support the use cases (other than cross-site tracking and advertising) previously implemented using third-party cookies.
\nIn this article, we’ll discuss:
\nThird-party cookie restrictions affect user authentication in three ways, as follows.
\nIf your website or app uses an external Identity Provider (IdP) — like LoginRadius, the IdP sets a third-party cookie when the user authenticates on your app.
\nIf you have multiple apps across domains within your organization and authentication is handled using an IdP (internal or external) with web SSO, you already use third-party cookies to facilitate seamless access for each user using a single set of credentials.
\nIf you have implemented web SSO with one primary domain and multiple sub-domains of the primary domain, third-party cookie restrictions may not apply. For now, Google doesn’t consider the cookies set by sub-domains as third-party cookies, although this stance may change in the future.
\nFor example, you have apps at example.com, travel.example.com, stay.example.com, and web SSO is handled by auth.example.com. In this case, third-party cookie restrictions don’t apply.
Federated SSO is similar to, albeit different from, web SSO. It can handle multiple IdPs and applications—aka., Service Providers (SPs)—spanning multiple organizations. It can also implement authentication scenarios that are usually implemented through web SSO.
\nUsually, authentication is handled on a separate pop-up or page when the user wants to authenticate rather than on the application or website a user visits.
\nFor example, you already use federated SSO if you facilitate authentication for a set of apps through multiple social identity providers as well as traditional usernames and passwords.
\n\n\nNote: It is also possible to store tokens locally, not within cookies. In this case, third-party cookie restrictions won’t affect token-based authentication. However, the restrictions still affect authentication where tokens are stored within third-party cookies (a common and secure method).
\n
Google has been developing alternative features and capabilities for Chrome to replace third-party cookies as part of its Privacy Sandbox for Web initiative.
\nSpecific to authentication, Google recommends the following:
\nCHIPS are a restricted way of setting third-party cookies on a top-level site without making them accessible on other top-level sites. Thus, they limit cross-site tracking and enable specific cross-site functionalities, such as maps, chat, and payment embeds.
\nFor example, a user visits a.com with a map embed from map-example.com, which can set a partitioned cookie that is only accessible on a.com.
If the user visits b.com with a map embed from map-example.com, it cannot access the partitioned cookie set on a.com. It has to create a separate partitioned cookie specific to b.com, thus blocking cross-site tracking yet allowing limited cross-site functionality.
You should specifically opt for partitioned cookies (CHIPS), which are set with partitioned and secure cookie attributes.
\nIf you’re using an external identity provider for your application, CHIPS is a good option to supplant third-party cookie restrictions.
\nHowever, CHIPS may not be ideal if you have a web SSO or federated SSO implementation. It creates separate partitioned cookies for each application with a separate domain, which can increase complexity and create compatibility issues.
\nWith Storage Access API, you can access the local storage in a third-party context through iframes, similar to when users visit it as a top-level site in a first-party context. That is, it gives access to unpartitioned cookies and storage.
\nStorage Access API requires explicit user approval to grant access, similar to locations, camera, and microphone permissions. If the user denies access, unpartitioned cookies and storage won’t be accessible in a third-party context.
\nIt is most suitable when loading cross-site resources and interactions, such as:
\nVerifying user sessions when allowing interactions on an embedded social post or providing personalization for an embedded video.\nEmbedded documents requiring user verification status to be accessible.
\nAs it requires explicit user approval, it is advisable to use Storage Access API when you can’t implement an identity use case with the other options.
\nWith Related Website Sets, you can declare a primary website and associatedSites for limited purposes to grant third-party cookie access and local storage for a limited number of sites.
Chrome automatically recognizes related website sets declared, accepted, and maintained in this open-source GitHub repository: Related Website Sets
\nIt provides access through Storage Access API directly without prompting for user approval, but only after the user interacts with the relevant iframe.
\nIt is important to declare a limited number of domains in related website sets that are meaningful and used for specific purposes. Google may block or suspend any exploitative use of this feature.
\nThe top-level site can also request approval for specific cross-site resources and scripts to Storage Access API using resuestStorageAccessFor() API.
If you’re using an external identity provider for your web application, you can declare the domain of the identity provider in the related set to ensure limited third-party cookies and storage access to the identity provider, thus ensuring seamless user authentication.
\nRelated Website Sets can also work to supplement third-party cookie restrictions in web SSO and federated SSO if the number of web applications (or domains) is limited.
\nFedCM API enables federated SSO without third-party cookies.
\nWith FedCM API, a user follows these steps for authentication:
\nYou can access a user demo of FedCM here: FedCM.
\nFor more information about implementing federated SSO with FedCM API, go through the FedCM developer guide.
\nFirstly, we’re committed to solving our customers' user identity pain points — and preparing for the third-party cookies phase-out is no different.
\nWe’ll implement the most relevant and widely useful solutions to facilitate a smooth transition for our customers.
\nPlease subscribe to our blog for more information. We’ll update you on how we help with the third-party cookie phase-out.
\nThe proposed changes to phase out third-party cookies and suggested alternatives are evolving as Google has been actively collaborating and discussing changes with the border community.
\nMoreover, browsers like Firefox, Safari, and Edge may approach restricting third-party cookies differently than Google does.
\nFrom LoginRadius, we’ll keep you updated on what we’re doing as a leading Customer Identity and Access Management (CIAM) vendor to prepare for the third-party cookie phase-out.
\nTop-level site: It is the primary site a user has visited.
\nFirst-party cookie: A cookie set by the top-level site.
\nThird-party cookie: A cookie set by a domain other than the top-level site. For example, let’s assume that a user has visited a.com, which might use an embed from loginradius.com to facilitate authentication. If loginradius.com sets a cookie when the user visits a.com, it is called a third-party cookie as the user hasn’t directly visited loginradius.com.
First, let's understand:
\nSSO stands for Single Sign-On. It's an authentication process that allows a user to access multiple applications or systems with one set of login credentials (username and password). Instead of requiring users to log in separately to each application, SSO enables them to log in once and gain access to all the connected systems without needing to re-enter their credentials.
\nOpenID Connect (OIDC) is a protocol that builds on OAuth 2.0 to ensure secure user authentication and authorization. It adds an identity layer to OAuth 2.0, allowing applications to confirm a user's identity and gather basic profile information. OIDC utilizes JSON Web Tokens (JWTs) for these functions, aligning with OAuth 2.0's token acquisition methods. This integration enables seamless user authentication across different platforms, supporting features like single sign-on, where users can access multiple applications with one set of credentials managed by an identity provider.
\nLoginRadius is a high-performance, scalable identity and access management platform focused on customer-facing use cases. It offers comprehensive features and capabilities to help you implement user authentication and authorization and manage user data with built-in workflows and security controls.
\nOn these lines, LoginRadius offers built-in support for OIDC and the use of OIDC to implement SSO.
\nFirst, you need to create an OIDC application in LoginRadius to tailor user claim fields effortlessly. You can fine-tune these customizable user claims through LoginRadius' user-friendly interface. Subsequently, you can seamlessly integrate these claims into the token, enabling streamlined extraction and utilization within the application ecosystem.
\nIn essence, LoginRadius facilitates the setup of OIDC applications and offers customization capabilities through its intuitive interface. This ensures efficient management of user claims, ultimately contributing to a more personalized and secure authentication experience.
\nAfter setting up the OIDC app from the LoginRadius dashboard, you'll use the go-oidc library to configure our provider further and configure the oidc connect.
Go to OIDC Application Configuration and click on Add App button
\nAfter clicking the Create button, you'll get the OIDC application configuration page. This page contains details like your application's Client ID and Client Secret, which are necessary for setting up the OIDC provider and configuration when you code in Golang.
\nThis array of configurable options empowers you to fine-tune your OIDC Application according to your specific requirements. To ensure seamless redirection of requests and successful callbacks to your endpoint, add your application's domain to the whitelist. This will authorize the redirection process and prevent failures when calling the callback endpoint. LoginRadius lets you uniquely identify the redirect URLs for individual OIDC applications: When setting up a new provider, you'll need to input the LoginRadius OIDC App URL, typically in this format: To seamlessly integrate this with your Go backend, create two essential APIs for setting up and configuring By establishing these APIs, your Go backend efficiently handles the authentication flow, ensuring a smooth user experience while securely managing user identity and access. Handle the callback hit that exchanged the authorization token for the access token: For both endpoints, let's review a sample backend server with implementation in Gin Golang. For OIDC integration with the Go backend, you'll implement it using the coreos/go-oidc library (feel free to check it out). This library provides comprehensive support for OIDC, allowing to easily verify tokens, extract user claims, and validate ID tokens. Its features ensure secure authentication and seamless integration with various OIDC providers. With the The process described involves several key steps in setting up an OAuth2 flow with OpenID Connect (OIDC) for user authentication. Here's a brief overview of what was done in the code: This process leverages the security and standardization provided by OIDC and OAuth2 to implement a secure authentication flow. By following these steps, the application can authenticate users through LoginRadius OIDC provider, ensuring that user credentials are managed securely and that the application can trust authenticated users' identities. In this tutorial, you have learned how to implement OIDC SSO with LoginRadius as the Identity Provider. You have also built a simple Golang backend with Gin to understand the implementation. First, let's understand some basic terminology. In LoginRadius, you can implement brute-force lockout using APIs. To implement brute-force lockout, please register in the LoginRadius Admin Console. Let's go through the API implementation of brute-force lockout and user unlock. You can view the created app using the link https:// In LoginRadius, the brute-force lockout feature can be enabled from the Admin Console. In the Admin Console, you can set the brute-force lockout threshold, lockout type, and suspend effective period. LoginRadius supports the following lockout types: CAPTCHA: Refer CAPTCHA in miscellaneous section to learn more. You can unlock the locked user account in two ways, using: For more understanding on Auth Unlock Account, refer Auth Security Configuration Calling the Account Update API with the provided endpoint, using the given method, providing the apisecret and apikey, and formatting the given body will unlock the account. LoginRadius supports the following types of CAPTCHAs: To understand more about LoginRadius APIs, refer to the API docs. LoginRadius is one of the leading and technologically advanced Customer Identity and Access Management (CIAM) solutions. Enterprise customers rely on our CIAM to manage end-user authentication and authorization. They typically serve hundreds of thousands to millions of end-users, making our CIAM a critical part of their IT infrastructure and value delivery. Our backend consists of multiple microservices handling various identity and access management functions and workflows through APIs. And we use MongoDB as persistent storage for configuration data. For faster access and availability of this data, we deployed Redis in-memory cache through Redis Enterprise Cloud. We had our configuration cache set up in Redis Cloud. And to reduce the Redis Cloud latency, we kept the configuration cache at the application level in memory — but we ran into problems. Generally, customers don’t update their configurations so frequently. But when a customer updates their configuration, it doesn’t propagate in the backend until the server memory cache is purged — sometimes even taking several hours. This is bad for business: A customer updates configurations in response to a new requirement or rapidly changing business environment. If these changes take so much time for a digital identity process, it can affect end-users and, in turn, business outcomes. Simply imagine that a customer updated app configuration to accommodate a one-time flash sale, and end-users can’t place orders properly due to configuration update issues! So, we started evaluating various options to address these issues. We considered running multiple instances in the Redis Cloud and synchronizing them to minimize latency for all regions while ensuring customer configuration updates go live immediately. But this proved to be technically cumbersome and costly. We continued our research with various solutions and concluded that AWS ElastiCache for Redis best serves our needs. AWS provides ElastiCache for Redis as a Redis Cloud alternative with all necessary capabilities. Also, we were already using AWS Cloud for some of our IT infrastructure needs.\nSo, we can deploy ElastiCache alongside the same infrastructure to solve the latency issues. Accordingly, we have created ElastiCache instances in multiple AWS regions and set up the primary ElastiCache DB to quickly sync configuration updates in the secondary ElastiCache instances. Also, we deployed ElastiCache instances in multiple locations as needed. For migration, we updated the old Redis and ElastiCache primary instances simultaneously. Once we reached a sufficient confidence level with the new setup, we completely switched over to ElastiCache. Our applications and cache are deployed in AWS, so our API response latency is no longer problematic. Ultimately, we can reduce application in memory cache updates to a few minutes or seconds as required. Now customers get updated configurations deployed rapidly, solving our primary challenge! As a developer, I like to work on the terminal. Many developers are the same way. Instead of scrolling, clicking the mouse, they prefer working with only keywords (through commands or shortcuts). The command-line interface (CLI) is a great tool for them. So, LoginRadius has launched a CLI for its enterprise dashboard. The CLI makes it easier by using some commands to perform different operations and manage the flow of the LoginRadius Enterprise dashboard. We always look for ways to eliminate resistance from the process of working with LoginRadius. Therefore, we have taken this step to introduce LoginRadius CLI for a better developer experience. In the 1970s and 1980s, most users preferred to use command-line interfaces. As time passed, we shifted to graphical user interfaces. GUIs are user-friendly; however, CLIs are faster than GUIs. Here is an example of adding domain via Admin Console v/s CLI : To add a domain through LoginRadius Admin Console, you need to: \\ On the flip side, you can do this by running a single command: Here are some more of LoginRadius CLI Enterprise's commands: 1. Login/Logout to your LoginRadius Dashboard This command (lr login) will help you to login to your LoginRadius Enterprise Dashboard. Once logged in, you can perform other operations and configure your LoginRadius Application through CLI. 2. Manage Application Credentials You can get our App Credentials, reset Secret key, update account password and generate SOTT through LoginRadius CLI. Set Schema for Your LoginRadius Application This command will help you set the schema for your application. We can get all the basic fields via lr get schema we can update the schema via lr set schema. Theme Management (LoginRadius Page) It is essential to protect your APIs for a secure experience, and JSON Web Token (JWT) authentication allows you to protect your APIs so that an unauthorized person will not have access. This is a hands-on tutorial to follow. To get the most out of it, ensure you have: Deno is developed in Rust. It is a modern runtime environment for JavaScript/TypeScript and a WebAssembly that uses the Google V8 engine. It is simple and safe. It implements web platform standards and provides web platform capabilities. Deno’s features are intended to enhance Node.js’s capabilities. It’s secure by default, with no access to files, networks, or the environment except explicitly enabled. And it supports both JavaScript and TypeScript out of the box. Deno is a well-thought-out modular system. Apart from its simplicity and high security, there are so many other reasons to use Deno: JSON Web Token, popularly called JWT, is an open standard that offers a concise and self-contained method for securely transferring data between parties as a JSON object. It holds information in an easy-to-access format for developers and computers; the token's compact size makes it simple to send through URL, POST parameter, or HTTP header. It allows two parties — a client and a server — to share information securely. A secret or public/private key pair is used to digitally sign the information in a JWT. Authentication is the primary use of JWT. It is assigned to a user after they sign in to an application, and with the assigned JWT, a user can request other routes. Without too many shenanigans, let's start by installing Deno! Deno installation in Windows isn't as smooth sailing as on Mac or Linux. Unlike in Node.js, where you run a command on your terminal, Deno in Windows can be installed using PowerShell, Scoop (a command-line installer), or Chocolatey (a package manager). Click here for the guide on how to install Deno. To install Deno with PowerShell, open your PowerShell and run the following command: Relax while Deno is being installed. When completed, exit PowerShell and close and reopen a terminal. The new PATH is activated by closing and reopening the terminal. Now that you have installed Deno, let's check the version of Deno. To check the version of your installed Deno, run: With installation out of the way, let us set up your project. Create a folder Inside your Your project directory should look as follows: │\n└─src Next is to create your Oak server. Oak is a Deno middleware system that provides a router middleware for HTTP servers. Go to Let's quickly run your server: to run the server, use Deno will always request permission to use your network. You should see Now, in your Moving on, you need to modify You can rerun your app with the same command: Now, you need to create user data. But before that, let's connect your application to the MongoDB database. With that out of the way, let's create an interface for your database. In your Let's play with some logic: go to your It's not a good practice to store your password in plain text for security reasons. To has your password, let's import bcrypt from the deno bcrypt URL. So, create a function called Now, head over to Next, create an authentication route that authenticates your user route. The latest version of Deno does not allow a string as a secret key but accepts a cryptokey generated from a Web Crypto API with the So, head over to your Now that you have successfully created your key, you can create a user authentication route so that every user that logs in will get authenticated. Head over to Now, let's import Deno JWT (djwt) So far, you have progressed well. The next thing is to import your Congratulations on making it this far! You are through with the authentication route. Now, you can register a user, sign in, and authenticate the user. You need to create your todo CRUD API and protect the routes so that a random person will not be able to access your route except when authenticated. Go to your After successfully creating the task interface, move to our controller, create a file With that out of the way, you need to create your todo CRUD routes. So, head over to You need to protect your todo routes so that an unauthorized person will not be able to access them. To protect the todo routes, go to your The authorize function checks if a user has a JWT token, grant the user access if he does, and deny him access if otherwise. To protect your todo routes, import the authorized middleware function from the Awesome! Your application is ready, but wait! Don't get too excited yet, relax let's test the application :) Below is what your final project directory looks like: │ Now that your application is ready, you need to test the various routes to ensure they are working. To test the routes, rerun your server with Amazing! Now that you have signed up and authenticated a user, the returned token, which shows that the user has been authenticated, can be used to access your todo CRUD APIs. First, let's try accessing your todo routes without the token... As you can see, when you tried to create a task, you got a message Now, let's also try accessing the delete by Id route without the token... Your todo CRUD APIs have been protected, and the only way a user can access them is by getting authenticated. Now let's log in again and use the returned token to access the todo routes. So, you have logged a user in and put the returned Bearer's token in the authorization header. You can access our todo APIs now because, with the bearer's token, you are authorized to access the todo APIs. The code for this tutorial is available here on Github. Feel free to clone and extend the features of the application. Google has prepared a roadmap to restrict third-party cookies in Chrome. Since 04 January 2024, Chrome has rolled out third-party cookie restrictions for 1% of stable clients and 20% of Canary, Dev, and Beta clients. What does it mean for user authentication? On one hand, Google believes third-party cookies are widely used for cross-site tracking, greatly affecting user privacy. Hence, Google wants to phase out (or restrict) supporting third-party cookies in Chrome by early Q2 2025 (subject to regulatory processes). On the other hand, Google introduced Privacy Sandbox to support the use cases (other than cross-site tracking and advertising) previously implemented using third-party cookies. In this article, we’ll discuss: Third-party cookie restrictions affect user authentication in three ways, as follows. If your website or app uses an external Identity Provider (IdP) — like LoginRadius, the IdP sets a third-party cookie when the user authenticates on your app. If you have multiple apps across domains within your organization and authentication is handled using an IdP (internal or external) with web SSO, you already use third-party cookies to facilitate seamless access for each user using a single set of credentials. If you have implemented web SSO with one primary domain and multiple sub-domains of the primary domain, third-party cookie restrictions may not apply. For now, Google doesn’t consider the cookies set by sub-domains as third-party cookies, although this stance may change in the future. For example, you have apps at Federated SSO is similar to, albeit different from, web SSO. It can handle multiple IdPs and applications—aka., Service Providers (SPs)—spanning multiple organizations. It can also implement authentication scenarios that are usually implemented through web SSO. Usually, authentication is handled on a separate pop-up or page when the user wants to authenticate rather than on the application or website a user visits. For example, you already use federated SSO if you facilitate authentication for a set of apps through multiple social identity providers as well as traditional usernames and passwords. Note: It is also possible to store tokens locally, not within cookies. In this case, third-party cookie restrictions won’t affect token-based authentication. However, the restrictions still affect authentication where tokens are stored within third-party cookies (a common and secure method). Google has been developing alternative features and capabilities for Chrome to replace third-party cookies as part of its Privacy Sandbox for Web initiative. Specific to authentication, Google recommends the following: CHIPS are a restricted way of setting third-party cookies on a top-level site without making them accessible on other top-level sites. Thus, they limit cross-site tracking and enable specific cross-site functionalities, such as maps, chat, and payment embeds. For example, a user visits If the user visits You should specifically opt for partitioned cookies (CHIPS), which are set with partitioned and secure cookie attributes. If you’re using an external identity provider for your application, CHIPS is a good option to supplant third-party cookie restrictions. However, CHIPS may not be ideal if you have a web SSO or federated SSO implementation. It creates separate partitioned cookies for each application with a separate domain, which can increase complexity and create compatibility issues. With Storage Access API, you can access the local storage in a third-party context through iframes, similar to when users visit it as a top-level site in a first-party context. That is, it gives access to unpartitioned cookies and storage. Storage Access API requires explicit user approval to grant access, similar to locations, camera, and microphone permissions. If the user denies access, unpartitioned cookies and storage won’t be accessible in a third-party context. It is most suitable when loading cross-site resources and interactions, such as: Verifying user sessions when allowing interactions on an embedded social post or providing personalization for an embedded video.\nEmbedded documents requiring user verification status to be accessible. As it requires explicit user approval, it is advisable to use Storage Access API when you can’t implement an identity use case with the other options. With Related Website Sets, you can declare a Chrome automatically recognizes related website sets declared, accepted, and maintained in this open-source GitHub repository: Related Website Sets It provides access through Storage Access API directly without prompting for user approval, but only after the user interacts with the relevant iframe. It is important to declare a limited number of domains in related website sets that are meaningful and used for specific purposes. Google may block or suspend any exploitative use of this feature. The top-level site can also request approval for specific cross-site resources and scripts to Storage Access API using If you’re using an external identity provider for your web application, you can declare the domain of the identity provider in the related set to ensure limited third-party cookies and storage access to the identity provider, thus ensuring seamless user authentication. Related Website Sets can also work to supplement third-party cookie restrictions in web SSO and federated SSO if the number of web applications (or domains) is limited. FedCM API enables federated SSO without third-party cookies. With FedCM API, a user follows these steps for authentication: You can access a user demo of FedCM here: FedCM. For more information about implementing federated SSO with FedCM API, go through the FedCM developer guide. Firstly, we’re committed to solving our customers' user identity pain points — and preparing for the third-party cookies phase-out is no different. We’ll implement the most relevant and widely useful solutions to facilitate a smooth transition for our customers. Please subscribe to our blog for more information. We’ll update you on how we help with the third-party cookie phase-out. The proposed changes to phase out third-party cookies and suggested alternatives are evolving as Google has been actively collaborating and discussing changes with the border community. Moreover, browsers like Firefox, Safari, and Edge may approach restricting third-party cookies differently than Google does. From LoginRadius, we’ll keep you updated on what we’re doing as a leading Customer Identity and Access Management (CIAM) vendor to prepare for the third-party cookie phase-out. Top-level site: It is the primary site a user has visited. First-party cookie: A cookie set by the top-level site. Third-party cookie: A cookie set by a domain other than the top-level site. For example, let’s assume that a user has visited \n
\nWhitelisting the Domain of Your Application
\nTo access Web Apps in Deployment, follow these steps:
\n\n
\nNow, to add a new site:
\n\n
\nhttps://localhost:8080\").Whitelisting Domain from OIDC Application Configuration
\n\n
\nSetting Up the Provider Object and the OAuthconfig with the Loginradius OIDC App Credentials
\n
\nprovider, err := oidc.NewProvider(ctx, "`https://api.loginradius.com/{oidcappname}")`\nif err != nil {\n // handle error\n}\n\n// Configure an OpenID Connect aware OAuth2 client.\noauth2Config := oauth2.Config{\n ClientID: your-oidc-clientID,\n ClientSecret: your-oidc-clientSecret\n RedirectURL: redirectURL,\n\n // Discovery returns the OAuth2 endpoints.\n Endpoint: provider.Endpoint(),\n\n // "openid" is a required scope for OpenID Connect flows.\n Scopes: []string{oidc.ScopeOpenID, "profile", "email"},\n}https://{siteUrl}/service/oidc/{OidcAppName}go-oidc:\n
\nHandle the Callback Hit
\n
\nvar verifier = provider.Verifier(&oidc.Config{ClientID: clientID})\n\nfunc handleOAuth2Callback(ctx *gin.context) {\n // Verify state and errors.\n authCode := ctx.query("code")\n\n oauth2Token, err := oauth2Config.Exchange(ctx, authCode)\n if err != nil {\n // handle error\n }\n\n // Extract the ID Token from the OAuth2 token.\n rawIDToken, ok := oauth2Token.Extra("id_token").(string)\n if !ok {\n // handle missing token\n }\n\n // Parse and verify ID Token payload.\n idToken, err := verifier.Verify(ctx, rawIDToken)\n if err != nil {\n // handle error\n }\n\n // Extract custom claims\n var claims struct {\n Email string `json:"email"`\n Verified bool `json:"email_verified"`\n }\n if err := idToken.Claims(&claims); err != nil {\n // handle error\n }\n}Gin Golang Code
\ngo-oidc library, you can efficiently implement OIDC authentication in the Go backend, guaranteeing users a smooth and secure authentication process.
\ngo get github.com/coreos/go-oidc/v3/oidc
\npackage main\n\nimport (\n\t"encoding/json"\n\t"fmt"\n\t"io"\n\t"log"\n\t"net/http"\n\t"os"\n\n\t"github.com/coreos/go-oidc/v3/oidc"\n\t"github.com/gin-gonic/gin"\n\t"golang.org/x/oauth2"\n)\n\n// Define global OAuth2 configuration and OIDC provider.\nvar (\n\toauthConfig = &oauth2.Config{\n\t\tClientID: "your-client-id", // Replace with your LoginRadius Client ID\n\t\tRedirectURL: "http://localhost:8080/api/callback",\n\t\tClientSecret: "your-client-secret", // Replace with your LoginRadius Client Secret\n\t\tScopes: []string{"user"},\n\t}\n\tglobalProvider *oidc.Provider\n\tglobalOuthConfig *oauth2.Config\n)\n\n// Server struct holds interfaces like HTTP server, DBHelper, ServerProvider, MongoDB client, etc.\ntype Server struct {\n\n}\n\n// InitializeOAuthConfig sets up the global OAuth2 configuration and OIDC provider.\nfunc InitializeOAuthConfig() {\n\t// Create a new OIDC provider using the OAuth2 endpoint and OIDC provider URL.\n\tprovider, err := oidc.NewProvider(context.Background(), "https://<siteUrl>/service/oidc/<OidcAppName>") // Replace with your OIDC Provider URL\n\tif err!= nil {\n\t\tlog.Fatalf("Failed to create new provider: %v", err)\n\t}\n\tglobalProvider = provider\n\n\t// Set up the OAuth2 configuration with the client ID, secret, redirect URL, and scopes.\n\toauth2Config := &oauth2.Config{\n\t\tClientID: oauthConfig.ClientID,\n\t\tClientSecret: oauthConfig.ClientSecret,\n\t\tRedirectURL: oauthConfig.RedirectURL,\n\t\tEndpoint: provider.Endpoint(),\n\t\tScopes: []string{oidc.ScopeOpenID, "profile", "email"},\n\t}\n\tglobalOuthConfig = oauth2Config\n}\n\n// StartLoginProcess initiates the login process by redirecting the user to the OIDC provider.\nfunc StartLoginProcess(ctx *gin.Context) {\n\t// Generate the authorization URL for the OIDC provider.\n\tauthURL := globalOuthConfig.AuthCodeURL("state", oidc.Nonce(""))\n\t// Redirect the user to the OIDC provider for authentication.\n\thttp.Redirect(ctx.Writer, ctx.Request, authURL, http.StatusFound)\n}\n\n// HandleCallback processes the callback from the OIDC provider after the user has authenticated.\nfunc HandleCallback(ctx *gin.Context) {\n\t// Retrieve the authorization code from the query parameters.\n\tcode := ctx.Query("code")\n\n\t// Exchange the authorization code for an access token.\n\toauth2Token, err := globalOuthConfig.Exchange(ctx, code)\n\tif err!= nil {\n\t\tlog.Printf("Error exchanging code for token: %v", err)\n\t\treturn\n\t}\n\n\t// Extract the ID token from the OAuth2 token.\n\trawIDToken, ok := oauth2Token.Extra("id_token").(string)\n\tif!ok {\n\t\tlog.Println("Missing ID token")\n\t\treturn\n\t}\n\n\t// Verify the ID token using the OIDC provider.\n\tvar verifier = globalProvider.Verifier(&oidc.Config{ClientID: globalOuthConfig.ClientID, SkipClientIDCheck: true})\n\n\tidToken, err := verifier.Verify(ctx, rawIDToken)\n\tif err!= nil {\n\t\tlog.Printf("Error verifying ID token: %v", err)\n\t\treturn\n\t}\n\n\t// Extract claims from the verified ID token.\n\tvar claims interface{}\n\tif err := idToken.Claims(&claims); err!= nil {\n\t\tlog.Printf("Error extracting claims: %v", err)\n\t\treturn\n\t}\n\n\t// Respond with a success message.\n\tctx.JSON(http.StatusOK, gin.H{"message": "success"})\n}\n\n// InjectRoutes sets up the routes for the application, including login and callback endpoints.\nfunc (srv *Server) InjectRoutes() *gin.Engine {\n\trouter := gin.Default()\n\n\tapi := router.Group("/api")\n\t{\n\t\t// Define the login route that redirects users to the OIDC provider for authentication.\n\t\tapi.GET("/login", StartLoginProcess)\n\t\t// Define the callback route that handles the callback from the OIDC provider.\n\t\tapi.GET("/callback", HandleCallback)\n\t}\n\n\treturn router\n}\n\nfunc main() {\n\t// Initialize the OAuth2 configuration and OIDC provider.\n\tInitializeOAuthConfig()\n\t// Create a new server instance.\n\tserver := &Server{}\n\t// Inject routes into the Gin engine.\n\trouter := server.InjectRoutes()\n\t// Start the HTTP server.\n\tlog.Fatal(http.ListenAndServe(":8080", router))\n}Initialization of OIDC Provider and OAuth2 Configuration
\n\n
\noidc.NewProvider function, which requires the OAuth2 endpoint and the OIDC provider's URL. This step is crucial for establishing a connection with the OIDC provider, enabling the application to authenticate users through the provider.oauthConfig) is set up with essential details such as the client ID, client secret, redirect URL, and scopes. These credentials are specific to the OIDC application registered with the provider (e.g., LoginRadius). The redirect URL is where the provider will send the user after authentication, and the scopes define the permissions requested from the user.Setting Up the Callback Endpoint
\n\n
\n/api/callback. This endpoint handles the callback from the OIDC provider after the user has been authenticated.Verifying the Access Token and Extracting User Claims
\n\n
\nConclusion
\nBasic Terminology
\n\n
\n\n
\nAPI Implementation for Brute-force Lockout
\nCreating a Basic Application
\n\n
\n\n
\n<app-name>.hub.loginradius.com/auth.aspx in the implement section of the Identity Experience Framework or from the preview section.Brute-force Lockout
\nEnabling
\n\n
\n\n
\nLockout Types in LoginRadius
\n\n
\n\n
\n\n
\nUnlocking an Account Locked through Brute-force Lockout
\n\n
\n\n
\nAccount Update API from the LoginRadius Account API Collection
\n\n
\nhttps://api.loginradius.com/identity/v2/manage/account/{uid}
\n{\n ...\n "FirstName": "Test",\n "MiddleName": null,\n ...\n}\n
\n
\n{\n ...\n "LoginLockedType": "None",\n "Email": [\n {\n "Type": "Primary",\n "Value": "user1@yopmail.com"\n }\n ],\n ...\n}
\nConclusion
\n\n
\nMiscellaneous
\nCAPTCHA
\n\n
\nMulti-Factor Authentication (MFA):
\n\n
\nChallenges with Cache Updates
\nMigrating to AWS ElastiCache for Redis
\nConclusion
\nIntroduction
\nThe Idea Behind LoginRadius CLI
\n\n
\nIntroduction
\nPrerequisites
\n\n
\nWhat is Deno?
\nWhy Use Deno?
\n\n
\nWhat is JSON Web Token?
\nInstall Deno
\n
\niwr https://deno.land/x/install/install.ps1 -useb | iexdeno -VProject Setup
\nDenoAPI_JWT_Auth; you can call it any name you choose. Create an app.ts file and a folder src in your folder.src folder, create the following folders: controllers, database, middlewares, routes, schema, and utils.DenoAPI_JWT_Auth
\n│ └───controllers
\n│ │\n│ └───database
\n│ │\n│ └───middlewares
\n│ │\n│ └───routes
\n│ │\n│ └───schema
\n│ │\n│ └───utils
\n└─app.ts Create Oak Server
\napp.ts, import Application from the Deno Oak URL, create an instance of the application, define your port, and call a middleware, as follows.app.ts
\nimport { Application } from "https://deno.land/x/oak/mod.ts";\n\nconst app = new Application();\nconst PORT = 8080;\n\n app.use((ctx, next) => {\n ctx.response.body = 'Welcome';\n next();\n });\n\nconsole.log(`Application is listening on port: ${PORT}`);\n\nawait app.listen({port:PORT});deno run --allow-net app.ts --allow-net gives Deno permission to all network calls.Application is listening on port: 8080routes folder, create a file called allRoutes.ts, and set up your router by importing Router from the oak URL, then create an instance of the router and export the default router.routes.allRoutes.ts
\nimport { Router } from "https://deno.land/x/oak/mod.ts";\n\nconst router = new Router();\n\nexport default router;app.ts. So, go to app.ts and import the router. Let the app use router.routes() and router.allowedMethods() methods, then remove the middleware, so it doesn't overshadow the imported routes. The allowedMethods() tells Deno to include all routes by your router.app.ts
\nimport { Application } from "https://deno.land/x/oak/mod.ts";\nimport router from "./src/routes/allRoutes.ts";\n\nconst app = new Application();\nconst PORT = 8080;\n\napp.use(router.routes());\napp.use(router.allowedMethods());\n\nconsole.log(`Application is listening on port: ${PORT}`);\n\nawait app.listen({port:PORT});deno run --allow-net app.tsCreate User Data
\n\n
\ndatabase folderconnectBD.tsdatabase.connectDB.ts
\nimport { MongoClient } from "https://deno.land/x/mongo@v0.30.0/mod.ts";\n\n // Connecting to a Mongo Database\n const client = new MongoClient();\n \n const dbString = "DB_String"\n\n await client.connect(dbString)\n \n console.log("Database connected!");\n \n const db = client.database("deno_auth");\n\n export default db;\n schema folder, create a file user.ts, import objectId from deno MongoDB URL, then define and export your schema.schema.user.ts
\nimport {ObjectId} from "https://deno.land/x/mongo@v0.30.0/mod.ts";\n\nexport interface UserSchema {\n _id: ObjectId;\n username: string;\n password: string;\n }controllers folder, and create a file called users.ts. In the file, import your database and UserSchema.signup that takes username and password. Take the user details from the request body, hash the password, and save them to your database.controllers.users.ts
\nimport db from "../database/connectBD.ts";\nimport * as bcrypt from "https://deno.land/x/bcrypt/mod.ts";\nimport { UserSchema } from "../schema/user.ts";\n\nconst Users = db.collection<UserSchema>("users");\n\nexport const signup = async({request, response}:{request:any;response:any}) => {\n const {username, password} = await request.body().value;\n const salt = await bcrypt.genSalt(8);\n const hashedPassword = await bcrypt.hash(password, salt);\n\n const _id = await Users.insertOne({\n username,\n password:hashedPassword\n });\n response.status =201;\n response.body = {message: "User created", userId:_id, user:username}\n \n};allRoutes.ts in your routes folder, import the signup function from the controller, and create a POST route for signup, as follows.routes.allRoutes.ts
\nimport { Router } from "https://deno.land/x/oak/mod.ts";\nimport {signup} from "../controllers/users.ts";\n\nconst router = new Router();\n\n//User routes\nrouter.post("/api/signup", signup)\n\nexport default router;Create Authenticate User route
\ngeneratekey() method of the SubtleCrypto interface.utils folder, create a file called apiKey.ts, and in the file, generate your key and export it, as follows.utils.apiKey.ts
\nexport const key = await crypto.subtle.generateKey(\n { name: "HMAC", hash: "SHA-512" },\n true,\n ["sign", "verify"],\n );user.ts in your controller, import the API key, create a signin function, and write some validation logic to validate that the user exists in your database. If validation is successful, you create a token to authenticate the user. Using JWT to Authenticate a User
\ncreate function from the URL to create a token. When a user logs in, take the id and username, pass the payload into the JWT create function, generate a token, and use the token to authenticate the user.controllers.users.ts
\nimport db from "../database/connectDB.ts";\nimport * as bcrypt from "https://deno.land/x/bcrypt/mod.ts";\nimport { UserSchema } from "../schema/user.ts";\nimport { create } from "https://deno.land/x/djwt@v2.4/mod.ts";\nimport { key } from "../utils/apiKey.ts";\n\nconst Users = db.collection<UserSchema>("users");\n\n //create a user\n export const signup = async({request, response}:{request:any;response:any}) => {\n const {username, password} = await request.body().value;\n const salt = await bcrypt.genSalt(8);\n const hashedPassword = await bcrypt.hash(password, salt);\n\n const _id = await Users.insertOne({\n username,\n password:hashedPassword\n });\n response.status =201;\n response.body = {message: "User created", userId:_id, user:username} \n};\n\n //sign in a user\n export const signin = async ({request, response}:{request:any; response:any}) => {\n\n const body = await request.body();\n const {username, password} = await body.value;\n\n const user = await Users.findOne({username});\n\n if(!user) {\n response.body = 404;\n response.body = {message: `user "${username}" not found`};\n return;\n }\n const confirmPassword = await bcrypt.compare(password, user.password);\n if(!confirmPassword){\n response.body = 404;\n response.body = {message: "Incorrect password"};\n return;\n }\n \n //authenticate a user\n const payload = {\n id: user._id,\n name: username\n };\n const jwt = await create({ alg: "HS512", typ: "JWT" }, { payload }, key);\n\n if(jwt) {\n response.status = 200;\n response.body = {\n userId: user._id,\n username: user.username,\n token: jwt,\n }\n } else {\n response.status = 500;\n response.body = {\n message: "internal server error"\n }\n }\n return;\n }signin function in the routes and create a post request for it, as follows.routes.allRoutes.ts
\nimport { Router } from "https://deno.land/x/oak/mod.ts";\nimport {signup, signin} from "../controllers/users.ts";\n\nconst router = new Router();\n\n//User routes\nrouter.post("/api/signup", signup)\n .post("/api/signin", signin);\n \n\nexport default router;schema folder, and create a file task.ts. In the file, create your tasks interface and export it.Create Todo Route
\nschema.task.ts
\nexport interface TaskSchema {\n name: string;\n isCompleted: boolean;\n } tasks.ts, and import the database, schema, and object Id. Then write the logic for our todo CRUD API.controllers.tasks.ts
\nimport db from "../database/connectDB.ts";\nimport { TaskSchema } from "../schema/task.ts";\nimport {ObjectId} from "https://deno.land/x/mongo@v0.30.0/mod.ts";\n\nconst tasks = db.collection<TaskSchema>("tasks");\n\nexport const create = async({request, response}:{request:any;response:any}) => {\n const {name, isCompleted} = await request.body().value;\n\n const _id = await tasks.insertOne({\n name,\n isCompleted\n });\n response.body = {message: "Task created!!", id:_id, name:name, Completed:isCompleted}\n };\n\n export const getTasks = async ({response}:{response:any}) => {\n const allTasks = await tasks.find({}).toArray();\n\n response.status = 200;\n response.body = {tasks:allTasks};\n };\n\n export const getById = async ({\n params,\n response\n }:{\n params:{taskId:string};\n response:any;\n }) => {\n const taskId = params.taskId;\n const task = await tasks.findOne({_id:new ObjectId(taskId)});\n\n if(!task){\n response.body = {message: `no task with Id: ${taskId}`};\n return;\n}\n response.status = 200;\n response.body = {task: task}\n};\n\nexport const updateById = async ({\n params,\n request,\n response\n}:{\n params:{taskId:string};\n request:any;\n response:any;\n}) => {\n const taskId = params.taskId;\n const {name, isCompleted} = await request.body().value;\n const task = await tasks.updateOne({_id:new ObjectId(taskId)},\n {$set:{name:name, isCompleted:isCompleted}});\n\n response.status = 200;\n response.body = {message:"Updated task", task:task};\n};\n\nexport const deleteTask = async ({\n params,\n response,\n}:{\n params:{taskId:string};\n response:any;\n}) => {\n const taskId = params.taskId;\n const task = await tasks.deleteOne({_id:new ObjectId(taskId)});\n response.status = 200;\n response.body = {message:"Deleted task", task:task};\n};allRoutes.ts and import the CRUD functions from the task controllers, then create the routes for our todo, as follows.routes.allRoutes.ts
\nimport { Router } from "https://deno.land/x/oak/mod.ts";\nimport {signup, signin} from "../controllers/users.ts";\nimport {create, getTasks, getById, updateById, deleteTask} from "../controllers/tasks.ts";\n\nconst router = new Router();\n\n//User routes\nrouter.post("/api/signup", signup)\n .post("/api/signin", signin);\n\n//Task routes\nrouter.post("/api/tasks", create)\n .get("/api/tasks", getTasks)\n .get("/api/tasks/:taskId", getById)\n .patch("/api/tasks/:taskId", updateById)\n .delete("/api/tasks/:taskId", deleteTask);\n\nexport default router;Protect Todo Routes
\nmiddlewares folder: create a file called isAuthorized.ts, import the verify function from deno JWT URL, import Context from deno, import the secret key you've created, and create the authorized function.middlewares.isAuthorized.ts
\nimport { verify } from "https://deno.land/x/djwt@v2.4/mod.ts";\nimport { key } from "../utils/apiKey.ts";\nimport { Context } from "https://deno.land/x/oak/mod.ts";\n\nexport const authourized = async (ctx: Context, next:any) => {\n try{ \n const headers: Headers = ctx.request.headers;\n const authorization = headers.get('Authorization');\n if(!authorization) {\n ctx.response.status = 401;\n return;\n }\n const jwt = authorization.split(' ')[1];\n\n if(!jwt) {\n ctx.response.status = 401;\n return;\n }\n const payload = await verify(jwt, key);\n\n if(!payload){\n throw new Error("!payload")\n }\n await next();\n \n } catch (error) {\n ctx.response.status = 401;\n ctx.response.body ={message: "You are not authorized to access this route"}\n return;\n }\n};isAuthorized.ts middleware file and pass the middleware into the todo routes to protect them from unauthorized people.routes.allRoutes.ts
\nimport { Router } from "https://deno.land/x/oak/mod.ts";\nimport {signup, signin} from "../controllers/users.ts";\nimport {create, getTasks, getById, updateById, deleteTask} from "../controllers/tasks.ts";\nimport { authourized } from "../middlewares/isAuthorized.ts";\n\nconst router = new Router();\n\n//User routes\nrouter.post("/api/signup", signup)\n .post("/api/signin", signin);\n\n//Task routes\nrouter.post("/api/tasks", authourized, create)\n .get("/api/tasks", authourized, getTasks)\n .get("/api/tasks/:taskId", authourized, getById)\n .patch("/api/tasks/:taskId", authourized, updateById)\n .delete("/api/tasks/:taskId", authourized, deleteTask);\n\nexport default router;DenoAPI_JWT_Auth
\n└─src
\n│ └───controllers
\n│ │ └───users.ts
\n│ │ └───tasks.ts
\n│ │\n│ └───database
\n│ │ └───connectDB.ts
\n│ │
\n│ └───middlewares
\n│ │ └───isAuthorized.ts
\n│ │
\n│ └───routes
\n│ │ └───allRoutes.ts
\n│ │\n│ └───schema
\n│ │ └───user.ts
\n│ │ └───task.ts
\n│ │\n│ └───utils
\n│ │ └───apiKey.ts
\n│ │
\n└─app.ts Test Application
\ndeno run --allow-net app.ts.Sign-in Route
\nAccessing the Todo Routes
\nCreate Task Route
\nYou are not authorized to access this route because a random person did it without a token.Delete Task Route
\nCreate Task Route
\nGet All Tasks Route
\nGet Task By Id Route
\n\n
\nHow is User Authentication Affected?
\nExternal Identity Providers
\nWeb SSO
\nexample.com, travel.example.com, stay.example.com, and web SSO is handled by auth.example.com. In this case, third-party cookie restrictions don’t apply.Federated SSO
\n\n
\nChrome’s Alternatives for Third-Party Cookies
\n\n
\nCookies Having Independent Partitioned State (CHIPS)
\na.com with a map embed from map-example.com, which can set a partitioned cookie that is only accessible on a.com. b.com with a map embed from map-example.com, it cannot access the partitioned cookie set on a.com. It has to create a separate partitioned cookie specific to b.com, thus blocking cross-site tracking yet allowing limited cross-site functionality.Storage Access API
\nRelated Website Sets
\nprimary website and associatedSites for limited purposes to grant third-party cookie access and local storage for a limited number of sites.resuestStorageAccessFor() API.Federated Credential Management (FedCM) API
\n\n
\nHow is LoginRadius Preparing for the Third-party Cookie Phase-out?
\nIn Conclusion
\nGlossary
\na.com, which might use an embed from loginradius.com to facilitate authentication. If loginradius.com sets a cookie when the user visits a.com, it is called a third-party cookie as the user hasn’t directly visited loginradius.com.References
\n\n","frontmatter":{"date":"July 08, 2024","updated_date":null,"description":"Google Chrome has planned to phase out third-party cookies, which will affect different website functionalities depending on third-party cookies. This blog focuses on how this phase-out affects identity and user authentication and discusses alternatives for overcoming challenges.","title":"How Chrome’s Third-Party Cookie Restrictions Affect User Authentication?","tags":["Identity","Cookies","Chrome"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/eb7396060c0adc430dbed2d04b63d431/ee604/third-party-cookies-phaseout-chrome.png","srcSet":"/static/eb7396060c0adc430dbed2d04b63d431/69585/third-party-cookies-phaseout-chrome.png 200w,\n/static/eb7396060c0adc430dbed2d04b63d431/497c6/third-party-cookies-phaseout-chrome.png 400w,\n/static/eb7396060c0adc430dbed2d04b63d431/ee604/third-party-cookies-phaseout-chrome.png 800w,\n/static/eb7396060c0adc430dbed2d04b63d431/f3583/third-party-cookies-phaseout-chrome.png 1200w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Raghunath Reddy","github":"raghunath-r-a","avatar":null}}}},"pageContext":{"limit":6,"skip":0,"currentPage":1,"type":"//engineering//","numPages":52,"pinned":"17fa0d7b-34c8-51c4-b047-df5e2bbaeedb"}},"staticQueryHashes":["1171199041","1384082988","2100481360","23180105","528864852"]}