# OPC UA Web Integration: HTTPS, JSON and WebSocket Mappings

> Traditional OPC UA runs over binary TCP on port 4840 — a protocol that browsers, serverless functions, and web applications cannot speak natively.

- Canonical URL: https://wiki.aspotomasyon.com/article/opc-ua-web-integration-json-websockets
- Publisher: ASP OTOMASYON A.Ş. (ASP OTOMASYON Wiki)
- Category: OPC Solutions
- Published: 2026-08-11 · Updated: 2026-09-13
- Reading time: 4 min · Language: English

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: **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.

![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)

*A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do.*

## Why Web Mappings Exist

Three forces drive web transport support:

- **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.
- **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.
- **Proxies and gateways** — HTTPS rides through corporate proxies, CDNs, and load balancers that would block or mangle binary TCP streams.

## The Mappings at a Glance

| Transport | Encoding | Characteristics |
| --- | --- | --- |
| OPC UA Binary over TCP (classic) | UA Binary | Lowest overhead, lowest latency; native UA features; port 4840. |
| 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. |
| 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. |

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.

## Security Over Web Transports

HTTPS and WebSocket mappings reuse the web's security stack instead of UA's native certificate handshake:

- **TLS** — transport security comes from TLS as in any web service; the server presents a normal web certificate.
- **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.
- **Authorization** — user roles map onto the UA server's access model: which nodes the authenticated user may read, write, or execute.
- **Deployment** — because it is plain HTTPS, the server can sit behind a reverse proxy with WAF rules, rate limiting, and standard monitoring.

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.

## Practical Implementation Patterns

- **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.
- **Mobile maintenance** — field staff read machine status and acknowledge alarms through a mobile web app using the same JSON endpoints.
- **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.
- **System integration** — enterprise systems (ERP, quality) that already speak REST consume plant data through the JSON mapping without new middleware.

## When to Prefer Classic Binary

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 *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.

## Summary

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.

## Apply this to your project

- Record the endpoint, supported security policies, application identity, certificate expiry, and user permissions.
- Verify the value, engineering unit, StatusCode, and source timestamp together at the receiving application.
- Test disconnection and recovery with representative subscriptions; preserve evidence of any data gaps or repeated values.

[Follow an ASP project guide](https://wiki.aspotomasyon.com/guides) to connect the fundamentals with implementation and acceptance.

![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)

*Engineering review sequence: Discover → Authenticate → Subscribe → Recover. Keep the recorded evidence with the accepted configuration.*

## Primary references and further reading

Use the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.

- [OPC Foundation — OPC UA Part 4: Services](https://reference.opcfoundation.org/specs/OPC-10000-4/)
- [OPC Foundation — OPC UA Part 2: Security Model](https://reference.opcfoundation.org/specs/OPC-10000-2/)

---

Cite 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).