Trust-Based Identity Sharing For Token Grants

Authentication and authorization are two key elements of a software application. In modern day, OAuth 2.0 framework and OpenID Connect protocol are widely adopted standards fulfilling these requirements. These protocols are implemented into authorization servers. It is common to call these authorization servers as identity servers or identity providers since they hold user identity information. Applications registered to an identity provider can use OpenID Connect to retrieve ID token for authentication. Access token obtained along with ID token allows the application to consume OAuth 2.0 protected resources. In this approach, the client application is bound to a single identity provider. If the client needs to consume a protected resource from a different domain, which only accepts tokens of a defined identity provider, then the client must again follow OpenID Connect protocol to obtain new tokens. This requires user identity details to be stored in the second identity provider as well. This paper proposes an extension to OpenID Connect protocol to overcome this issue. It proposes a client-centric mechanism to exchange identity information as token grants against a trusted identity provider. Once a grant is accepted, resulting token response contains an access token, which is good enough to access protected resources from token issuing identity provider’s domain.

💡 Research Summary

The paper addresses a practical limitation of the current OAuth 2.0 and OpenID Connect ecosystem: a client application is typically bound to a single identity provider (IDP). When a user who is registered only with IDP A needs to access a protected resource in domain B, the client must repeat the OpenID Connect flow with IDP B, which forces the user to maintain duplicate credentials across domains. This duplication creates usability friction and increases the attack surface because personal data must be stored in multiple places.

To solve this problem, the authors propose a “trust‑based identity sharing” extension to OpenID Connect. The core idea is to introduce a new token type – the Identity Share Token (IST) – that carries the user’s identity claims from one trusted IDP to another. The IST is a JSON Web Token (JWT) that contains mandatory claims such as iss (issuer IDP), aud (receiving IDP), exp, iat, and a sdata claim that holds the user’s attribute set. Depending on the agreement between the two IDPs, the IST can be signed only (allowing the receiving IDP to verify the audience) or fully encrypted (protecting the user’s claims from the client).

The trust model is formalized through four relationships: (A) end‑user ↔ client, (B) IDP A ↔ IDP B, (C) client ↔ IDP A, and (D) client ↔ IDP B. Relationship B is the novel element; it mirrors the federation concepts found in SAML or WS‑Federation but is implemented on top of OAuth 2.0/OpenID Connect. Trust between the two IDPs is established via a registration process (or dynamic client registration) that includes policy validation and possibly mutual certificate exchange. Once the trust is in place, the client can act as a bridge:

1. The client initiates a normal OpenID Connect authentication request to IDP A, adding the scope value identity_share.
2. After successful authentication, IDP A issues an IST and returns it to the client together with the usual ID token and access token for domain A.
3. The client then presents the IST to IDP B’s token endpoint using a custom grant type grant_type=identity_share.
4. IDP B validates the IST (signature, audience, expiration, and the user claims in sdata). If validation succeeds, IDP B issues a standard OAuth 2.0 access token that the client can use to call protected resources in domain B.

Thus the client obtains valid access tokens for both domains without requiring the user to register separately with IDP B.

Security considerations are discussed in depth. The authors recommend short lifetimes for ISTs, mandatory signature verification, optional encryption of the sdata claim, and strict audience checking to prevent token replay across unrelated IDPs. They also acknowledge that exposing user claims to the client (if the IST is only signed) may leak sensitive data, so encryption is advisable when privacy is a concern. The paper compares the proposal with existing standards: SAML/WS‑Federation already support identity federation but are not natively compatible with OAuth 2.0; RFC 7521 defines an assertion framework for token grants but requires a separate infrastructure. The IST approach leverages the already‑ubiquitous JWT format and integrates directly into the OpenID Connect flow, reducing implementation complexity and preserving backward compatibility.

Limitations identified include the operational overhead of establishing and maintaining bilateral trust between every pair of IDPs, the need for robust policy management to avoid inconsistent trust decisions, and the challenge of auditing cross‑domain token exchanges in large federations.

In conclusion, the paper presents a practical, standards‑based extension that enables multi‑domain token sharing through a trusted identity share token. By embedding the mechanism within the existing OpenID Connect protocol, it improves user experience, reduces duplicate credential storage, and opens a path toward seamless federation of OAuth 2.0‑protected services. Future work is suggested on automating trust establishment, dynamic policy negotiation, and performance/security evaluation in large‑scale federated deployments.