Apply suggestions from code review

Co-authored-by: Stojan Dimitrovski <sdimitrovski@gmail.com>

apps/www/_blog/2022-12-14-mfa-auth-via-rls.mdx

@@ -23,12 +23,12 @@ Today, we’re releasing Multi Factor Authentication for everyone. We are also e
 
 ## What is MFA?
 
-Multi-factor authentication (MFA), sometimes called two-factor authentication (2FA), adds an additional layer of security to your application by letting you verify users’ identity through extra steps. This typically consists of something you know, like a password, and something you have, like an authenticator application. We built MFA in response to customer requests - developers wanted enhanced security- be it for compliance, client requirements, or simply for peace of mind. As such, we started by building MFA support for Time-Based One Time Passwords (TOTP).
+Multi-factor authentication (MFA), sometimes called two-factor authentication (2FA), adds an additional layer of security to your application by letting you verify users’ identity through extra steps. This typically consists of something you know, like a password, and something you have, like an authenticator application. We built MFA in response to customer requests - developers wanted enhanced security - be it for compliance, client requirements, or simply for peace of mind. As such, we started by building MFA support for Time-Based One Time Passwords (TOTP).
 
 
 ## An Overview of TOTP
 
-[TOTP](https://www.rfc-editor.org/rfc/rfc6238) works by generating a unique, one-time password that is valid for a limited amount of time, usually 30 seconds or less. This password is generated using a shared secret key that is known only to the device and Supabase Auth, along with the current time. To exchange the shared secret key, a user scans a QR code generated by the server in order to establish a connection.  The QR code can be represented by a URI which conforms to the [Google Authenticator Key URI format](https://github.com/google/google-authenticator/wiki/Key-Uri-Format):
+[TOTP](https://www.rfc-editor.org/rfc/rfc6238) works by generating a unique, one-time password that is valid for a limited amount of time, usually 30 seconds or less. This password is generated using a shared secret key that is known only to the device and Supabase Auth, along with the current time. To exchange the shared secret key, a user scans a QR code generated by the server in order to establish a connection. The QR code can be represented by a URI which conforms to the [Google Authenticator Key URI format](https://github.com/google/google-authenticator/wiki/Key-Uri-Format):
 
 ```jsx
 otpauth://totp/supabase.io:j@supacats.io?algorithm=SHA1&digits=6&issuer=supabase.io&period=30&secret=BFSXQHFB2BGAZIOQWCDBJUF7B54A52JQ
@@ -40,7 +40,7 @@ In the event that the user faces difficulties entering a QR code the user can al
 
 ## MFA Flows: Enrolment and Verification
 
-An MFA flow can be broken into two key steps: Enrollment and Verification. During the *Enrollment* process Supabase Auth exchanges secrets with the user’s authenticator application. During the *Verification* process, the device makes use of the timestamp together with the secret to produce a six digit code that the server can verify.
+An MFA flow can be broken into two key steps: Enrollment and Verification. During the *Enrollment* process Supabase Auth exchanges a randomly generated secret with the user’s authenticator application. During the *Verification* process, the device makes use of the timestamp together with the secret to produce a six digit code that the server can verify.
 
 ![Flowchart of an MFA flow](apps/www/public/images/blog/lw6-auth/mfa-flow.png)
 **Enrollment**
@@ -76,24 +76,14 @@ graph TD
 Adding MFA to your project and not enforcing it is like buying an expensive door and never locking it. We love Postgres RLS at Supabase and we believe it plays a key role in facilitating custom checks for a spread of use cases. To support RLS integration, JWTs issued by Supabase Auth now contain two additional pieces of information:
 
 1. An Authenticator Assurance Level (AAL) claim. Use this to quickly identify the level of identity checks the user has performed. `aal1` is reserved for conventional sign in, while `aal2` is issued only after the user has verified with an additional factor.
-
 2. An Authenticator Method Reference (AMR) claim. Use this to identify all of the authentication methods used by the user. This is also useful if you wish to implement step-up login scenarios.
 
 ```jsx
 {
-  "aud": "authenticated",
-  "exp": 1670929371,
   "sub": "8802c1d6-c555-46e3-aacd-b61198b058d9",
   "email": "j0@supacats.io",
-  "phone": "",
-  "app_metadata": {
-    "provider": "email",
-    "providers": [
-      "email"
-    ]
-  },
-  "user_metadata": {},
-  "role": "authenticated",
+  "aud": "authenticated",
+  "exp": 1670929371,
   "aal": "aal2",
   "amr": [
     {
@@ -105,9 +95,8 @@ Adding MFA to your project and not enforcing it is like buying an expensive door
       "timestamp": 1670925771
     }
   ],
-  "session_id": "9db34b97-a0e3-4eaf-810c-00b21b844cd0"
+  // ...
 }
-```
 
 The information encoded in these claims can be used for both full enforcement and partial enforcement across database queries.