Applications are primarily meant for human interaction, as opposed to APIs, which provide data to applications through a standardised messaging system.
The term application does not imply any particular implementation characteristics. For example, your application could be a native app that executes on a mobile device, a single-page app that executes on a browser, or a regular web app that executes on a server.
OAuth2 uses the client secret mechanism as a means of authorising an application; the software requests an access token. You might think of it as a secret passphrase that proves to the authentication server that the client application is authorised to make a request on behalf of the user.
An application requesting an access token has to know the client secret in order to gain the token. This prevents malicious, unauthorised apps from ever obtaining valid access tokens. The client secret prevents a service from giving out tokens to rogue applications. This client secret must be protected at all costs; if the secret is compromised, a new one must be generated and all authorised applications will have to be updated with the new client secret.
This process is not related to user authentication. We are only authorising an application to request access tokens. Authorisation and authentication are distinct. Users are authenticated (proven that they are whom they say they are), while applications are authorised (the app is allowed to use or access the resources).
To learn how to create applications and view the client secret, please visit our tutorial on this topic.