Fix minor typos in the 'Authorization Services' guide (#1700)

authorization_services/topics/auth-services-terminology.adoc

@@ -61,7 +61,7 @@ That is, you can create individual policies, then reuse them with different perm
 Policy providers are implementations of specific policy types. {project_name} provides built-in policies, backed by their corresponding
 policy providers, and you can create your own policy types to support your specific requirements.
 
-{project_name} provides a SPI (Service Provider Interface) that you can use to plug in your own policy provider implementations.
+{project_name} provides an SPI (Service Provider Interface) that you can use to plug in your own policy provider implementations.
 
 [[_overview_terminology_permission_ticket]]
 == Permission ticket

authorization_services/topics/policy-js-policy.adoc

@@ -74,8 +74,8 @@ if (identity.hasClientRole('my-client', 'my-client-role')) {
 }
 ```
 
-=== Checking for roles granted to an user
-To check for realm roles granted to an user:
+=== Checking for roles granted to a user
+To check for realm roles granted to a user:
 
 ```javascript
 const realm = $evaluation.getRealm();
@@ -85,7 +85,7 @@ if (realm.isUserInRealmRole('marta', 'role-a')) {
 }
 ```
 
-Or for client roles granted to an user:
+Or for client roles granted to a user:
 
 ```javascript
 const realm = $evaluation.getRealm();

authorization_services/topics/resource-server-default-config.adoc

@@ -45,7 +45,7 @@ This permission is a <<_permission_create_resource, resource-based permission>>,
 
 You can change the default configuration by removing the default resource, policy, or permission definitions and creating your own.
 
-The default resource is created with an **URI** that maps to any resource or path in your application using a **/*** pattern. Before creating your own resources, permissions and policies, make
+The default resource is created with a **URI** that maps to any resource or path in your application using a **/*** pattern. Before creating your own resources, permissions and policies, make
 sure the default configuration doesn't conflict with your own settings.
 
 [NOTE]

authorization_services/topics/resource-server-enable-authorization.adoc

@@ -68,7 +68,7 @@ Disables the evaluation of all policies and allows access to all resources.
 +
 * *Decision Strategy*
 +
-This configurations changes how the policy evaluation engine decides whether or not a resource or scope should be granted based on the outcome from all evaluated permissions. `Affirmative` means that at least one permission must evaluate to a positive decision in order grant access to a resource and its scopes. `Unanimous` means that all permissions must evaluate to a positive decision in order for the final decision to be also positive. As an example, if two permissions for a same resource or scope are in conflict (one of them is granting access and the other is denying access), the permission to the resource or scope will be granted if the choosen strategy is `Affirmative`. Otherwise, a single deny from any permission will also deny access to the resource or scope.
+This configurations changes how the policy evaluation engine decides whether or not a resource or scope should be granted based on the outcome from all evaluated permissions. `Affirmative` means that at least one permission must evaluate to a positive decision in order grant access to a resource and its scopes. `Unanimous` means that all permissions must evaluate to a positive decision in order for the final decision to be also positive. As an example, if two permissions for a same resource or scope are in conflict (one of them is granting access and the other is denying access), the permission to the resource or scope will be granted if the chosen strategy is `Affirmative`. Otherwise, a single deny from any permission will also deny access to the resource or scope.
 +
 * *Remote Resource Management*
 +

authorization_services/topics/service-authorization-obtaining-permission-uma.adoc

@@ -24,7 +24,7 @@ Resource owners are allowed to manage permissions to their resources and decide
 {project_name} is a UMA 2.0 compliant authorization server that provides most UMA capabilities.
 
 As an example, consider a user Alice (resource owner) using an Internet Banking Service (resource server) to manage her Bank Account (resource). One day, Alice decides
-to open her bank account to Bob (requesting party), a accounting professional. However, Bob should only have access to view (scope) Alice's account.
+to open her bank account to Bob (requesting party), an accounting professional. However, Bob should only have access to view (scope) Alice's account.
 
 As a resource server, the Internet Banking Service must be able to protect Alice's Bank Account. For that, it relies on {project_name}
 Resource Registration Endpoint to create a resource in the server representing Alice's Bank Account.

authorization_services/topics/service-authorization-obtaining-permission.adoc

@@ -92,7 +92,7 @@ Indicates that responses from the server should contain any permission granted b
 +
 If the authorization request does not map to any permission, a `403` HTTP status code is returned instead.
 
-Example of a authorization request when a client is seeking access to two resources protected by a resource server.
+Example of an authorization request when a client is seeking access to two resources protected by a resource server.
 
 [source,bash,subs="attributes+"]
 ----
@@ -105,7 +105,7 @@ curl -X POST \
   --data "permission=Resource B#Scope B"
 ----
 
-Example of a authorization request when a client is seeking access to any resource and scope protected by a resource server.
+Example of an authorization request when a client is seeking access to any resource and scope protected by a resource server.
 NOTE: This will not evaluate the permissions for all resources. Instead, the permissions for resources owned by the resource server, owned by the requesting user,
 and explicitly granted to the requesting user by other owners are evaluated.
 

authorization_services/topics/service-authorization-uma-authz-process.adoc

@@ -4,7 +4,7 @@
 In UMA, the authorization process starts when a client tries to access a UMA protected resource server.
 
 A UMA protected resource server expects a bearer token in the request where the token is an RPT. When a client requests
-a resource at the resource server without a RPT:
+a resource at the resource server without an RPT:
 
 .Client requests a protected resource without sending an RPT
 ```bash

authorization_services/topics/service-protection-resources-api-papi.adoc

@@ -41,7 +41,7 @@ curl -v -X POST \
   }'
 ----
 
-By default, the owner of a resource is the resource server. If you want to define a different owner, such as an
+By default, the owner of a resource is the resource server. If you want to define a different owner, such as a
 specific user, you can send a request as follows:
 
 [source,bash,subs="attributes+"]