+## Authentication Steps
+
+:::caution
+
+This is only supported by the **NodeJS** SDK.
+
+:::
+
+This flow uses common **OAuth2** terminology. If you want a short explanation on how **OAuth2** works and its concepts, please check out [this page](/docs/unified-login/introduction#oauth2-basics).
+
+
+
+
+In the **Client Credentials Flow** the authentication sequence will work in the following way:
+
+1. `Service A` uses credentials to get an **OAuth2 Access Token**
+2. [**Authorization Service**](/docs/unified-login/introduction#authorization-service) returns the **OAuth2 Access Token**
+3. `Service A` uses the **OAuth2 Access Token** to communicate with `Service B`
+4. `Service B` validates the **OAuth2 Access Token**
+5. If the token is valid `Service B` returns the requested resource
+
+Check our [**extensive guide**](/docs/microservice_auth/client-credentials) that will show you how to setup the **Authorization Service** and how to complete all the steps using **SuperTokens**.
-In the next sections, we will be showing you how to create and verify a JWT using SuperTokens.
\ No newline at end of file
diff --git a/v2/microservice_auth/jwt-creation.mdx b/v2/microservice_auth/jwt-creation.mdx
index 3c8b1468e..17df93788 100644
--- a/v2/microservice_auth/jwt-creation.mdx
+++ b/v2/microservice_auth/jwt-creation.mdx
@@ -4,267 +4,6 @@ title: Creating a JWT
hide_title: true
---
-import WithWithoutSDK from "/src/components/tabs/WithWithoutSDK";
-import BackendSDKTabs from "/src/components/tabs/BackendSDKTabs";
-import TabItem from '@theme/TabItem';
-import PythonSyncAsyncSubTabs from "/src/components/tabs/PythonSyncAsyncSubTabs"
+import Redirector from '/src/components/Redirector';
-# Creating a JWT
-
-## When to create a JWT?
-The first step is to create a JWT from the microservice that will be sending the request (let's call this microservice `M1`). This JWT will be verified by other microservices when `M1` sends them a request. Since this JWT remains static per microservice, the best time to create this is on process starts - i.e. when `M1` starts.
-
-## What to add in the JWT?
-The JWT can contain any information you like, but at a minimum, it needs to contain information proving that it is a microservice that is allowed to query other microservices in your infrastructure. This is needed since you may issue a JWT to an end user as well, and they should not be able to query any microservice directly.
-
-We can add the following claim in the JWT to "mark" the JWT as one that is meant for microservice auth only:
-```json
-{..., "source": "microservice", ...}
-```
-
-In the receiving microservice (`M2`), we can then [verify the JWT](./jwt-verification/index) and check that this claim is present before serving the request.
-
-
-## Code for creating a JWT
-
-
+
+The authentication sequene will work in the following way:
+
+1. Microservice `M1` requests a JWT (JSON Web Token) from the **SuperTokens Core**
+2. Microservice `M1` sends the JWT to `M2`
+3. Microservice `M2` will verifies the JWT and completes the action if the JWT is valid
+
+
+## Creating a JWT
+
+### When to create a JWT?
+The first step is to create a JWT from the microservice that will be sending the request (let's call this microservice `M1`). This JWT will be verified by other microservices when `M1` sends them a request. Since this JWT remains static per microservice, the best time to create this is on process starts - i.e. when `M1` starts.
+
+### What to add in the JWT?
+The JWT can contain any information you like, but at a minimum, it needs to contain information proving that it is a microservice that is allowed to query other microservices in your infrastructure. This is needed since you may issue a JWT to an end user as well, and they should not be able to query any microservice directly.
+
+We can add the following claim in the JWT to "mark" the JWT as one that is meant for microservice auth only:
+```json
+{..., "source": "microservice", ...}
+```
+
+In the receiving microservice (`M2`), we can then [verify the JWT](./jwt-verification/index) and check that this claim is present before serving the request.
+
+
+### Code for creating a JWT
+
+
+
+This flow is best suited for scenarios that involve **web applications**.
+It consists of the following steps:
+1. The **Client** redirects the **Resource Owner** to the **Authorization Server’s** authorization endpoint.
+2. If the **Resource Owner** grants permission, the **Authorization Server** redirects their browser back to the specified **Redirect URI** and includes an **Authorization Code** as a query parameter.
+3. The **Client** then sends a request to the **Authorization Server**’s token endpoint, including the **Authorization Code**.
+4. The **Authorization Server** verifies the information sent by the **Client** and, if valid, issues an **OAuth2 Access Token**.
+5. The token can now be used to make requests to the **Resource Server** to access the protected resources on behalf of the **Resource Owner**.
+
+##### Authorization Code
+
+An **Authorization Code** is a short-lived code that the [**Authorization Server**](/#authorization-server) provides to the [**Client**](/#client), via a **Redirect URI**, after authorization has been granted.
+This code then gets exchanged for an [**OAuth2 Access Token**](/#oauth2-access-token).
+The **Authorization Code** flow enhances security by keeping tokens out of the user-agent and letting the [**Client**](/#client) manage the backend communication with the [**Authorization Server**](/#authorization-server).
+
+##### Proof Key for Code Exchange (PKCE)
+
+In order to prevent CSRF and code injection attacks, the **Authorization Code flow** can be enhanced with [**PKCE**](https://oauth.net/2/pkce/).
+
+At the beginning of the authentication flow the **Client** will generate a random string called a *code verifier*.
+This gets used to ensure that, even if the **Authorization Code** is intercepted, it cannot be exchanged for a token without also including the initial code.
+
+
+#### [Client Credentials](https://oauth.net/2/grant-types/client-credentials/)
+
+
+
+This flow is best suited for **machine-to-machine** (M2M) interactions where there is no end-user.
+It consists of the following steps:
+1. The **Client** authenticates with the **Authorization Server** using its own credentials.
+2. The **Authorization Server** verifies the credentials.
+3. The **Authorization Server** returns an **OAuth2 Access Token**.
+4. The **Client** uses the **OAuth2 Access Token** to access protected resources.
+5. The **Resource Server** validates the **OAuth2 Access Token**.
+6. If the validation is successful, the **Resource Server** returns the requested resources.
+
+
+
+
+
diff --git a/v2/unified-login/multiple-frontends-with-a-single-backend.mdx b/v2/unified-login/multiple-frontends-with-a-single-backend.mdx
new file mode 100644
index 000000000..1ad0698bd
--- /dev/null
+++ b/v2/unified-login/multiple-frontends-with-a-single-backend.mdx
@@ -0,0 +1,892 @@
+---
+title: Multiple frontend domains with a common backend
+hide_title: true
+---
+
+
+import NodeJSFrameworkSubTabsServerless from "/src/components/tabs/NodeJSFrameworkSubTabsServerless"
+import FrontendPreBuiltUITabs from "/src/components/tabs/FrontendPreBuiltUITabs"
+import FrontendCustomUITabs from "/src/components/tabs/FrontendCustomUITabs"
+import NpmOrScriptTabs from "/src/components/tabs/NpmOrScriptTabs"
+import FrontendMobileSubTabs from "/src/components/tabs/FrontendMobileSubTabs"
+import BackendSDKTabs from "/src/components/tabs/BackendSDKTabs"
+import {Question, Answer}from "/src/components/question"
+import OAuthFrontendTabs from "/src/components/tabs/OAuthFrontendTabs"
+import OAuthBackendTabs from "/src/components/tabs/OAuthBackendTabs"
+import CoreInjector from "/src/components/coreInjector"
+import AppInfoForm from "/src/components/appInfoForm"
+import TabItem from '@theme/TabItem';
+import OAuthPaidBanner from '../community/reusableMD/oauth-paid-banner.mdx'
+
+
+
+
+The authentication flow will work in the following way:
+
+1. The User accesses the `frontend` app
+ - The application `frontend` redirects the user to [**Authorization Service**](/docs/unified-login/introduction#authorization-service) authorize URL.
+ - The [**Authorization Service**](/docs/unified-login/introduction#authorization-service) backend redirects the user to the login UI
+2. The User completes the login attempt
+ - The [**Authorization Service**](/docs/unified-login/introduction#authorization-service) backend redirects the user to the `callback URL`.
+3. The User accesses the callback URL
+ - The `frontend` uses the callback URL information to obtain a **OAuth2 Access Token** from the [**Authorization Service**](/docs/unified-login/introduction#authorization-service).
+
+:::info
+This guide assumes that you already have setup and configured **SuperTokens** in your [**Authorization Service**](/docs/unified-login/introduction#authorization-service).
+
+For more information on how to do that please check our [quickstart guide](/docs/thirdparty/introduction).
+:::
+
+
+
+
+
+## 1. Enable the OAuth2 features from the Dashboard
+
+You will first have to enable the **OAuth2** features from the **SuperTokens.com Dashboard**.
+1. Open the **SuperTokens.com Dashboard**
+2. Click on the **Enabled Paid Features** button
+3. Click on **Managed Service**
+4. Check the **OAuth 2.0** option
+5. Click *Save*
+
+Now you should be able to use the OAuth2 recipes in your applications.
+
+
+
+## 2. Create the OAuth2 Clients
+
+
+
+The authentication flow will work in the following way:
+
+1. The User accesses the `frontend` app
+ - The application `frontend` calls a login endpoint on the `backend` application.
+ - The `backend` application generates an `authorization` URL to the [**Authorization Service**](/docs/unified-login/introduction#authorization-service) and redirects the user to it.
+ - The [**Authorization Service**](/docs/unified-login/introduction#authorization-service) backend redirects the user to the login UI
+2. The User completes the login attempt
+ - The [**Authorization Service**](/docs/unified-login/introduction#authorization-service) backend redirects the user to a `callback URL` that includes the **Authorization Code**.
+3. The User accesses the callback URL
+ - The **Authentication Code** gets sent to the application `backend`
+ - The `backend` exchanges the **Authentication Code** for an [**OAuth2 Access Token**](/docs/unified-login/introduction#oauth2-access-token)
+ - The `backend` saves the received token in a server session and sends it back to the `frontend` as a cookie.
+
+The `frontend` can now use the new cookie to access protected resources from the `backend`.
+
+:::info
+This guide assumes that you already have setup and configured **SuperTokens** in your [**Authorization Service**](/docs/unified-login/introduction#authorization-service).
+
+For more information on how to do that please check our [quickstart guides](/docs/guides).
+
+:::
+
+
+
+
+
+## 1. Enable the OAuth2 features from the Dashboard
+
+You will first have to enable the **OAuth2** features from the **SuperTokens.com Dashboard**.
+1. Open the **SuperTokens.com Dashboard**
+2. Click on the **Enabled Paid Features** button
+3. Click on **Managed Service**
+4. Check the **OAuth 2.0** option
+5. Click *Save*
+
+Now you should be able to use the OAuth2 recipes in your applications.
+
+
+
+## 2. Create the OAuth2 Clients
+
+
+
+The authentication flow will work in the following way:
+
+1. User accesses the native application
+2. The user gets redirected to [**Authorization Service**](/docs/unified-login/introduction#authorization-service) authentication url.
+3. The [**Authorization Service**](/docs/unified-login/introduction#authorization-service) redirects the user to the login UI
+4. User completes the login attempt
+5. The [**Authorization Service**](/docs/unified-login/introduction#authorization-service) backend redirects the user to the `callback URL`.
+This URL should be a deep link that can be opened by your actual application.
+6. The application uses the callback URL information to request a **OAuth2 Access Token** from the [**Authorization Service**](/docs/unified-login/introduction#authorization-service).
+7. The returned token is saved by the application.
+
+:::info
+This guide assumes that you already have setup and configured **SuperTokens** in your [**Authentication Service**](/docs/unified-login/introduction#authentication-service).
+
+For more information on how to do that please check our [quickstart guides](/docs/guides).
+:::
+
+
+
+
+
+## 1. Enable the OAuth2 features from the Dashboard
+
+You will first have to enable the **OAuth2** features from the **SuperTokens.com Dashboard**.
+1. Open the **SuperTokens.com Dashboard**
+2. Click on the **Enabled Paid Features** button
+3. Click on **Managed Service**
+4. Check the **OAuth 2.0** option
+5. Click *Save*
+
+Now you should be able to use the OAuth2 recipes in your applications.
+
+
+
+
+## 2. Create the OAuth2 Clients
+
+