7.1 Overview

The integration of Model Context Protocol (MCP) with oneM2M in Internet of Things (IoT) systems introduces unique security challenges that necessitate dedicated solutions to ensure secure interworking. MCP, designed for contextual data exchange and model-based interactions, enables advanced querying and resource access in IoT environments. However, when MCP clients seek to interact with oneM2M resources, such as creating, retrieving, updating, or deleting data stored in Common Service Entities (CSEs), potential vulnerabilities arise, including unauthorized access, data leakage, impersonation attacks, and integrity breaches. These risks stem from differences in the protocols' native security mechanisms: oneM2M relies on Access Control Policies (ACPs) and Application Entity (AE) identifiers for fine-grained authorization, while MCP does not define equivalent built-in controls for cross-protocol operations, leading to exposure if the mediator forwards requests using a shared oneM2M originator or AE identity for multiple MCP clients.

A security solution is essential to mitigate these issues by providing robust authentication, authorization, and message translation. This approach adopts a token-based authorization and authentication framework for MCP-side access while preserving oneM2M-native authentication and authorization toward the CSE. Each AI agent (via its MCP client) obtains a Personal Access Token (PAT), which encapsulates information about who owns the token, to whom it was issued, its lifetime, the MCP-related scopes granted to the token owner, and the oneM2M AE identifier required for interworking with oneM2M. PAT is a JWT-based OAuth access token [i.2][i.3] issued by a PAT Issuer (OAuth Authorization Server), with a single oneM2M-specific AE identifier binding claim. In this profile, that token-bound AE identifier denotes the actual oneM2M AE-ID of the oneM2M-facing IPE AE used by the MCP-IPE, with a one-to-one binding between an agent context, the token-bound AE identifier, and the corresponding AE identity toward the CSE. The PAT Issuer does not create that oneM2M-side identity; rather, it issues the PAT using deployment-established binding information for the already established oneM2M-facing IPE AE.

From the perspective of oneM2M security, the MCP-IPE acts as an interworking proxy entity (described in oneM2M TS-0033 [i.4]) at the MCP-oneM2M interworking boundary. Its oneM2M-facing side is realized as a oneM2M-facing IPE AE registered at the hosting CSE. It terminates the PAT at the MCP-IPE, applies deny-by-default admission limited to token-level eligibility and locally configured capability exposure policy, and only then issues ordinary oneM2M request primitives toward the CSE without forwarding the PAT. Those oneM2M requests are authenticated using oneM2M-side credential arrangements between the oneM2M-facing IPE AE of the MCP-IPE and the CSE. In this profile, the credential material for those arrangements is protected within a deployment-specific secure environment and secure storage function corresponding to the TS-0003 secure storage concept; that protected material is accessed only for authorized MCP-IPE operations and is not retrieved directly by the PAT Issuer or the CSE. TS-0003 already provides the secure storage, bootstrap credential configuration, remote provisioning, and association configuration concepts used for this oneM2M-facing side. In this profile, the token-bound AE identifier equals the AE-ID of that oneM2M-facing IPE AE used for the mediated request, so that the From value remains consistent with the authenticated identity checked by oneM2M impersonation-prevention procedures and the CSE continues to make its final authorization decision using its native security mechanisms as specified in oneM2M TS-0003 [i.5].

This report does not define a new authorization framework. Instead, it profiles the OAuth 2.1 Authorization Framework [i.6] already used in MCP deployments [i.7] for secure oneM2M interworking. It preserves interoperability with MCP implementations that support OAuth, while adding oneM2M-specific bindings for authentication and message translation.

The high-level security architecture for MCP-oneM2M interworking is designed around a proxy-mediated framework to ensure that AI agents can access oneM2M resources in a controlled way, while the AI system has no direct awareness of oneM2M. Key components include:

The solution described in this clause assumes a deployment in which the MCP-IPE operates as a remote MCP server and is reached by MCP clients over the HTTP transport. Single-user or purely local deployments (e.g. using the STDIO transport) can rely on simpler arrangements that are outside the scope of this security profile.