Overview
At Nopan, authentication and authorization are core to secure machine-to-machine (M2M) communication. This guide walks through how clients authenticate, how tokens are issued and validated, and how requests are signed.
We use layered security approach to authenticate and authorize clients. These layers work together to ensure secure transport, validate client identity, and protect request integrity. Authentication and authorization systems are based on the following parts:
- Mutual TLS (mTLS) — transport‑level client authentication
- OAuth access token — expiring token-based authorization
- HTTP Message Signatures (RFC 9421) — ensures request integrity verification
Mutual TLS (mTLS)
mTLS provides client authentication at the transport level. Nopan requires all external clients to present a valid X.509 certificate signed by a trusted CA.
TLS 1.3 is required by default
Nopan requires TLS 1.3 for all connections to production systems. TLS 1.2 may be accepted as an exception in limited cases.
TLS 1.3 improves security, reduces latency, and removes outdated cryptographic algorithms.
Ensure your client libraries and environments support TLS 1.3 during mTLS handshake.
OAuth Access Token
All API requests must include a valid OAuth 2.0 Bearer token. Tokens are issued after successful client credential authentication.
HTTP Message Signatures (RFC 9421)
To protect request integrity, Nopan requires clients to include HTTP message signatures.
Authentication Flow Diagram
The following diagram shows how these layers work together during a typical API interaction:
Technical Context
Please refer to the authentication-article-specific guidelines for integration tips and further details: