✏ Fix typos and rewording in docs for security (#1678)

Co-authored-by: Sebastián Ramírez <tiangolo@gmail.com>

docs/en/docs/tutorial/security/first-steps.md

@@ -90,7 +90,7 @@ So, let's review it from that simplified point of view:
 * The API checks that `username` and `password`, and responds with a "token" (we haven't implemented any of this yet).
     * A "token" is just a string with some content that we can use later to verify this user.
     * Normally, a token is set to expire after some time.
-        * So, the user will have to login again at some point later.
+        * So, the user will have to log in again at some point later.
         * And if the token is stolen, the risk is less. It is not like a permanent key that will work forever (in most of the cases).
 * The frontend stores that token temporarily somewhere.
 * The user clicks in the frontend to go to another section of the frontend web app.
@@ -103,7 +103,7 @@ So, let's review it from that simplified point of view:
 
 **FastAPI** provides several tools, at different levels of abstraction, to implement these security features.
 
-In this example we are going to use **OAuth2**, with the **Password** flow, using a **Bearer** token.
+In this example we are going to use **OAuth2**, with the **Password** flow, using a **Bearer** token. We do that using the `OAuth2PasswordBearer` class.
 
 !!! info
     A "bearer" token is not the only option.
@@ -114,7 +114,7 @@ In this example we are going to use **OAuth2**, with the **Password** flow, usin
 
     In that case, **FastAPI** also provides you with the tools to build it.
 
-`OAuth2PasswordBearer` is a class that we create passing a parameter with the URL the client (the frontend running in the user's browser) can use to send the `username` and `password` and get a token.
+When we create an instance of the `OAuth2PasswordBearer` class we pass in the `tokenUrl` parameter. This parameter contains the URL that the client (the frontend running in the user's browser) will use to send the `username` and `password` in order to get a token.
 
 ```Python hl_lines="6"
 {!../../../docs_src/security/tutorial001.py!}
@@ -127,7 +127,9 @@ In this example we are going to use **OAuth2**, with the **Password** flow, usin
 
     Using a relative URL is important to make sure your application keeps working even in an advanced use case like [Behind a Proxy](../../advanced/behind-a-proxy.md){.internal-link target=_blank}.
 
-It doesn't create that endpoint / *path operation* for `./token`, but declares that that URL `./token` is the one that the client should use to get the token. That information is used in OpenAPI, and then in the interactive API documentation systems.
+This parameter doesn't create that endpoint / *path operation*, but declares that the URL `/token` will be the one that the client should use to get the token. That information is used in OpenAPI, and then in the interactive API documentation systems.
+
+We will soon also create the actual path operation.
 
 !!! info
     If you are a very strict "Pythonista" you might dislike the style of the parameter name `tokenUrl` instead of `token_url`.

docs/en/docs/tutorial/security/oauth2-jwt.md

@@ -20,9 +20,9 @@ It is not encrypted, so, anyone could recover the information from the contents.
 
 But it's signed. So, when you receive a token that you emitted, you can verify that you actually emitted it.
 
-That way, you can create a token with an expiration of, let's say, 1 week. And then when the user comes back the next day with the token, you know she/he is still signed into your system.
+That way, you can create a token with an expiration of, let's say, 1 week. And then when the user comes back the next day with the token, you know she/he is still logged in to your system.
 
-And after a week, the token will be expired and the user will not be authorized and will have to sign in again to get a new token. And if the user (or a third party) tried to modify the token to change the expiration, you would be able to discover it, because the signatures would not match.
+After a week, the token will be expired and the user will not be authorized and will have to sign in again to get a new token. And if the user (or a third party) tried to modify the token to change the expiration, you would be able to discover it, because the signatures would not match.
 
 If you want to play with JWT tokens and see how they work, check <a href="https://jwt.io/" class="external-link" target="_blank">https://jwt.io</a>.
 
@@ -97,7 +97,7 @@ Import the tools we need from `passlib`.
 Create a PassLib "context". This is what will be used to hash and verify passwords.
 
 !!! tip
-    The PassLib context also has functionality to use different hashing algorithms, including deprecate old ones only to allow verifying them, etc.
+    The PassLib context also has functionality to use different hashing algorithms, including deprecated old ones only to allow verifying them, etc.
 
     For example, you could use it to read and verify passwords generated by another system (like Django) but hash any new passwords with a different algorithm like Bcrypt.
 

docs/en/docs/tutorial/security/simple-oauth2.md

@@ -36,7 +36,7 @@ They are normally used to declare specific security permissions, for example:
     In OAuth2 a "scope" is just a string that declares a specific permission required.
 
     It doesn't matter if it has other characters like `:` or if it is a URL.
-    
+
     Those details are implementation specific.
 
     For OAuth2 they are just strings.
@@ -166,7 +166,7 @@ For this simple example, we are going to just be completely insecure and return
     This is something that you have to do yourself in your code, and make sure you use those JSON keys.
 
     It's almost the only thing that you have to remember to do correctly yourself, to be compliant with the specifications.
-    
+
     For the rest, **FastAPI** handles it for you.
 
 ## Update the dependencies
@@ -177,7 +177,7 @@ We want to get the `current_user` *only* if this user is active.
 
 So, we create an additional dependency `get_current_active_user` that in turn uses `get_current_user` as a dependency.
 
-Both of these dependencies will just return an HTTP error if the user doesn't exists, or if is inactive.
+Both of these dependencies will just return an HTTP error if the user doesn't exist, or if is inactive.
 
 So, in our endpoint, we will only get a user if the user exists, was correctly authenticated, and is active: