We're currently sending our customer's VTScada e-mail alarms through a dreamhost mailserver but need to switch that to our customer's Microsoft365 mailserver with OAuth 2.0.

Their ISP has given us all the credentials we need. All that's missing is our redirect URI & certificate.

Is there anyone here who can baby step us through those steps? I've been reading & re-reading the VTScada help for days, as well as general stuff online re: OAuth 2.0 and am getting more & more lost the more I read.

As one of the devs responsible for the VTScada implementation of OAuth I take some of the blame for this. In my defence the subject matter is quite complex.

There are two things here, the redirect URI(s) and the TLS certificates associated with those redirect URI(s).

The redirect URI(s) are a list of endpoints on your VTScada Servers that the identity provider, e.g. MS365, can use to return the authorization code after the user has consented (authenticated and approved usage) to the OAuth request.

For each VTScada server you want to use as a possible recipient of the redirect message from the identity provider, it MUST have a TLS certificate (with the appropriate info) and the redirect URI for each VTScada server MUST be listed both in the identity provider configuration (step 8 of the MS365 setup here) and the VTScada OAuth 2.0 Configuration (Part 2, Step 10 here)

As an example, imagine you have a VTScada Server with the FQDN of "scada1.mycompany.com". You would need a TLS certificate with the FQDN appearing in either the "Subject" field or as a DNS entry in the "Subject alternative Name" field. The certificate has to be acceptable to the identity provider, which for MS365 means that it MUST be a publicly Certificate Authority (CA) issued certificate, e.g. from a pay-for provider, or a free CA such as Let's Encrypt. Additional VTScada servers, e.g. "scada2.mycompany.com" would require their own certificate with their respective FQDN in the appropriate fields.

The certificate(s) (and associated private key(s)) would be installed on the VTScada server(s). See the help section starting here for info about certificates.

The redirect URI for the VTScada server is then formed from the server FQDN and the fixed element of the redirect URL, e.g. "https://scada1.mycompany.com//vtscada/oauth/return" and is added as above to both the MS365 and VTScada configuration.

Thanks Graham for connecting around this.

With regards to the certificate can you provide some details on how to process a certificate once it's signed? I got lost when the VTScada help referred me to Microsoft & the link provided tried to sell me a Windows upgrade.

With regards to the URI's URL, can this be private to the machine that's sending alarms? I'd like to use http://hostname/vtscada/oauth/return/ for this. This VTScada system is small, running on a single PC. Securing & maintaining a publicly accessible web-server is asking a lot.

I misstated the position slightly in my previous answer, the VTScada certificate does NOT have to be a publicly trusted one, a private certificate can be used.

There's no need to run a public VTScada server as the interactions are between the user's browser (usually running on the same machine as VTScada) and VTScada or the browser and the Identity Provider (IDP), i.e. MS 365.

VTScada does need to be able to connect to the IDP though, which will usually be an internal -> external connection so must be permitted by any firewalls. It's a regular HTTPS connection though, nothing special.

The VTScada certificate must be acceptable to the user's browser, i.e. "Trusted", so either a "public" certificate that's automagically trusted or a private certificate that requires the browser to be configured to trust the cert.