OIDC user identity focuses on user identity and is user-centric, whereas SPIFFE workload identity handles workload identities and authentication (e.g., services, containers).
OIDC:
Identity Representation: user-centric claims (subject, email, name)
Authentication Method: OAuth2/OIDC tokens (JWTs)
Use Cases: Web app authentication and federation
Integration: Web apps, API gateways, CI/CD tools
Trust Domain: Defined by the IdP
SPIFFE Workload Identity:
Identity Representation: SPIFFE ID (e.g., spiffe://trust-workload-name)
Authentication Method: X.509 certificates or JWTs
Use Cases: Service-to-service authentication
Integration: Kubernetes, service mesh, multiple cluster/cloud environments
Trust Domain: defined by SPIFFEE trust domains
OIDC and SPIFFE can work together.
Bridging user and work authentication; SPIFFE can authorize workloads acting on behalf of a user authenticated via OIDC
Interoperable Tokens: SPIFFE certificates or tokens can interoperate with systems expecting OIDC-based tokens
Combined Policies: Policies can be created for both OIDC user identities and SPIFFEE workload identities. For example, a specific user (via OIDC) may trigger a workload authenticated by SPIFFE
Complementary Functions: OIDC authenticates the user to a service, while SPIFFE secures subsequent service-to-service communication using workload identities
From this perspective, I believe Accuknox’s proposal aligns with Ericsson’s interest and direction.
ONAP Context:
In ONAP, user identities via OIDC are used alongside a Service Mesh, which secures service-to-service communication within a single cluster (with SPIFFE, a service mesh can work across multi cluster/clouds).
...