OAuth and octoplant communication workflow
This topic explains how octoplant integrates with OAuth for secure authentication and communication. It outlines the participant interaction in during OAuth sign-in process in different network scenarios.
Scenario 1: Direct communication between octoplant server and client (each in the same network)
This workflow explains the runtime OAuth login flow between octoplant client, octoplant server, ID provider, and DNS, in a same-network scenario, with FQDN and certificates as prerequisites.
In this example, the Configuration name in the Server configuration settings is Svr.demo.com.
Scenario 2: Indirect communication between octoplant server and client (each in different networks)
This workflow explains runtime OAuth login flow between octoplant client, octoplant server, ID provider, DNS, and a CSC-Gateway in a separated-network scenario:
- CSC Gateway forwards/routes HTTPS traffic between networks.
- An additional DNS server in separated network and adjustment of matching table is required.
- A secure certificate needs to be implemented on the octoplant server.
- The client resolves the server FQDN to the gateway, not the server IP.
- The client never queries the global DNS. The global DNS is relevant only as configuration context for the server network.
- In this example, the Configuration name in the Server configuration settings is Svr.demo.com.
Related topics