fix numbering

Author: pcarleton

docs/specification/draft/basic/authorization.mdx

@@ -266,7 +266,7 @@ as outlined in [RFC 9700](https://datatracker.ietf.org/doc/html/rfc9700).
 
 MCP authorization servers SHOULD enforce token expiration and rotation to limit the window of exploitation.
 
-### 3.3 Token Interception
+### 3.2 Token Interception
 An attacker positioned between MCP clients and MCP servers can intercept tokens via [Man-in-the-Middle (MITM)](https://en.wikipedia.org/wiki/Man-in-the-middle_attack) attacks.
 
 To mitigate the risk of this threat:
@@ -275,7 +275,7 @@ To mitigate the risk of this threat:
 1. MCP clients **MUST** implement PKCE according to [OAuth 2.1 section 7.5.2](https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-12.html#name-countermeasures). PKCE helps  prevent authorization code interception attacks by requiring clients to create a secret verifier-challenge pair, ensuring that only the original requestor can exchange an authorization code for tokens.
 1. All redirect URIs **MUST** be either `localhost` or use HTTPS to prevent token and code interception.
 
-### 3.4 Open Redirection
+### 3.3 Open Redirection
 An attacker may craft malicious redirect URIs to direct users to phishing sites 
 and intercept credentials during the authorization flow.
 
@@ -287,7 +287,7 @@ MCP clients **SHOULD** use and verify state parameters in the authorization code
 and discard any results that do not include or have a mis-match with the original state.
 
 
-### 3.5 Confused Deputy Problem
+### 3.4 Confused Deputy Problem
 
 An attacker can exploit OAuth proxy configurations that share third-party client credentials 
 across multiple users.