diff --git a/docs/how-clerk-works/overview.mdx b/docs/how-clerk-works/overview.mdx index e5b610b1e8..0aae29923f 100644 --- a/docs/how-clerk-works/overview.mdx +++ b/docs/how-clerk-works/overview.mdx @@ -174,7 +174,9 @@ This example assumes that the user already signed up and their credentials are s > > --- > - > This is a great test of your mastery of [how cookies work](/docs/how-clerk-works/cookies)! For security reasons, the domain of a cookie can only be set as the domain of the server that set the cookie. The server that is returning the request to your application is FAPI. For the client cookie, this is ok, since the client cookie is set on FAPI. However, FAPI cannot set a cookie with your app's domain because it's not your app. Remember, if your app is running at `example.com`, FAPI would run at `clerk.example.com`. Instead, FAPI it sends back the **JWT value** of the session cookie in its response, and Clerk's client side SDK picks it up and uses javascript to set the session cookie on your app directly, since the javascript is running on your app's domain. + > This is a great test of your mastery of [how cookies work](/docs/how-clerk-works/cookies)! + > + > The server that is returning the request to your application is FAPI. For the **client cookie**, this is ok, since the **client cookie** needs to be set on FAPI. However, the **session cookie** needs to be set on your app's domain and remember, **the domain of a cookie can only be set as the domain of the server that set the cookie**. So FAPI cannot set the domain of your **session cookie** to your app's domain. Instead, FAPI returns the **JWT value** of the session cookie in its response, and when the Clerk client-side SDK integrated in your app receives the response, it gets the **JWT value** and uses JavaScript to set the **session cookie** on your app directly, since the JavaScript is running on your app's domain.