Fixing some typos

9 files changed, 15 insertions, 15 deletions

diff --git a/docs/contributing.rst b/docs/contributing.rst
index 7b6a8ea..744c4c2 100644
--- a/docs/contributing.rst
+++ b/docs/contributing.rst
@@ -159,7 +159,7 @@ request reduces our test coverage because it lacks tests then it will be
 
 Also, keep your tests as simple as possible. Complex tests end up requiring
 their own tests. We would rather see duplicated assertions across test methods
-then cunning utility methods that magically determine which assertions are
+than cunning utility methods that magically determine which assertions are
 needed at a particular stage. Remember: `Explicit is better than implicit`.
 
 Don't mix code changes with whitespace cleanup
diff --git a/docs/faq.rst b/docs/faq.rst
index 561df15..74b6312 100644
--- a/docs/faq.rst
+++ b/docs/faq.rst
@@ -1,7 +1,7 @@
 F.A.Q
 =====
 
-What parts of OAuth 1 & 2 is supported?
+What parts of OAuth 1 & 2 are supported?
     See :doc:`feature_matrix`.
 
 What is the difference between a client and a consumer?
diff --git a/docs/installation.rst b/docs/installation.rst
index a5be158..5a8b2cb 100644
--- a/docs/installation.rst
+++ b/docs/installation.rst
@@ -3,7 +3,7 @@ Installing OAuthLib
 
 The recommended way to install OAuthLib is from PyPI but if you are running
 into a bug or want to try out recently implemented features you will want to
-try the installing directly from the GitHub master branch.
+try installing directly from the GitHub master branch.
 
 For various reasons you may wish to install using your OS packaging system and
 install instructions for a few are shown below. Please send a PR to add a
@@ -24,7 +24,7 @@ Bleeding edge from GitHub master
 
     pip install -e git+https://github.com/idan/oauthlib.git#egg=oauthlib
 
-Debian and derivaties like Ubuntu, Mint, etc.
+Debian and derivatives like Ubuntu, Mint, etc.
 ---------------------------------------------
 
 .. code-block:: bash
diff --git a/docs/oauth1/client.rst b/docs/oauth1/client.rst
index 2b3dfec..b209196 100644
--- a/docs/oauth1/client.rst
+++ b/docs/oauth1/client.rst
@@ -59,7 +59,7 @@ Using the Client
 
     * a dictionary
     * an iterable of 2-tuples
-    * a properly-formated x-www-url-formencoded string
+    * a properly-formatted x-www-url-formencoded string
 
 **RSA Signatures**
 
diff --git a/docs/oauth1/security.rst b/docs/oauth1/security.rst
index fa2180e..a1432a9 100644
--- a/docs/oauth1/security.rst
+++ b/docs/oauth1/security.rst
@@ -11,7 +11,7 @@ A few important facts regarding OAuth security
         nonce/timestamp pairs for each request, allowing an attacker who
         intercept your request to replay it later, overriding your initial
         request. **Server defaults to fail all requests which are not made over
-        HTTPS**, you can explicitely disable this using the enforce_ssl
+        HTTPS**, you can explicitly disable this using the enforce_ssl
         property.
 
     * **Tokens must be random**, OAuthLib provides a method for generating
@@ -19,7 +19,7 @@ A few important facts regarding OAuth security
         use it. If you decide to roll your own, use ``random.SystemRandom``
         which is based on ``os.urandom`` rather than the default ``random``
         based on the effecient but not truly random Mersenne Twister.
-        Predicatble tokens allow attackers to bypass virtually all defences
+        Predictable tokens allow attackers to bypass virtually all defences
         OAuth provides.
 
     * **Timing attacks are real** and more than possible if you host your
diff --git a/docs/oauth1/server.rst b/docs/oauth1/server.rst
index fec8e40..9364f8c 100644
--- a/docs/oauth1/server.rst
+++ b/docs/oauth1/server.rst
@@ -161,7 +161,7 @@ obtain an access token.
 **Authorization Verifier**:
     An unguessable unique string of characters. This code asserts that the user
     has given the client authorization to access the requested realms. It is
-    initial nil when the client obtains the request token in the first step, and
+    initially nil when the client obtains the request token in the first step, and
     set after user authorization is given in the second step::
 
         verifier = sqlalchemy.Column(sqlalchemy.String)
@@ -178,7 +178,7 @@ The user and realms will need to be transferred from the request token to the
 access token. It is possible that the list of authorized realms is smaller
 than the list of requested realms. Clients can observe whether this is the case
 by comparing the `oauth_realms` parameter given in the token reponse. This way
-of indicated change of realms is backported from OAuth2 scope behaviour and is
+of indicating change of realms is backported from OAuth2 scope behaviour and is
 not in the OAuth 1 spec.
 
 **Client**:
diff --git a/docs/oauth2/endpoints/authorization.rst b/docs/oauth2/endpoints/authorization.rst
index 3c42387..9c0cea1 100644
--- a/docs/oauth2/endpoints/authorization.rst
+++ b/docs/oauth2/endpoints/authorization.rst
@@ -58,7 +58,7 @@ Grant and the Client Credentials Grant.
             }
             # these credentials will be needed in the post authorization view and
             # should be persisted between. None of them are secret but take care
-            # to ensure their integrety if embedding them in the form or cookies.
+            # to ensure their integrity if embedding them in the form or cookies.
             from your_datastore import persist_credentials
             persist_credentials(credentials)
 
diff --git a/docs/oauth2/endpoints/endpoints.rst b/docs/oauth2/endpoints/endpoints.rst
index 42b1deb..0e70798 100644
--- a/docs/oauth2/endpoints/endpoints.rst
+++ b/docs/oauth2/endpoints/endpoints.rst
@@ -5,10 +5,10 @@ Endpoints in OAuth 2 are targets with a specific responsibility and often
 associated with a particular URL. Because of this the word endpoint might be
 used interchangably from the endpoint url.
 
-There main three responsibilities in an OAuth 2 flow is to authorize access to a
+The main three responsibilities in an OAuth 2 flow is to authorize access to a
 certain users resources to a client, to supply said client with a token
 embodying this authorization and to verify that the token is valid when the
-client attempts to access thee user resources on their behalf.
+client attempts to access the user resources on their behalf.
 
 .. toctree::
     :maxdepth: 2
diff --git a/docs/oauth2/endpoints/token.rst b/docs/oauth2/endpoints/token.rst
index 9bf9f8d..b01cda6 100644
--- a/docs/oauth2/endpoints/token.rst
+++ b/docs/oauth2/endpoints/token.rst
@@ -3,9 +3,9 @@ Token creation
 ==============
 
 Token endpoints issue tokens to clients who have already been authorized access,
-be it by explicit actions from the user or implicitely. The token response is
-well defined and typically consist of an unguessable access token, the token
-type, its expiration from now in seconds and depending on the scenario, a
+be it by explicit actions from the user or implicitly. The token response is
+well defined and typically consists of an unguessable access token, the token
+type, its expiration from now in seconds, and depending on the scenario, a
 refresh token to be used to fetch new access tokens without authorization.
 
 One argument for OAuth 2 being more scalable than OAuth 1 is that tokens may