docs: update authentication docs

Signed-off-by: Felix Gateru <felix.gateru@gmail.com>

Author: felixgateru

docs/authentication.md

@@ -45,7 +45,7 @@ SuperMQ uses the `access_token` provided by Google only to fetch user informatio
 
 ## Authentication with SuperMQ keys
 
-By default, SuperMQ uses SuperMQ Thing secret for authentication. The Thing secret is a secret key that's generated at the Thing creation. In order to authenticate, the Thing needs to send its secret with the message. The way the secret is passed depends on the protocol used to send a message and differs from adapter to adapter. For more details on how this secret is passed around, please check out [messaging section][messaging]. This is the default SuperMQ authentication mechanism and this method is used if the composition is started using the following command:
+By default, SuperMQ uses SuperMQ Client secret for authentication. The Client secret is a secret key that's generated at the Client creation. In order to authenticate, the Client needs to send its secret with the message. The way the secret is passed depends on the protocol used to send a message and differs from adapter to adapter. For more details on how this secret is passed around, please check out [messaging section][messaging]. This is the default SuperMQ authentication mechanism and this method is used if the composition is started using the following command:
 
 ```bash
 docker-compose -f docker/docker-compose.yml up
@@ -59,52 +59,52 @@ In most of the cases, HTTPS, WSS, MQTTS or secure CoAP are secure enough. Howeve
 AUTH=x509 docker-compose -f docker/docker-compose.yml up -d
 ```
 
-Mutual authentication includes client-side certificates. Certificates can be generated using the simple script provided [here][ssl-makefile]. In order to create a valid certificate, you need to create SuperMQ thing using the process described in the [provisioning section][provision]. After that, you need to fetch created thing secret. Thing secret will be used to create x.509 certificate for the corresponding thing. To create a certificate, execute the following commands:
+Mutual authentication includes client-side certificates. Certificates can be generated using the simple script provided [here][ssl-makefile]. In order to create a valid certificate, you need to create SuperMQ client using the process described in the [provisioning section][provision]. After that, you need to fetch created client secret. Client secret will be used to create x.509 certificate for the corresponding client. To create a certificate, execute the following commands:
 
 ```bash
 cd docker/ssl
 make ca CN=<common_name> O=<organization> OU=<organizational_unit> emailAddress=<email_address>
 make server_cert CN=<common_name> O=<organization> OU=<organizational_unit> emailAddress=<email_address>
-make thing_cert THING_SECRET=<thing_secret> CRT_FILE_NAME=<cert_name> O=<organization> OU=<organizational_unit> emailAddress=<email_address>
+make client_cert CLIENT_SECRET=<client_secret> CRT_FILE_NAME=<cert_name> O=<organization> OU=<organizational_unit> emailAddress=<email_address>
 ```
 
 These commands use [OpenSSL][openssl] tool, so please make sure that you have it installed and set up before running these commands. The default values for Makefile variables are
 
 ```env
 CRT_LOCATION = certs
-THING_SECRET = d7cc2964-a48b-4a6e-871a-08da28e7883d
+CLIENT_SECRET = d7cc2964-a48b-4a6e-871a-08da28e7883d
 O = SuperMQ
 OU = supermq_ca
 EA = info@supermq.com
 CN = localhost
-CRT_FILE_NAME = thing
+CRT_FILE_NAME = client
 ```
 
-Normally, in order to get things running, you will need to specify only `THING_SECRET`. The other variables are not mandatory and the termination should work with the default values.
+Normally, in order to get clients running, you will need to specify only `CLIENT_SECRET`. The other variables are not mandatory and the termination should work with the default values.
 
 - Command `make ca` will generate a self-signed certificate that will later be used as a CA to sign other generated certificates. CA will expire in 3 years.
 - Command `make server_cert` will generate and sign (with previously created CA) server cert, which will expire after 1000 days. This cert is used as a SuperMQ server-side certificate in usual TLS flow to establish HTTPS or MQTTS connection.
-- Command `make thing_cert` will finally generate and sign a client-side certificate and private key for the thing.
+- Command `make client_cert` will finally generate and sign a client-side certificate and private key for the client.
 
-In this example `<thing_secret>` represents secret of the thing and `<cert_name>` represents the name of the certificate and key file which will be saved in `docker/ssl/certs` directory. Generated Certificate will expire after 2 years. The key must be stored in the x.509 certificate `CN` field. This script is created for testing purposes and is not meant to be used in production. We strongly recommend avoiding self-signed certificates and using a certificate management tool such as [Vault][vault] for the production.
+In this example `<client_secret>` represents secret of the client and `<cert_name>` represents the name of the certificate and key file which will be saved in `docker/ssl/certs` directory. Generated Certificate will expire after 2 years. The key must be stored in the x.509 certificate `CN` field. This script is created for testing purposes and is not meant to be used in production. We strongly recommend avoiding self-signed certificates and using a certificate management tool such as [Vault][vault] for the production.
 
 Once you have created CA and server-side cert, you can spin the composition using:
 
 ```bash
 AUTH=x509 docker-compose -f docker/docker-compose.yml up -d
 ```
 
-Then, you can create user and provision things and channels. Now, in order to send a message from the specific thing to the channel, you need to connect thing to the channel and generate corresponding client certificate using aforementioned commands. To publish a message to the channel, thing should send following request:
+Then, you can create user and provision clients and channels. Now, in order to send a message from the specific client to the channel, you need to connect client to the channel and generate corresponding client certificate using aforementioned commands. To publish a message to the channel, client should send following request:
 
 ### WSS
 
 ```javascript
 const WebSocket = require("ws");
 // Do not verify self-signed certificates if you are using one.
 process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";
-// Replace <channel_id> and <thing_secret> with real values.
+// Replace <channel_id> and <client_secret> with real values.
 const ws = new WebSocket(
-  "wss://localhost/ws/channels/<channel_id>/messages?authorization=<thing_secret>",
+  "wss://localhost/ws/channels/<channel_id>/messages?authorization=<client_secret>",
   // This is ClientOptions object that contains client cert and client key in the form of string. You can easily load these strings from cert and key files.
   {
     cert: `-----BEGIN CERTIFICATE-----....`,
@@ -127,21 +127,21 @@ As you can see, `Authorization` header does not have to be present in the HTTP r
 ### HTTPS
 
 ```bash
-curl -s -S -i --cacert docker/ssl/certs/ca.crt --cert docker/ssl/certs/<thing_cert_name>.crt --key docker/ssl/certs/<thing_cert_key>.key -X POST -H "Content-Type: application/senml+json" https://localhost/http/channels/<channel_id>/messages -d '[{"bn":"some-base-name:","bt":1.276020076001e+09, "bu":"A","bver":5, "n":"voltage","u":"V","v":120.1}, {"n":"current","t":-5,"v":1.2}, {"n":"current","t":-4,"v":1.3}]'
+curl -s -S -i --cacert docker/ssl/certs/ca.crt --cert docker/ssl/certs/<client_cert_name>.crt --key docker/ssl/certs/<client_cert_key>.key -X POST -H "Content-Type: application/senml+json" https://localhost/http/channels/<channel_id>/messages -d '[{"bn":"some-base-name:","bt":1.276020076001e+09, "bu":"A","bver":5, "n":"voltage","u":"V","v":120.1}, {"n":"current","t":-5,"v":1.2}, {"n":"current","t":-4,"v":1.3}]'
 ```
 
 ### MQTTS
 
 #### Publish
 
 ```bash
-mosquitto_pub -u <thing_id> -P <thing_secret> -t channels/<channel_id>/messages -h localhost -p 8883  --cafile docker/ssl/certs/ca.crt --cert docker/ssl/certs/<thing_cert_name>.crt --key docker/ssl/certs/<thing_cert_key>.key -m '[{"bn":"some-base-name:","bt":1.276020076001e+09, "bu":"A","bver":5, "n":"voltage","u":"V","v":120.1}, {"n":"current","t":-5,"v":1.2}, {"n":"current","t":-4,"v":1.3}]'
+mosquitto_pub -u <client_id> -P <client_secret> -t channels/<channel_id>/messages -h localhost -p 8883  --cafile docker/ssl/certs/ca.crt --cert docker/ssl/certs/<client_cert_name>.crt --key docker/ssl/certs/<client_cert_key>.key -m '[{"bn":"some-base-name:","bt":1.276020076001e+09, "bu":"A","bver":5, "n":"voltage","u":"V","v":120.1}, {"n":"current","t":-5,"v":1.2}, {"n":"current","t":-4,"v":1.3}]'
 ```
 
 #### Subscribe
 
 ```bash
-mosquitto_sub -u <thing_id> -P <thing_secret> --cafile docker/ssl/certs/ca.crt --cert docker/ssl/certs/<thing_cert_name>.crt --key docker/ssl/certs/<thing_cert_key>.key -t channels/<channel_id>/messages -h localhost -p 8883
+mosquitto_sub -u <client_id> -P <client_secret> --cafile docker/ssl/certs/ca.crt --cert docker/ssl/certs/<client_cert_name>.crt --key docker/ssl/certs/<client_cert_key>.key -t channels/<channel_id>/messages -h localhost -p 8883
 ```
 
 [jwt]: https://jwt.io/