diff --git a/doc/sphinx-guides/source/api/auth.rst b/doc/sphinx-guides/source/api/auth.rst
index 5acf0fb0ff7..8dffb914e29 100644
--- a/doc/sphinx-guides/source/api/auth.rst
+++ b/doc/sphinx-guides/source/api/auth.rst
@@ -94,13 +94,13 @@ By default, the Bearer token is expected to include the following claims that wi
 - ``lastName``
 - ``emailAddress``
 
-The one parameter required by default is ``termsAccepted``` which must be set to true, indicating that the user has seen and accepted the Terms of Use of the Installation. 
+The one parameter required by default is ``termsAccepted`` which must be set to true, indicating that the user has seen and accepted the Terms of Use of the installation. 
 
-If the feature flag ``api-bearer-auth-handle-tos-acceptance-in-idp``` is enabled (along with the ``api-bearer-auth`` feature flag), Dataverse assumes that the Terms of Service acceptance was handled by the identity provider, e.g. in the OIDC ``consent``` dialog, and the `termsAccepted``` parameter is not needed.
+If the feature flag ``api-bearer-auth-handle-tos-acceptance-in-idp`` is enabled (along with the ``api-bearer-auth`` feature flag), Dataverse assumes that the Terms of Service acceptance was handled by the identity provider, e.g. in the OIDC ``consent`` dialog, and the ``termsAccepted`` parameter is not needed.
 
 There is another flag called ``api-bearer-auth-provide-missing-claims`` that can be enabled (along with the ``api-bearer-auth`` feature flag) to allow sending missing user claims in the registration JSON. This is useful when the identity provider does not supply the necessary claims listed above. If properties are provided in the JSON, but corresponding claims already exist in the identity provider, an error will be thrown, outlining the conflicting properties. Note that supplying missing claims is configured via a separate feature flag because using it may introduce user impersonation issues, for example if the identity provider does not provide an email field and the user submits an email address they do not own.
 
-In all cases, the submitted JSON can optionally include the fields ``position`` or ``affiliation``, which will be added to the users's Dataverse account profile. These fields are optional, and if not provided, they will be persisted as empty in Dataverse.
+In all cases, the submitted JSON can optionally include the fields ``position`` or ``affiliation``, which will be added to the user's Dataverse account. These fields are optional, and if not provided, they will be persisted as empty in Dataverse.
 
 Signed URLs
 -----------