OAuth 2.0 Protocol
OAuth stands for Open Authorization (not authentication). "2.0" refers to the second (and current) generation. It is an open standard, used by Microsoft, Google and many other companies. OAuth 2.0 is related to, but distinct from, OpenID Connect. This protocol is used to allow defined access between web or desktop applications. It can be configured for authenticating specific users or to verify application credentials (with no user interaction required).
To put it very simply, OAuth 2.0 is a standard that uses a third party provider to facilitate access to tokens.
While configuring OAuth 2.0, you can define the specific protected resources that can be accessed and for how long that access will last. OAuth 2.0 supports several flows, but VTScada currently supports these two:
- Authorization Code flow - On behalf of a user.
- Client Credentials flow - On behalf of an application (server-to-server).
If using OAuth 2.0 ensure that all servers are using the same VTScada version 12.0, 12.1 or 12.2. OAuth tokens will not be handled properly if your servers run a mix of different versions.
OAuth 2.0 Terms & Definitions
| Terminology | OAuth 2.0 Definition |
| OAuth | "Open Authorization", OAuth 2.0 specification as defined in RFC 6749. |
| Authorization Code flow | As defined in RFC 6749, this flow allows a client to obtain an access token on behalf of a user via an authorization code. |
| Client Credentials flow | As defined in RFC 6749, this flow enables a client to obtain an access token using only its own credentials, without user involvement. |
| Client ID | A public identifier of the client application. |
| Client Secret | A confidential key for client authentication. The application and the authenticating server both confidentially know the secret. |
| Resource | What you want access to. For example, a user may want access to an email service. An application may want access to a device status or analytics. |
| Resource Provider | Source from which a resource is offered. |
| Resource Server | Server where access tokens are expected to be used. |
| Resource Owner | An entity registered with the resource provider to which specific resources are assigned. For example, a user registered email. |
| OAuth 2.0 Provider | The third party that vouches for the user or application. OAuth 2.0 providers and VTScada engage in protected communication, and the OAuth 2.0 provider authenticates and enables token access. |
| OAuth 2.0 Grant | The consent given by a resource owner for a specific set of permissions to be given to a third-party application registered with the OAuth 2.0 provider. A token is tied to the grant. In Authorization Code flow, the bearer of the grant is the account that will be used during normal operation and requires the scopes you are defining as allowed for use by VTScada (ie. reply email.) |
| User Agent | Often a web browser. Used as a means of confirming the resource owner’s credentials during the OAuth 2.0 consent process. This browser provides a means for the credentials to be sent directly to the OAuth 2.0 provider without passing by the application which is requesting access to the resources. For VTScada, this is the users default web browser. |
| OAuth 2.0 Provider Authorization Endpoint | A publicly available REST endpoint offered by the OAuth 2.0 provider. This is used to confirm the resource owner credentials during an access request by a third-party application. |
| OAuth 2.0 Provider Token Endpoint | A publicly available REST endpoint offered by the OAuth 2.0 provider. This is where a third-party application can acquire the tokens required to access the resource owner’s protected resources. |
| Redirect URI | URL identifying a server registered as a potential system to receive the single use code during the OAuth 2 consent flow. There may be multiple redirect URIs registered for a single third-party application registration. Due to the handling of the communication during a consent operation, the redirect URI needs only be resolvable by the system which is running the user agent. |
| Access Token | A short-lived token that is exchanged by a third-party application when attempting to access a resource owner’s resources. |
| Refresh Token | A longer-lived token that permits the third-party application to acquire a new access token without requiring the user provide consent each time. The permissions given for the new access token are the same as the previous. This token can be invalidated by the resource owner when desired. |
VTScada references RFC 6749 for OAuth 2.0 Terms and Definitions. Not all OAuth 2.0 providers adhere strictly to this standard, so while you will see these terms while configuring VTScada, your chosen OAuth 2.0 Provider might use different jargon. See Common Provider Tips for provider-specific cross-referencing and setup guidance.
Third-Party OAuth 2.0 Providers
VTScada does not recommend any specific service providers over others. There are many providers available. The features they offer, the quality of their services and the cost of their services are ever changing and outside of VTScada's control. Select providers that work best for you and remain vigilant about the service they provide.
These are the third-parties that are responsible for:
- Verifying a user login
- managing client IDs/secrets
- Issuing access tokens and refresh tokens
- Enforcing scopes and permissions
| Service Provider | URL | Used for... |
| Microsoft Entra ID | https://entra.microsoft.com | Enterprise identity & access management. OAuth 2.0 and OpenID Connect provider. |
| Microsoft AAD | https://aad.portal.azure.com | Absorbed into Entra ID in 2023. Still accessible but with less features. |
| Google Cloud | https://console.cloud.google.com | Alphabet's OAuth 2.0 Provider. Not recommended for Client Credentials flow. |
| Auth0 | https://auth0.com | Specialized identity-as-a-service platform. |
| Okta | https://okta.com | Enterprise-focused identity & access platform |
| LogTo | https://logto.io | Open-source identity provider designed for modern application frameworks. |
