docs: correct order of jwt claims sections

Author: steve-chavez

docs/references/auth.rst

@@ -168,27 +168,14 @@ It goes as follows:
 
 - If the JWT does not have a ``kid`` parameter, then PostgREST will validate the token against each JWK in the :ref:`jwt-secret`.
 
-.. _jwt_aud_verification:
-
-``aud`` verification
-~~~~~~~~~~~~~~~~~~~~
-
-PostgREST has built-in verification of the `JWT audience claim <https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3>`_.
-It works this way:
-
-- If :ref:`jwt-aud` is not set (the default), PostgREST identifies with all audiences and allows the JWT for any ``aud`` claim.
-- If :ref:`jwt-aud` is set to a specific audience, PostgREST will check if this audience is present in the ``aud`` claim:
-
-  + If the ``aud`` value is a JSON string, it will match it to the :ref:`jwt-aud`.
-  + If the ``aud`` value is a JSON array of strings, it will search every element for a match.
-  + If the match fails or if the ``aud`` value is not a string or array of strings, then the token will be rejected with a :ref:`401 Unauthorized <pgrst303>` error.
-  + If the ``aud`` key **is not present** or if its value is ``null`` or ``[]``, PostgREST will interpret this token as allowed for all audiences and will complete the request.
-
 .. _jwt_claims_validation:
 
 JWT Claims Validation
 ---------------------
 
+Time-Based claims validation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
 The time-based JWT claims specified in `RFC 7519 <https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4>`_ are validated:
 
 - ``exp`` Expiration Time
@@ -197,6 +184,22 @@ The time-based JWT claims specified in `RFC 7519 <https://datatracker.ietf.org/d
 
 We allow a 30-second clock skew when validating the above claims. In other words, we give an extra 30 seconds before the JWT is rejected if there is a slight discrepancy in the timestamps.
 
+.. _jwt_aud:
+
+``aud`` validation
+~~~~~~~~~~~~~~~~~~
+
+PostgREST has built-in validation of the `JWT audience claim <https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3>`_.
+It works this way:
+
+- If :ref:`jwt-aud` is not set (the default), PostgREST identifies with all audiences and allows the JWT for any ``aud`` claim.
+- If :ref:`jwt-aud` is set to a specific audience, PostgREST will check if this audience is present in the ``aud`` claim:
+
+  + If the ``aud`` value is a JSON string, it will match it to the :ref:`jwt-aud`.
+  + If the ``aud`` value is a JSON array of strings, it will search every element for a match.
+  + If the match fails or if the ``aud`` value is not a string or array of strings, then the token will be rejected with a :ref:`401 Unauthorized <pgrst303>` error.
+  + If the ``aud`` key **is not present** or if its value is ``null`` or ``[]``, PostgREST will interpret this token as allowed for all audiences and will complete the request.
+
 .. _jwt_caching:
 
 JWT Cache

docs/references/configuration.rst

@@ -603,7 +603,7 @@ jwt-aud
   **In-Database** pgrst.jwt_aud
   =============== =================================
 
-    Specifies an audience for the JWT ``aud`` claim. See :ref:`jwt_aud_verification`.
+    Specifies an audience for the JWT ``aud`` claim. See :ref:`jwt_aud`.
 
 .. _jwt-role-claim-key: