diff --git a/architecture/additional_concepts/authentication.adoc b/architecture/additional_concepts/authentication.adoc
index 3f6c411a810c..0674c769db2b 100644
--- a/architecture/additional_concepts/authentication.adoc
+++ b/architecture/additional_concepts/authentication.adoc
@@ -88,22 +88,29 @@ the `system:anonymous` virtual user and the `system:unauthenticated` virtual
 group to the request. This allows the authorization layer to determine which
 requests, if any, an anonymous user is allowed to make.
 
+[[authentication-impersonation]]
 === Impersonation
-A request the OpenShift API may include an `"Impersonate-User"` header, which indicates that requester wants
-to have request handled as though it came from the specified user.  This can be done on the command line
-by passing the `--as=username` flag.
-
-Before UserA is allowed to impersonate UserB, UserA is first authenticated and then an authorization
-check is made to be sure UserA is allowed to "impersonate" the "user" named "UserB".  If UserA is requesting to 
-impersonate a service account (`system:serviceaccount:namespace:name`), we check to make sure that UserA can
-"impersonate" the "serviceaccount" named "name" in "namespace".  If he is disallowed, a 403 will be returned.
-
-By default, project admins and editors are allowed impersonate service accounts in their namespace.  There is 
-also a new group called `sudoers`.  That role allows a user to impersonate `system:admin`, which in turn has
-cluster-admin permissions.  This grants some protection against typos (but *not* security) for someone administering
-the cluster.  For example, `oc delete nodes --all` would be forbidden, but `oc delete nodes --all --as=system:admin`
-would be allowed.  You still have the power, but you have to mean it.  You can add a user to that group using
-`oadm policy add-cluster-role-to-user sudoer <username>`.
+A request to the {product-title} API may include an *Impersonate-User* header,
+which indicates that the requester wants to have the request handled as though
+it came from the specified user. This can be done on the command line by passing
+the `*--as=username*` flag.
+
+Before User A is allowed to impersonate User B, User A is first authenticated.
+Then, an authorization check occurs to ensure that User A is allowed to
+impersonate the user named User B. If User A is requesting to impersonate a
+service account (*system:serviceaccount:namespace:name*), {product-title} checks
+to ensure that User A can impersonate the *serviceaccount* named *name* in
+*namespace*. If the check fails, the request fails with a 403 (Forbidden) error
+code.
+
+By default, project administrators and editors are allowed to impersonate
+service accounts in their namespace. The *sudoers* role allows a user to
+impersonate *system:admin*, which in turn has cluster administrator permissions.
+This grants some protection against typos (but not security) for someone
+administering the cluster. For example, `oc delete nodes --all` would be
+forbidden, but `oc delete nodes --all --as=system:admin` would be allowed. You
+can add a user to that group using `oadm policy add-cluster-role-to-user sudoer
+<username>`.
 
 [[oauth]]