Fixes typos in docs (authts#1443)

* Fixed typos.

Author: grjan7

docs/index.md

@@ -5,7 +5,7 @@ If you are unfamiliar with OpenID Connect, then you should learn the
 library is designed as a spec-compliant protocol library.
 
 There are two main classes that you might want to use depend on the level at
-with you use to use the library:
+which you use to use the library:
 
 - [UserManager](classes/UserManager.html) provides a higher level API for
   signing a user in, signing out, managing the user's claims
@@ -118,12 +118,12 @@ const customState = { foo: "bar" };
 mgr.signinRedirect({ state: customState });
 ```
 
-After successful sign-in the custom state is part of the [User](classes/User.html#state) object as `state`. In case of failure it is inside [ErrorResponse](classes/ErrorResponse.html#state).
+After successful sign-in, the custom state is part of the [User](classes/User.html#state) object as `state`. In case of failure, it is inside [ErrorResponse](classes/ErrorResponse.html#state).
 
 This custom state should not be confused with the URL state parameter. The latter is internally used to match against the authentication state object to finish the authentication process.
 
 # Custom state in request url
-If you would like to encode a custom state string in the sign in request url, you can do so with the `url_state` parameter. You may want to do this in order to pass user state to the authentication server and/or a proxy and return that state as part of the response.
+If you would like to encode a custom state string in the sign-in request url, you can do so with the `url_state` parameter. You may want to do this in order to pass user state to the authentication server and/or a proxy and return that state as part of the response.
 
 ```javascript
 const mgr = new UserManager();

docs/migration.md

@@ -2,9 +2,9 @@
 
 The API is largely backwards-compatible.
 
-The "crypto-js" software library has been removed; the native crypto/crypto.subtle module built into the browser is instead used. All modern browsers are expected to support it. If you need to support older browsers stay with v2.4!
+The "crypto-js" software library has been removed; the native crypto/crypto.subtle module built into the browser is instead used. All modern browsers are expected to support it. If you need to support older browsers, stay with v2.4!
 
-The behavior of merging claims  has been improved.
+The behavior of merging claims has been improved.
 
 ### [OidcClientSettings](https://authts.github.io/oidc-client-ts/interfaces/OidcClientSettings.html)
 
@@ -13,7 +13,7 @@ The behavior of merging claims  has been improved.
   - `userInfoJwtIssuer`
   - `refreshTokenCredentials` use `fetchRequestCredentials`
 - the `mergeClaims` has been replaced by `mergeClaimsStrategy`
-  - if the previous behavior is required `mergeClaimsStrategy: { array: "merge" }` comes close to it
+  - if the previous behavior is required, `mergeClaimsStrategy: { array: "merge" }` comes close to it
 - default of `response_mode` changed from `query` → `undefined`
 
 
@@ -32,7 +32,7 @@ removed.
   - `staleStateAge` → `staleStateAgeInSeconds`
 - default of `loadUserInfo` changed from `true` → `false`
 - removed `ResponseValidatorCtor` and `MetadataServiceCtor`
-  - if necessary `OidcClient` / `UserManager` classes may be extended to alter
+  - if necessary, `OidcClient` / `UserManager` classes may be extended to alter
     their behavior
 - restricted `response_type` to `code` flow only. As per [OAuth 2.1](https://oauth.net/2.1/): **PKCE is required** for all OAuth clients using the authorization `code` flow
   - as in oidc-client 1.x, OAuth 2.0 hybrid flows are not supported

docs/protocols/authorization-code-grant-with-pkce.md

@@ -1,6 +1,6 @@
 # Authorization Code Grant with Proof Key for Code Exchange (PKCE)
 
-The authorization code protocol is part of OAuth 2.0 (defined in [OAuth 2.0 RFC 7636](https://tools.ietf.org/html/rfc7636)). It involves the exchange of an authorization code for a token. This is the recommend authorization code flow in the [OAuth 2.1 draft](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-07#section-10).
+The authorization code protocol is part of OAuth 2.0 (defined in [OAuth 2.0 RFC 7636](https://tools.ietf.org/html/rfc7636)). It involves the exchange of an authorization code for a token. This is the recommended authorization code flow in the [OAuth 2.1 draft](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-07#section-10).
 
 
 ## Principle of function

docs/protocols/authorization-code-grant.md

@@ -8,10 +8,10 @@ It implies some security risks, so you should only use it after a security asses
 
 ## Security concerns
 This flow can only be used for applications, which can protect the client secret:
-- **Native app**: Can not securely store the client secret, as its possible to decompile the application.
-- **Single-page app**: Can not securely store the client secret, as the full code is exposed in the users browser
+- **Native app**: Can not securely store the client secret, as it's possible to decompile the application.
+- **Single-page app**: Can not securely store the client secret, as the full code is exposed in the user's browser
 
-In that scenarios [Authorization Code Grant with Proof Key for Code Exchange (PKCE)](authorization-code-grant-with-pkce.md) must be used.
+In that scenarios, [Authorization Code Grant with Proof Key for Code Exchange (PKCE)](authorization-code-grant-with-pkce.md) must be used.
 
 
 ## Principle of function

docs/protocols/resource-owner-password-credentials-grant.md

@@ -8,15 +8,15 @@ It implies some security risks, so you should only use it after a security asses
 
 ## Security concerns
 
-To start with, this flow is not part of the [Open ID Connect standard](https://openid.net/specs/openid-connect-core-1_0.html). Furthermore, although it is part of OAuth 2.0, it has been removed in the [OAuth 2.1 draft](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-07#section-10), and there are good reasons for this:
+To start with, this flow is not part of the [OpenID Connect standard](https://openid.net/specs/openid-connect-core-1_0.html). Furthermore, although it is part of OAuth 2.0, it has been removed in the [OAuth 2.1 draft](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-07#section-10), and there are good reasons for this:
 
 * When using this flow, the credentials of the user are exposed to the client application. The RFC mandates that ["the client application MUST discard the credentials once the access token has been obtained"](https://www.rfc-editor.org/rfc/rfc6749#section-4.3.1), but there is no technical way for the Identity Provider / Authorization Server to enforce this point. This flow MUST NOT be allowed unless the Client can be enforced to fulfill this requirement through other means (probably because both are under the same security domain, probably the same organization or similar constraints). This point is covered [several](https://www.rfc-editor.org/rfc/rfc6749#section-1.3.3) [times](https://www.rfc-editor.org/rfc/rfc6749#section-4.3) during the RFC and by some IdP implementations, such as [Auth0](https://auth0.com/docs/get-started/authentication-and-authorization-flow/resource-owner-password-flow) or [Keycloak](https://www.keycloak.org/docs/latest/securing_apps/#_resource_owner_password_credentials_flow), but it is sometimes quickly ignored by some developers.
 
 * Even if the previous point is covered, this flow is increasing the attack surface of the system. For example, if the Client Application is compromised (maybe through an XSS attack, for example), the credentials of the user are exposed, so the attacker have access to other applications accessible by the user. In comparison, for example, in the Authorization Code Flow if the Client Application is equally compromised only the access token is exposed, usually meaning that only the given application has been compromised. A different way to see this is: usually the IdP/Authorization Server are strongly protected, and the Client Applications are allowed lower levels of security auditing... but when using this flow, if any of them is exposed, the user credentials are exposed; so both of them should be equally treated regarding security.
 
-Therefor, this flow MUST NOT be used as a replacement for the Authorization Code flow. This flow can only be seen as a replacement of classic form-based user/password authentication directly in the application.
+Therefore, this flow MUST NOT be used as a replacement for the Authorization Code flow. This flow can only be seen as a replacement of classic form-based user/password authentication directly in the application.
 
-Then, why are we adding this support in `oidc-client-ts`? Well... form-based user/password authentication is actually widely used in the industry, and using a standard IdP as authenticator for this architecture has some benefits (other things, such as password expiration, user management back-office, etc are provided for free by the IdP). So this flow can be an easy help in this scenario. But you MUST NOT use this flow believing that you are having all the security benefits of OpenId Connect or OAuth; you are not.
+Then, why are we adding this support in `oidc-client-ts`? Well... form-based user/password authentication is actually widely used in the industry, and using a standard IdP as authenticator for this architecture has some benefits (other things, such as password expiration, user management back-office, etc are provided for free by the IdP). So this flow can be an easy help in this scenario. But you MUST NOT use this flow believing that you are having all the security benefits of OpenID Connect or OAuth; you are not.
 
 
 ## Principle of function

src/UserManager.ts

@@ -179,7 +179,7 @@ export class UserManager {
 
     /**
      * Process the response (callback) from the authorization endpoint.
-     * It is recommend to use {@link UserManager.signinCallback} instead.
+     * It is recommended to use {@link UserManager.signinCallback} instead.
      *
      * @returns A promise containing the authenticated `User`.
      *
@@ -261,7 +261,7 @@ export class UserManager {
     }
     /**
      * Notify the opening window of response (callback) from the authorization endpoint.
-     * It is recommend to use {@link UserManager.signinCallback} instead.
+     * It is recommended to use {@link UserManager.signinCallback} instead.
      *
      * @returns A promise
      *
@@ -344,7 +344,7 @@ export class UserManager {
     /**
      *
      * Notify the parent window of response (callback) from the authorization endpoint.
-     * It is recommend to use {@link UserManager.signinCallback} instead.
+     * It is recommended to use {@link UserManager.signinCallback} instead.
      *
      * @returns A promise
      *
@@ -363,7 +363,7 @@ export class UserManager {
      * - {@link UserManager.signinPopupCallback}
      * - {@link UserManager.signinSilentCallback}
      *
-     * @throws `Error` If request_type is unknown or signout can not processed.
+     * @throws `Error` If request_type is unknown or signout cannot be processed.
      */
     public async signinCallback(url = window.location.href): Promise<User | void> {
         const { state } = await this._client.readSigninResponseState(url);
@@ -386,7 +386,7 @@ export class UserManager {
      * - {@link UserManager.signoutPopupCallback}
      * - {@link UserManager.signoutSilentCallback}
      *
-     * @throws `Error` If request_type is unknown or signout can not processed.
+     * @throws `Error` If request_type is unknown or signout cannot be processed.
      */
     public async signoutCallback(url = window.location.href, keepOpen = false): Promise<void> {
         const { state } = await this._client.readSignoutResponseState(url);
@@ -543,7 +543,7 @@ export class UserManager {
 
     /**
      * Process response (callback) from the end session endpoint.
-     * It is recommend to use {@link UserManager.signoutCallback} instead.
+     * It is recommended to use {@link UserManager.signoutCallback} instead.
      *
      * @returns A promise containing signout response
      *
@@ -557,7 +557,7 @@ export class UserManager {
     }
 
     /**
-     * Trigger a redirect of a popup window window to the end session endpoint.
+     * Trigger a redirect of a popup window to the end session endpoint.
      *
      * @returns A promise
      */
@@ -587,7 +587,7 @@ export class UserManager {
 
     /**
      * Process response (callback) from the end session endpoint from a popup window.
-     * It is recommend to use {@link UserManager.signoutCallback} instead.
+     * It is recommended to use {@link UserManager.signoutCallback} instead.
      *
      * @returns A promise
      *
@@ -676,7 +676,7 @@ export class UserManager {
 
     /**
      * Notify the parent window of response (callback) from the end session endpoint.
-     * It is recommend to use {@link UserManager.signoutCallback} instead.
+     * It is recommended to use {@link UserManager.signoutCallback} instead.
      *
      * @returns A promise
      *

src/utils/PopupUtils.ts

@@ -14,7 +14,7 @@ export interface PopupWindowFeatures {
     status?: boolean | string;
     resizable?: boolean | string;
     scrollbars?: boolean | string;
-    /** Close popup window after time in seconds, by default it is -1. To enable this feature set value greater than 0 */
+    /** Close popup window after time in seconds, by default it is -1. To enable this feature, set value greater than 0. */
     closePopupWindowAfterInSeconds?: number;
 
     [k: string]: boolean | string | number | undefined;