{"data":{"slug":"opc-ua-web-integration-json-websockets","title":"OPC UA Web Integration: HTTPS, JSON and WebSocket Mappings","summary":"Traditional OPC UA runs over binary TCP on port 4840 — a protocol that browsers, serverless functions, and web applications cannot speak natively.","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/opc-ua-web-integration-json-websockets","markdown_url":"https://wiki.aspotomasyon.com/article/opc-ua-web-integration-json-websockets.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/opc-ua-web-integration-json-websockets","published":"2026-08-11T13:05:19+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":4,"word_count":798,"image":"https://wiki.aspotomasyon.com/assets/social/opc-ua-web-integration-json-websockets-06bd3c6615d4.png","html":"<p>Traditional OPC UA runs over binary TCP on port 4840 — a protocol that browsers, serverless functions, and web applications cannot speak natively. As industrial data moves into web dashboards, mobile apps, and cloud services, the OPC Foundation has standardized web-friendly transports: <strong>OPC UA over HTTPS/JSON</strong> (Part 6 mapping) and the <strong>WebSocket</strong> transport (Part 6/Part 14 WebSocket mapping, released with OPC 10000-14 amendments). These mappings make OPC UA data accessible from any platform that can speak HTTP and JSON — without custom protocol stacks.</p><figure class=\"article-figure\"><img src=\"https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-context.svg\" width=\"1100\" height=\"460\" loading=\"lazy\" decoding=\"async\" alt=\"A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do.\"><figcaption>A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do. <a href=\"https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-context.svg\" target=\"_blank\" rel=\"noopener\">View full size</a></figcaption></figure>\n\n<h2 id=\"why-web-mappings-exist\">Why Web Mappings Exist</h2>\n\n<p>Three forces drive web transport support:</p>\n\n<ul>\n  <li><strong>Browser access</strong> — plant dashboards, quality portals, and maintenance apps that run in browsers cannot open raw TCP sockets; HTTPS and WebSockets are the browser's native channels.</li>\n  <li><strong>Cloud and serverless</strong> — functions-as-a-service and managed platforms typically restrict egress to HTTPS; a JSON mapping lets them consume UA data through standard web APIs.</li>\n  <li><strong>Proxies and gateways</strong> — HTTPS rides through corporate proxies, CDNs, and load balancers that would block or mangle binary TCP streams.</li>\n</ul>\n\n<h2 id=\"the-mappings-at-a-glance\">The Mappings at a Glance</h2>\n\n<table>\n  <thead>\n    <tr><th>Transport</th><th>Encoding</th><th>Characteristics</th></tr>\n  </thead>\n  <tbody>\n    <tr><td>OPC UA Binary over TCP (classic)</td><td>UA Binary</td><td>Lowest overhead, lowest latency; native UA features; port 4840.</td></tr>\n    <tr><td>OPC UA over HTTPS (REST-style)</td><td>UA JSON (Part 6 mapping)</td><td>Request/response over standard HTTP; uses standard web auth (OAuth 2.0/JWT); goes through any HTTPS-capable path.</td></tr>\n    <tr><td>OPC UA over WebSocket</td><td>UA JSON or UA Binary</td><td>Full-duplex channel for subscriptions/push; browsers and mobile native; supports the same session model over WS.</td></tr>\n  </tbody>\n</table>\n\n<p>The JSON encoding covers the core services: browse, read, write, call methods, and create subscriptions with monitored items; the event and alarm model also has JSON representations. Payloads are larger than binary, but for web clients the transport convenience outweighs the overhead in most cases.</p>\n\n<h2 id=\"security-over-web-transports\">Security Over Web Transports</h2>\n\n<p>HTTPS and WebSocket mappings reuse the web's security stack instead of UA's native certificate handshake:</p>\n\n<ul>\n  <li><strong>TLS</strong> — transport security comes from TLS as in any web service; the server presents a normal web certificate.</li>\n  <li><strong>Authentication</strong> — OAuth 2.0 bearer tokens (JWT) are the standard mechanism: the client obtains a token from an identity provider and the UA server validates it. This fits enterprise identity (Azure AD, Keycloak) and avoids per-client X.509 management.</li>\n  <li><strong>Authorization</strong> — user roles map onto the UA server's access model: which nodes the authenticated user may read, write, or execute.</li>\n  <li><strong>Deployment</strong> — because it is plain HTTPS, the server can sit behind a reverse proxy with WAF rules, rate limiting, and standard monitoring.</li>\n</ul>\n\n<p>The trade-off: the rich UA certificate trust model (application-level identity) is replaced by web identity — appropriate for internet-facing or IT-managed paths, less so for direct plant-floor device-to-device traffic.</p>\n\n<h2 id=\"practical-implementation-patterns\">Practical Implementation Patterns</h2>\n\n<ul>\n  <li><strong>Dashboards and portals</strong> — a web app subscribes over WebSocket to a UA server in the DMZ and renders live values; no thick client, no open inbound ports beyond HTTPS.</li>\n  <li><strong>Mobile maintenance</strong> — field staff read machine status and acknowledge alarms through a mobile web app using the same JSON endpoints.</li>\n  <li><strong>Cloud ingestion</strong> — a serverless function polls (or receives webhooks from) the UA-over-HTTPS endpoint and pushes into the data lake — a pattern that fits provider-managed platforms perfectly.</li>\n  <li><strong>System integration</strong> — enterprise systems (ERP, quality) that already speak REST consume plant data through the JSON mapping without new middleware.</li>\n</ul>\n\n<h2 id=\"when-to-prefer-classic-binary\">When to Prefer Classic Binary</h2>\n\n<p>Web mappings are not a replacement for binary UA everywhere. For high-rate process data between plant systems, for device-level connectivity, and where low latency matters, UA Binary over TCP remains the right choice. The JSON/WebSocket endpoints are the <em>demilitarized zone</em> face of the same data: secure, manageable, web-native — with the understanding that payload overhead and TLS handshakes make them better for human-facing and moderate-rate machine-to-web traffic than for high-frequency streaming.</p>\n\n<h2 id=\"summary\">Summary</h2>\n\n<p>OPC UA's HTTPS/JSON and WebSocket mappings extend the UA data model to the web: standard TLS, OAuth 2.0 identity, JSON payloads, and full-duplex subscriptions. Use them at the web edge of the architecture — dashboards, portals, mobile, and cloud ingestion — while keeping UA Binary for plant-floor integration. The same information model, the same semantics, with the transport that fits the audience.</p><section class=\"engineering-check\"><h2 id=\"apply-this-to-your-project\">Apply this to your project</h2><ul><li>Record the endpoint, supported security policies, application identity, certificate expiry, and user permissions.</li><li>Verify the value, engineering unit, StatusCode, and source timestamp together at the receiving application.</li><li>Test disconnection and recovery with representative subscriptions; preserve evidence of any data gaps or repeated values.</li></ul><p><a href=\"https://wiki.aspotomasyon.com/guides\">Follow an ASP project guide</a> to connect the fundamentals with implementation and acceptance.</p></section><figure class=\"article-figure\"><img src=\"https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-review.svg\" width=\"1100\" height=\"460\" loading=\"lazy\" decoding=\"async\" alt=\"Engineering review sequence: Discover → Authenticate → Subscribe → Recover. Keep the recorded evidence with the accepted configuration.\"><figcaption>Engineering review sequence: Discover → Authenticate → Subscribe → Recover. Keep the recorded evidence with the accepted configuration. <a href=\"https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-review.svg\" target=\"_blank\" rel=\"noopener\">View full size</a></figcaption></figure><h2 id=\"primary-references-and-further-reading\">Primary references and further reading</h2><p>Use the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.</p><ul><li><a href=\"https://reference.opcfoundation.org/specs/OPC-10000-4/\" rel=\"noopener noreferrer\" target=\"_blank\">OPC Foundation — OPC UA Part 4: Services</a></li><li><a href=\"https://reference.opcfoundation.org/specs/OPC-10000-2/\" rel=\"noopener noreferrer\" target=\"_blank\">OPC Foundation — OPC UA Part 2: Security Model</a></li></ul><!-- asp-editorial-202609 -->","markdown":"# OPC UA Web Integration: HTTPS, JSON and WebSocket Mappings\n\n> Traditional OPC UA runs over binary TCP on port 4840 — a protocol that browsers, serverless functions, and web applications cannot speak natively.\n\n- Canonical URL: https://wiki.aspotomasyon.com/article/opc-ua-web-integration-json-websockets\n- Publisher: ASP OTOMASYON A.Ş. (ASP OTOMASYON Wiki)\n- Category: OPC Solutions\n- Published: 2026-08-11 · Updated: 2026-09-13\n- Reading time: 4 min · Language: English\n\nTraditional OPC UA runs over binary TCP on port 4840 — a protocol that browsers, serverless functions, and web applications cannot speak natively. As industrial data moves into web dashboards, mobile apps, and cloud services, the OPC Foundation has standardized web-friendly transports: **OPC UA over HTTPS/JSON** (Part 6 mapping) and the **WebSocket** transport (Part 6/Part 14 WebSocket mapping, released with OPC 10000-14 amendments). These mappings make OPC UA data accessible from any platform that can speak HTTP and JSON — without custom protocol stacks.\n\n![A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do.](https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-context.svg)\n\n*A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do.*\n\n## Why Web Mappings Exist\n\nThree forces drive web transport support:\n\n- **Browser access** — plant dashboards, quality portals, and maintenance apps that run in browsers cannot open raw TCP sockets; HTTPS and WebSockets are the browser's native channels.\n- **Cloud and serverless** — functions-as-a-service and managed platforms typically restrict egress to HTTPS; a JSON mapping lets them consume UA data through standard web APIs.\n- **Proxies and gateways** — HTTPS rides through corporate proxies, CDNs, and load balancers that would block or mangle binary TCP streams.\n\n## The Mappings at a Glance\n\n| Transport | Encoding | Characteristics |\n| --- | --- | --- |\n| OPC UA Binary over TCP (classic) | UA Binary | Lowest overhead, lowest latency; native UA features; port 4840. |\n| OPC UA over HTTPS (REST-style) | UA JSON (Part 6 mapping) | Request/response over standard HTTP; uses standard web auth (OAuth 2.0/JWT); goes through any HTTPS-capable path. |\n| OPC UA over WebSocket | UA JSON or UA Binary | Full-duplex channel for subscriptions/push; browsers and mobile native; supports the same session model over WS. |\n\nThe JSON encoding covers the core services: browse, read, write, call methods, and create subscriptions with monitored items; the event and alarm model also has JSON representations. Payloads are larger than binary, but for web clients the transport convenience outweighs the overhead in most cases.\n\n## Security Over Web Transports\n\nHTTPS and WebSocket mappings reuse the web's security stack instead of UA's native certificate handshake:\n\n- **TLS** — transport security comes from TLS as in any web service; the server presents a normal web certificate.\n- **Authentication** — OAuth 2.0 bearer tokens (JWT) are the standard mechanism: the client obtains a token from an identity provider and the UA server validates it. This fits enterprise identity (Azure AD, Keycloak) and avoids per-client X.509 management.\n- **Authorization** — user roles map onto the UA server's access model: which nodes the authenticated user may read, write, or execute.\n- **Deployment** — because it is plain HTTPS, the server can sit behind a reverse proxy with WAF rules, rate limiting, and standard monitoring.\n\nThe trade-off: the rich UA certificate trust model (application-level identity) is replaced by web identity — appropriate for internet-facing or IT-managed paths, less so for direct plant-floor device-to-device traffic.\n\n## Practical Implementation Patterns\n\n- **Dashboards and portals** — a web app subscribes over WebSocket to a UA server in the DMZ and renders live values; no thick client, no open inbound ports beyond HTTPS.\n- **Mobile maintenance** — field staff read machine status and acknowledge alarms through a mobile web app using the same JSON endpoints.\n- **Cloud ingestion** — a serverless function polls (or receives webhooks from) the UA-over-HTTPS endpoint and pushes into the data lake — a pattern that fits provider-managed platforms perfectly.\n- **System integration** — enterprise systems (ERP, quality) that already speak REST consume plant data through the JSON mapping without new middleware.\n\n## When to Prefer Classic Binary\n\nWeb mappings are not a replacement for binary UA everywhere. For high-rate process data between plant systems, for device-level connectivity, and where low latency matters, UA Binary over TCP remains the right choice. The JSON/WebSocket endpoints are the *demilitarized zone* face of the same data: secure, manageable, web-native — with the understanding that payload overhead and TLS handshakes make them better for human-facing and moderate-rate machine-to-web traffic than for high-frequency streaming.\n\n## Summary\n\nOPC UA's HTTPS/JSON and WebSocket mappings extend the UA data model to the web: standard TLS, OAuth 2.0 identity, JSON payloads, and full-duplex subscriptions. Use them at the web edge of the architecture — dashboards, portals, mobile, and cloud ingestion — while keeping UA Binary for plant-floor integration. The same information model, the same semantics, with the transport that fits the audience.\n\n## Apply this to your project\n\n- Record the endpoint, supported security policies, application identity, certificate expiry, and user permissions.\n- Verify the value, engineering unit, StatusCode, and source timestamp together at the receiving application.\n- Test disconnection and recovery with representative subscriptions; preserve evidence of any data gaps or repeated values.\n\n[Follow an ASP project guide](https://wiki.aspotomasyon.com/guides) to connect the fundamentals with implementation and acceptance.\n\n![Engineering review sequence: Discover → Authenticate → Subscribe → Recover. Keep the recorded evidence with the accepted configuration.](https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-review.svg)\n\n*Engineering review sequence: Discover → Authenticate → Subscribe → Recover. Keep the recorded evidence with the accepted configuration.*\n\n## Primary references and further reading\n\nUse the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.\n\n- [OPC Foundation — OPC UA Part 4: Services](https://reference.opcfoundation.org/specs/OPC-10000-4/)\n- [OPC Foundation — OPC UA Part 2: Security Model](https://reference.opcfoundation.org/specs/OPC-10000-2/)\n\n---\n\nCite the canonical article: https://wiki.aspotomasyon.com/article/opc-ua-web-integration-json-websockets (OPC UA Web Integration: HTTPS, JSON and WebSocket Mappings, ASP OTOMASYON, updated 2026-09-13).\n","headings":[{"id":"why-web-mappings-exist","title":"Why Web Mappings Exist"},{"id":"the-mappings-at-a-glance","title":"The Mappings at a Glance"},{"id":"security-over-web-transports","title":"Security Over Web Transports"},{"id":"practical-implementation-patterns","title":"Practical Implementation Patterns"},{"id":"when-to-prefer-classic-binary","title":"When to Prefer Classic Binary"},{"id":"summary","title":"Summary"},{"id":"apply-this-to-your-project","title":"Apply this to your project"},{"id":"primary-references-and-further-reading","title":"Primary references and further reading"}],"faq":[],"references":[{"name":"OPC Foundation — OPC UA Part 4: Services","url":"https://reference.opcfoundation.org/specs/OPC-10000-4/"},{"name":"OPC Foundation — OPC UA Part 2: Security Model","url":"https://reference.opcfoundation.org/specs/OPC-10000-2/"}],"related":[{"slug":"opc-ua-protocol-overview","title":"OPC UA Protocol Overview","summary":"OPC Unified Architecture (OPC UA) , defined by IEC 62541, is the platform-independent, service-oriented architecture for secure, reliable data exchange in…","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/opc-ua-protocol-overview","markdown_url":"https://wiki.aspotomasyon.com/article/opc-ua-protocol-overview.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/opc-ua-protocol-overview","published":"2026-05-12T12:47:31+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":4,"word_count":873,"image":"https://wiki.aspotomasyon.com/assets/social/opc-ua-protocol-overview-eae98061a685.png"},{"slug":"rest-apis-for-industrial-automation","title":"REST APIs for Industrial Automation — Bridging OT and IT","summary":"REST APIs (Representational State Transfer Application Programming Interfaces) have become the standard method for integrating industrial automation systems…","category":{"slug":"modern-connectivity","name":"Modern Connectivity"},"url":"https://wiki.aspotomasyon.com/article/rest-apis-for-industrial-automation","markdown_url":"https://wiki.aspotomasyon.com/article/rest-apis-for-industrial-automation.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/rest-apis-for-industrial-automation","published":"2026-05-13T11:58:29+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":8,"word_count":1562,"image":"https://wiki.aspotomasyon.com/assets/social/rest-apis-for-industrial-automation-08df1b5c206b.png"},{"slug":"highbyte-intelligence-hub-industrial-dataops","title":"HighByte Intelligence Hub: Industrial DataOps","summary":"Industrial organizations face a persistent and expensive data challenge: manufacturing operations generate massive volumes of data from PLCs, DCS systems…","category":{"slug":"digital-transformation","name":"Digital Transformation"},"url":"https://wiki.aspotomasyon.com/article/highbyte-intelligence-hub-industrial-dataops","markdown_url":"https://wiki.aspotomasyon.com/article/highbyte-intelligence-hub-industrial-dataops.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/highbyte-intelligence-hub-industrial-dataops","published":"2026-05-13T12:07:56+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":8,"word_count":1654,"image":"https://wiki.aspotomasyon.com/assets/social/highbyte-intelligence-hub-industrial-dataops-d14228111de7.png"},{"slug":"opc-da-to-ua-migration-guide","title":"Migrating from OPC DA to OPC UA","summary":"Migrating from OPC DA to OPC UA is one of the most common infrastructure projects in industrial IT. OPC DA (Data Access) has served industry for more than two…","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/opc-da-to-ua-migration-guide","markdown_url":"https://wiki.aspotomasyon.com/article/opc-da-to-ua-migration-guide.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/opc-da-to-ua-migration-guide","published":"2026-08-06T12:26:37+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":5,"word_count":999,"image":"https://wiki.aspotomasyon.com/assets/social/opc-da-to-ua-migration-guide-4dc7a9d57cd5.png"}],"citation":"ASP OTOMASYON. OPC UA Web Integration: HTTPS, JSON and WebSocket Mappings. Updated 2026-09-13. https://wiki.aspotomasyon.com/article/opc-ua-web-integration-json-websockets"}}