Merge pull request #730 from yepes/patch-1

Update user-object.mdx

v2/thirdpartypasswordless/user-object.mdx

@@ -62,7 +62,7 @@ Before we dive into the meaning of each of the fields, it is important to unders
 
 ## Primary vs recipe user ID
 
-In SuperTokens, each user can have multiple login methods: for example, one user may be able to login with both, email password and social login. Each of these login methods, will give the user a unique user ID - this is known as a `recipeUserId`. We call it that, cause email passwors and social login are two different recipes in SuperTokens. Now of course, when that user uses either of the login methods, we must resolve it to the same user ID. This user ID, that is common across all login methods for a user, is known as the primary user ID. The value of the primary user ID is equal to the recipe user ID of the first login method.
+In SuperTokens, each user can have multiple login methods: for example, one user may be able to login with both, email password and social login. Each of these login methods, will give the user a unique user ID - this is known as a `recipeUserId`. We call it that, cause email passwords and social login are two different recipes in SuperTokens. Now of course, when that user uses either of the login methods, we must resolve it to the same user ID. This user ID, that is common across all login methods for a user, is known as the primary user ID. The value of the primary user ID is equal to the recipe user ID of the first login method.
 
 Let's take an example. A user first signs up with the email password recipe. This gives them a recipe user ID or `r1`. Their primary user ID is also `r1`. Now, they sign in with Google with the same email. This will create a different recipe user ID `r2`. If you have enabled the automatic account linking, then the two recipe userIds will be linked, and `r2`'s primary user will be `r1`. Therefore, we will have the following mapping: