update copy around account linking (#2148)

Author: alexisintech

docs/authentication/social-connections/account-linking.mdx

@@ -1,41 +1,39 @@
 ---
-title: Account Linking
-description: Learn how Clerk handles account linking and manages unverified email addresses from social providers.
+title: Account linking for OAuth
+description: Learn how Clerk handles account linking and manages unverified email addresses from OAuth providers.
 ---
 
-Account Linking is a process used by Clerk to ensure a smooth sign-in and sign-up experience using both OAuth and other methods (e.g. username/password). By using the "email address" as the common identifier, Clerk aims to merge accounts whenever possible. This mechanism is triggered when a social provider returns an email address that matches an existing account, assuming a single owner for each email address.
+Account linking is the process of connecting multiple user accounts from different services or platforms, allowing users to access various services with a single set of credentials. By using the email address as the common identifier, Clerk automatically attempts to link accounts whenever possible. Account linking is triggered when an OAuth provider returns an email address that matches an existing account, assuming a single owner for each email address.
 
 ## How it works
 
-When a user attempts to sign in or sign up, Clerk first checks the email address provided. If that email address comes from a social provider such as Google or Facebook, Clerk's behavior varies. It considers two main factors: the verification status of the email address, and whether an account with that email address already exists in Clerk's system. Based on these factors, Clerk will attempt to link the OAuth account with any existing Clerk account that shares the same email address.
+When a user attempts to sign in or sign up, Clerk first checks the provided email address. Clerk will attempt to link the OAuth account with any existing Clerk account that shares the same email address.
 
 In the following sections, we'll look at the different scenarios that can occur during this process and explain how Clerk handles each one.
 
 ![Flow chart of the account linking process in various scenarios](/docs/images/authentication/account-linking-flow-oauth.webp)
 
 ### Email address is verified in both OAuth and Clerk
 
-In this scenario, when a user with a verified email address signs in using a social provider that returns a matching verified email address, Clerk links the OAuth account to the existing account and signs the user in. This even applies to password-protected accounts, as the OAuth sign-in process automatically bypasses password verification.
+When a user signs in to your app using an OAuth provider that returns a **verified** email address, Clerk links the OAuth account to the existing account and signs the user in. This even applies to password-protected accounts, as the OAuth sign-in process automatically bypasses password verification.
 
 ### Email address is verified in Clerk but not in OAuth
 
-In this scenario, when a user with a verified email address at Clerk signs in using a social provider that returns a matching but unverified email address, Clerk will initiate a verification process. Once the email address is verified, the OAuth account is linked to the existing one, and the user is signed in.
+When a user signs in to your app using an OAuth provider that returns an **unverified** email address, Clerk will initiate a verification process. Once the email address is verified, the OAuth account is linked to the existing one, and the user is signed in.
 
-### Email address is not verified in Clerk and not in OAuth
+### Email address is unverified in Clerk
 
-For instances that allow account creation without email verification at sign-up, there is a possibility that an account may be created using an unverified email address, either through OAuth or other methods like username/password.
+By default, users are required to verify their email addresses before they can sign up.
 
-To allow unverified email addresses for your instance, navigate to the [**Email, phone, username**](https://dashboard.clerk.com/last-active?path=user-authentication/email-phone-username) page in the Clerk Dashboard. Select the settings icon next to "Email address" and uncheck the "Verify at sign-up" toggle.
+If you disabled the **Verify at sign-up** option in the [Clerk Dashboard](https://dashboard.clerk.com/last-active?path=user-authentication/email-phone-username), users will be able to sign up without verifying their email addresses.
 
-![Verify at sign-up toggle in the Clerk Dashboard](/docs/images/authentication/account-linking-verify-at-sign-up.webp)
-
-Clerk initiates the email verification process at the outset. Upon successful email verification, regardless of the method, additional steps may be taken to validate existing connections or passwords. This is done to ensure the user's account remains secure.
+When a user signs up with an **unverified** email address and later attempts to sign in with an OAuth provider, Clerk implements security measures to prevent potential account takeovers. For example, if an account was created with an unverified email/password combination and the user later signs in with Google (where the email is verified), Clerk will prompt the user to change their password before linking the accounts. This process begins with email verification, regardless of the method used. After successful verification, Clerk may require additional steps, such as validating existing connections or passwords, to ensure the account's security. These measures are in place because Clerk cannot confirm the original ownership of the account, which could otherwise lead to unauthorized access.
 
 ## Users with different email addresses
 
-If a user has a different email from the one associated with the OAuth account, they can manually associate the two. To do so, they must:
+If a user has a different email from the one associated with the OAuth account, they can manually associate the two by following these steps:
 
-1. Sign into their Clerk application with the account that uses their main email address.
-1. In the **Manage Profile** section of the [`<UserProfile />`](/docs/components/user/user-profile) page, add the different email.
+1. Sign in to their Clerk application with the account that uses their main email address.
+1. In the [`<UserProfile />`](/docs/components/user/user-profile), add the different email.
 
 After following these steps, the user's OAuth accounts associated with both their primary and added email addresses will be linked to their main account.

docs/backend-requests/resources/session-tokens.mdx

@@ -5,9 +5,9 @@ description: Learn about session tokens and how to validate them in your backend
 
 When a user is authenticated in your application, Clerk generates a short-lived session token that you can use to authenticate requests to your backend. This token is a JSON Web Token (JWT) that contains information about the user and their session.
 
-Learn more about how Clerk combines session token authentication and JWT authentication in the [blog post](https://clerk.com/blog/combining-the-benefits-of-session-tokens-and-jwts).
+Read more about Clerk session tokens and how they work in [the dedicated blog post.](https://clerk.com/blog/combining-the-benefits-of-session-tokens-and-jwts)
 
-## Default session claims
+## Default claims
 
 Every generated token has default claims that cannot be overridden by templates. Clerk's default claims include:
 
@@ -64,6 +64,6 @@ If you include any of these claims in your token, use caution to ensure the stor
 
 ## Validate session tokens
 
-If you're using the middleware provided by our Clerk SDKs, this is all handled automatically in every request. If you're not using the middleware, you can still use the respective helpers provided by the SDKs to validate the tokens.
+If you're using the middleware provided by our Clerk SDKs, validating session tokens is handled automatically in every request. If you're not using the middleware, you can still use the respective helpers provided by the SDKs to validate the tokens.
 
 To learn how to manually verify a session token, refer to the [dedicated guide](/docs/backend-requests/manual-jwt).