website: Apply CSpell corrections. (#20189)

* website: Apply CSpell corrections.

* Lint/spelling fix

---------

Co-authored-by: dewi-tik <dewi@goauthentik.io>

website/docs/add-secure-apps/bindings-overview/index.md

@@ -105,7 +105,7 @@ For example, you can create a binding for a specific group, and then [bind that
 Flow-stage bindings can have policy bindings bound to them; this can be used to conditionally run or skip stages within a flow. There are two settings in a flow-stage binding that configure _when_ these policies are executed:
 
 - **Evaluate when flow is planned**
-  Policies are evaluated when authentik creates a flow plan that contains a reference to all of the stages that the user will need to go through to complete the flow. In this case,user-specific attributes are only available if the user is already authentiticated before beginning the flow.
+  Policies are evaluated when authentik creates a flow plan that contains a reference to all of the stages that the user will need to go through to complete the flow. In this case,user-specific attributes are only available if the user is already authenticated before beginning the flow.
 
 - **Evaluate when the stage is run**
   Policies bound to a flow-stage binding are evaluated before the stage is run (i.e after the flow has started but before the stage is reached in the flow). Therefore the context with which policy bindings to the flow-stage binding are evaluated reflects the current state of the flow.

website/docs/add-secure-apps/flows-stages/stages/mtls/index.md

@@ -12,7 +12,7 @@ The Mutual TLS stage enables authentik to use client certificates to enroll and
 
 For mTLS, note that you should NOT use a globally known CA.
 
-Using private PKI certificates that are trusted by the end-device is best practise. For example, using a Verisign certificate as a "known CA" means that ANYONE who has a certificate signed by them can authenticate via mTLS, and in addition you should implement [custom validation](../../flow/context/index.mdx#auth_method-string) to prevent unauthorized access.
+Using private PKI certificates that are trusted by the end-device is best practice. For example, using a Verisign certificate as a "known CA" means that ANYONE who has a certificate signed by them can authenticate via mTLS, and in addition you should implement [custom validation](../../flow/context/index.mdx#auth_method-string) to prevent unauthorized access.
 :::
 
 ## Reverse-proxy configuration

website/docs/add-secure-apps/flows-stages/stages/redirect/index.md

@@ -17,4 +17,4 @@ When the user reaches this stage, they are redirected to a static URL.
 
 When the user reaches this stage, they are redirected to a specified flow, retaining all [flow context](../../flow/context/index.mdx).
 
-Optionally, untoggle the "Keep flow context" switch. If this is untoggled, all flow context is cleared with the exception of the [is_redirected](../../flow/context#is_redirected-flow-object) key.
+Optionally, toggle the "Keep flow context" switch to "off". When this control is set to "off", all flow context is cleared with the exception of the [is_redirected](../../flow/context#is_redirected-flow-object) key.

website/docs/add-secure-apps/providers/gws/configure-gws.md

@@ -43,7 +43,7 @@ The main steps to configure your Google Workspace organization are:
    A pop-up displays with the private key. The key can be saved to your computer as a JSON file. This key will be required when creating the Google Workspace provider in authentik.
 
     :::info Allow key creation
-    By default, the Google Cloud organization policy `iam.disableSerivceAccountKeyCreation` prevents creating service account keys. To allow key creation:
+    By default, the Google Cloud organization policy `iam.disableServiceAccountKeyCreation` prevents creating service account keys. To allow key creation:
     1. Navigate to **IAM & Admin** > **Organization Policies** and select the **Disable service account key creation** policy.
     2. Click **Manage policy** and disable the policy.
     3. Click **Set policy** to save your changes.
@@ -76,7 +76,7 @@ We do not recommend using an administrator account for the Delegated Subject use
 
 The Delagated Subject user requires the following permissions:
 
-##### Admin console privilieges
+##### Admin console privileges
 
 - Users
 - Groups

website/docs/add-secure-apps/providers/oauth2/index.mdx

@@ -23,7 +23,7 @@ OAuth 2.0 is an authorization protocol that allows an application (the RP) to de
 1. An authorization request is prepared by the RP and contains parameters for its implementation of OAuth and which data it requires, and then the User's browser is redirected to that URL.
 2. The RP sends a request to authentik in the background to exchange the access code for an access token (and optionally a refresh token).
 
-In detail, with OAuth2 when a user accesses the application (the RP) via their browser, the RP then prepares a URL with parameters for the OpenID Provider (OP), which the users's browser is redirected to. The OP authenticates the user and generates an authorization code. The OP then redirects the client (the user's browser) back to the RP, along with that authorization code. In the background, the RP then sends that same authorization code in a request authenticated by the `client_id` and `client_secret` to the OP. Finally, the OP responds by sending an Access Token saying this user has been authorised (the RP is recommended to validate this token using cryptography) and optionally a Refresh Token.
+In detail, with OAuth2 when a user accesses the application (the RP) via their browser, the RP then prepares a URL with parameters for the OpenID Provider (OP), which the users's browser is redirected to. The OP authenticates the user and generates an authorization code. The OP then redirects the client (the user's browser) back to the RP, along with that authorization code. In the background, the RP then sends that same authorization code in a request authenticated by the `client_id` and `client_secret` to the OP. Finally, the OP responds by sending an Access Token saying this user has been authorized (the RP is recommended to validate this token using cryptography) and optionally a Refresh Token.
 
 The image below shows a typical authorization code flow.
 
@@ -102,7 +102,7 @@ The flows and grant types used in this case are those used for a typical authori
 
 The authorization code is for environments with both a Client and a application server, where the back and forth happens between the client and an app server (the logic lives on app server). The RP needs to authorise itself to the OP. Client ID (public, identifies which app is talking to it) and client secret (the password) that the RP uses to authenticate.
 
-If you configure authentik to use "Offline access" then during the initial auth the OP sends two tokens, an access token (short-lived, hours, can be customised) and a refresh token (typically longer validity, days or infinite). The RP (the app) saves both tokens. When the access token is about to expire, the RP sends the saved refresh token back to the OP, and requests a new access token. When the refresh token itself is about to expire, the RP can also ask for a new refresh token. This can all happen without user interaction if you configured the offline access.
+If you configure authentik to use "Offline access" then during the initial auth the OP sends two tokens, an access token (short-lived, hours, can be customized) and a refresh token (typically longer validity, days or infinite). The RP (the app) saves both tokens. When the access token is about to expire, the RP sends the saved refresh token back to the OP, and requests a new access token. When the refresh token itself is about to expire, the RP can also ask for a new refresh token. This can all happen without user interaction if you configured the offline access.
 
 :::info
 Starting with authentik 2024.2, applications only receive an access token. To receive a refresh token, both applications and authentik must be configured to request the `offline_access` scope. In authentik this can be done by selecting the `offline_access` Scope mapping in the provider settings.

website/docs/add-secure-apps/providers/rac/index.md

@@ -51,7 +51,7 @@ A new connection is created every time an endpoint is selected in the [User Inte
 
 Additionally, it is possible to modify the connection settings through the authorization flow. Configuration set in `connection_settings` in the flow plan context will be merged with other settings as shown above.
 
-The RAC provider utilises [Apache Guacamole](https://guacamole.apache.org/) for establishing SSH, RDP and VNC connections. RAC supports the use of Apache Guacamole connection configurations.
+The RAC provider utilizes [Apache Guacamole](https://guacamole.apache.org/) for establishing SSH, RDP and VNC connections. RAC supports the use of Apache Guacamole connection configurations.
 
 For a full list of possible connection configurations, see the [Apache Guacamole connection configuration documentation](https://guacamole.apache.org/doc/gug/configuring-guacamole.html#configuring-connections).
 

website/docs/add-secure-apps/providers/radius/index.mdx

@@ -42,7 +42,7 @@ The RADIUS provider supports EAP-TLS and [PAP](https://en.wikipedia.org/wiki/Pas
 <details>
   <summary>RADIUS compatibility matrix for password-based authentication:</summary>
 
-This table represents the password-hash compatibillity with various RADIUS protocols.
+This table represents the password-hash compatibility with various RADIUS protocols.
 
 <HashSupport />
 </details>
@@ -61,7 +61,7 @@ For certificates, ensure that you use a client certificate and a server certific
 
 For EAP-TLS, note that you should NOT use a globally known CA.
 
-Using private PKI certificates that are trusted by the end-device is best practise. For example, using a Verisign certificate as a "known CA" means that ANYONE who has a certificate signed by them can authenticate via EAP-TLS, and in addition you should implement [custom validation](../../flows-stages/flow/context/index.mdx#auth_method-string) to prevent unauthorized access.
+Using private PKI certificates that are trusted by the end-device is best practice. For example, using a Verisign certificate as a "known CA" means that ANYONE who has a certificate signed by them can authenticate via EAP-TLS, and in addition you should implement [custom validation](../../flows-stages/flow/context/index.mdx#auth_method-string) to prevent unauthorized access.
 :::
 
 ### RADIUS attributes