further adjustments to the authentication explanation

Signed-off-by: Mike Cobbett <[email protected]>

src/markdown-pages/docs/ecosystem/ecosystem-authentication.md

@@ -19,7 +19,7 @@ The following diagram shows the architecture for the authentication process:
 ![Galasa ecosystem architecture:](ecosystem-cluster-auth.svg)
 
 
-When a user logs into the Galasa Web UI via their browser, the Web UI contacts the Galasa API server which in turn talks to a Dex server, providing it with the user ID. The Dex server talks to an identity provider, for example GitHub or LDAP, to authenticate that user. If the user is successfully authenticated, the provider returns a bearer token to the Dex server which sends that token to Galasa API server. The token is then sent to the Galasa Web UI, which is stored in a cookie on the Web UI client, to be used in further interactions with the Galasa API server until the user logs out fo the web application, or the token expires.
+When a user logs into the Galasa Web UI via their browser, the Web UI contacts the Galasa API server which in turn talks to a Dex server, providing it with the user ID. The Dex server talks to an identity provider, for example GitHub or LDAP, to authenticate that user. If the user is successfully authenticated, Dex returns a bearer token to the Galasa API server, which in turn passes the token to the Galasa Web UI. The bearer token is then stored in a cookie by the web browser, to be used in further interactions with the Galasa Web UI until the user logs out of the web application, or the token expires.
 
 Once logged-in to the Web UI, the user can then create a new access token token (using the 'My Settings' page). This provides a secret access token which must be copied from the Web UI panel and made available to the `galasactl` command line tool. The access token can be placed in the `GALASA_TOKEN` property in the `galasactl.properties` file, or the `GALASA_TOKEN` environment variable.