IDaaS machine-to-machine (M2M) federation lets your services and devices exchange long-lived infrastructure credentials—certificates, OIDC tokens, and cloud instance signatures—for short-lived Access Tokens, removing the need to store or rotate static credentials in your workloads.
IDaaS supports three federated credential providers: Private Certificate Authority (PCA), OpenID Connect (OIDC), and PKCS#7. Each maps to a different trust anchor that your environment already provides.
Choose a provider
| Environment or infrastructure | Recommended provider |
|---|---|
| You operate your own PKI or certificate authority | PCA |
| Your service runs in Kubernetes, a CI/CD pipeline, GitHub Actions, or a cloud VM with OIDC support | OIDC |
| Your service runs on Alibaba Cloud ECS or ECI, or Amazon EC2 | PKCS#7 |
PCA federated credential provider
If your organization already operates a Private Certificate Authority, use PCA federation to let PCA-signed JWT tokens act as the credential for obtaining an Access Token from IDaaS—no static secrets needed.
Key concepts
PCA (Private Certificate Authority) is a fully managed service for creating and managing private digital certificates for internal enterprise use.
The trust chain flows as follows: your service presents a JWT signed by its PCA client certificate → IDaaS validates the signature against the root certificate and intermediate certificate list you registered → IDaaS issues an Access Token.
Use cases
Large-scale device connectivity: Provision unique digital certificates to IoT and connected-vehicle devices, enabling device identity authentication and bidirectional secure communication (for example, over MQTT).
Software and firmware signing: Issue signing certificates for software and firmware to verify legitimacy and prevent tampering (for example, Launch Tech's charging pile device firmware verification).
Internal resource protection: Secure servers, applications, and containers to meet compliance requirements in regulated industries such as finance and healthcare.
Cross-account and cross-region certificate management: Share a root CA across accounts and publish CAs across regions to simplify large-scale certificate deployment (for example, StubHub's PKI architecture reconstruction during cloud migration).
How it works
Your service signs a JWT using its PCA client certificate.
Your service calls the IDaaS authorization server token endpoint and selects the PCA federated credential capability.
Your service provides the root certificate, intermediate certificate list, and client certificate.
IDaaS validates the certificate chain and issues an Access Token.
Prerequisites
Before you begin, make sure you have:
A self-built Private Certificate Authority
A root certificate, at least one intermediate certificate, and a client certificate issued by your PCA
OIDC federated credential provider
Storing long-lived access keys in containers or pipelines is a security risk—keys can leak through logs, environment variables, or container images. OIDC federation eliminates this by letting your workload exchange a short-lived OIDC token (issued by its runtime environment) for an IDaaS Access Token directly.
Use cases
Use OIDC federation when your client service runs in any of the following environments:
Kubernetes pod
Alibaba Cloud ACK cluster (RRSA mode)
GitHub Actions workflow
CI/CD pipeline
Azure VM
Google Cloud Compute Engine
How it works
Get an OIDC token from your container runtime or cloud server.
Call the IDaaS authorization server token endpoint and select the OIDC federated credential capability.
Provide the verification public key.
IDaaS validates the token and issues an Access Token.
PKCS#7 federated credential provider
Cloud providers sign instance metadata with a PKCS#7 signature that proves a request originates from a specific virtual machine. PKCS#7 federation lets your service exchange that signature for an IDaaS Access Token, giving you a trust anchor that requires no credential management.
PKCS#7 is a fundamental standard in Public Key Infrastructure (PKI), widely used in scenarios requiring data integrity and confidentiality. Its key capabilities include:
Financial transaction security: Sign and encrypt bank transaction data to ensure the authenticity and integrity of transaction instructions (for example, protecting transfers and payments).
Electronic document signing: Apply digital signatures to electronic documents with legal effect equivalent to physical seals (for example, official documents, legal contracts, and identity verification).
Data signing and encryption: Sign and encrypt messages to verify data sources and prevent tampering. PKCS#7 formats (
.p7b/.p7c) support multiple signatures and certificates, making them suitable for complex trust chain management.
Use cases
Use PKCS#7 federation when your client service runs on:
Alibaba Cloud ECS or ECI
Amazon EC2
How it works
Get a PKCS#7 signature from your cloud server's metadata signature endpoint.
Call the IDaaS authorization server token endpoint and select the PKCS#7 federated credential capability.
Provide the verification root certificate.
IDaaS validates the signature and issues an Access Token.