oAuth Implementation

OAuth in the iSHARE Trust Framework

The iSHARE Trust Framework has always enabled secure, certificate-based authentication between participants without bilateral preregistration at each Service Provider. This approach is grounded in self-sovereign principles: organisations authenticate using their eIDAS or eSeal certificates (PKI-based certificates), dynamically validated against the iSHARE Participant Registry.

While OAuth 2.0 is widely used as an industry standard for token-based authentication, most off-the-shelf implementations assume that every client must be preregistered with an Authorisation Server before obtaining a token. iSHARE’s design takes a different path: preregistration is handled centrally through the Participant Registry rather than separately at every Service Provider. As a result, Service Consumers generate JWT client assertions signed with their certificates, and Service Providers verify them directly in real time.

Despite this difference, iSHARE does not diverge from OAuth principles. Its authentication process closely follows the Client Credentials Grant described in RFC 7521 Section 6.2, where a client acts on its own behalf by presenting a digitally signed JSON Web Token. RFC 7523, which defines JWT profiles for OAuth 2.0, matches iSHARE’s mechanism: the Service Consumer generates a client_assertion signed with its certificate, and the Service Provider validates this assertion against trusted certificate roots listed in the iSHARE Participant Registry.

This article aims to clarify how the iSHARE Trust Framework implements OAuth 2.0 in a way that supports dynamic, certificate-based trust while remaining aligned with established industry standards. It explains how iSHARE specifications build on OAuth profiles such as RFC 7521 and RFC 7523, why Service Consumers do not need to preregister with Service Providers, and which libraries already support these mechanisms. This article reflects the outcome of RFC051, which was approved by iSHARE to provide further clarity on its OAuth implementation.

A Standards-Based Approach

The alignment between iSHARE and these RFCs means that Service Providers do not need to develop custom authentication systems. Existing OAuth 2.0 libraries already support JWT-based client assertions and can be configured or extended further to satisfy iSHARE’s certificate validation requirements. Mature tools such as Keycloak for Java, Authlib for Python, and Duende Identity Server for .NET provide native support for these flows. Similarly, cryptographic libraries such as Bouncy Castle, OpenSSL and Python’s cryptography module can perform X.509 certificate validation, including checking certificate chains, revocation status, and key usage attributes.

For developers, this means implementing iSHARE does not require building new security components. Instead, it is a matter of configuring well-known components to base authentication on certificates rather than on local preregistration. This lowers implementation effort, avoids duplication, and reduces the security risks that come with custom code. By aligning with RFC 7521 and RFC 7523, iSHARE remains interoperable with mainstream OAuth 2.0 tooling while preserving its decentralised trust model.

How OAuth Works in iSHARE

Each Service Provider hosts its own /token endpoint. When a Service Consumer wants to access a service, the Service Consumer creates a self-signed JWT client assertion using its eIDAS or eSeal certificate and sends this in a POST /connect/token request to the Service Provider. The Service Provider validates the signature, checks the certificate chain against trusted Certificate Authorities listed in the iSHARE Participant Registry, and verifies that the certificate is valid and not revoked. To complete the process, the Service Provider creates its own iSHARE client assertion and exchanges it with the Participant Registry for an access token. It may then query the registry to confirm party details such as identity, certificate, and status. If the verification succeeds, the Service Provider issues a bearer token to the Service Consumer for use in subsequent API calls. This approach means that Service Providers do not need to maintain client registries. Trust is established dynamically at runtime, ensuring a fully decentralised model.

Figure 1: iSHARE oAuth M2M Authentication Flow

For a more detailed technical reference on how authentication flows are implemented in practice, including request formats and validation steps, see the iSHARE Developer Portal.

Supporting Implementations

The main work is configuring standard libraries to perform certificate trust-chain validation against the iSHARE Participant Registry. To help participants adopt these flows with confidence, iSHARE Foundation is extending its developer documentation to explain how iSHARE maps directly onto OAuth 2.0 standards. The documentation will provide guidance on configuration patterns, practical examples, and a curated list of libraries that already support JWT-based assertions and certificate validation. These resources will enable Service Providers to integrate iSHARE authentication flows quickly, securely, and without unnecessary complexity.

A Continued Commitment to Standards

The approval of RFC051 confirms that iSHARE’s OAuth implementation remains aligned with widely adopted industry standards while retaining its core principles of decentralisation and dynamic trust. By using certificates validated against the Participant Registry, iSHARE participants achieve secure, standards-compliant authentication without bilateral preregistration — a design that supports interoperability across diverse data spaces and technology stacks.

This clarification underscores that iSHARE is not diverging from OAuth but extending it in a way already foreseen by its own RFCs. As new tools and frameworks continue to mature, iSHARE participants will increasingly benefit from library support that reduces integration effort while maintaining full compliance with the Trust Framework.