## 5 Gaia-X-Med: Our Solutions
### Authentication
#### 5.4.2 Authentication  
Participants initiate authentication by creating a JSON Web Token (JWT) for login, containing their DID URL, signed with the private key from their Participant Identity File. This token is sent to the verifying party, such as a Provider Service. By resolving the DID URL to an HTTPS address, the verifier downloads the DID Document containing the public key to validate the token's signature. The verifier then follows the link in the DID Document to access the Participant's Gaia-X Credential, ensuring it meets the Gaia-X Trust Framework's rules. If both the token and Credential are valid, the verifier can trust the Participant's identity and claims. The Gaia-X-Med implementation simplifies this process with a federation-wide _Authentication Service_. This service validates login tokens, verifies compliance, and returns trustworthy Credentials, sparing Providers from implementing the entire verification process independently. Figure 6 shows a simplified overview of the process. As for integrating this authentication flow into the backend architecture of a Provider Service, we developed two methods, each covering a different use case. The first combines the authentication flow with OpenID Connect, a widely used standard for enabling single sign-on authentication [30]. To realize this, an _OpenID Connect Identity Provider_ based on node-oidc-provider ([[https://github.com/panva/node-oidc-provider](https://github.com/panva/node-oidc-provider)]([https://github.com/panva/node-oidc-provider](https://github.com/panva/node-oidc-provider)) (accessed on 5 December 2024)) was developed and hosted as a federation-wide web application. After asking the user for their Participant Identity File and decryption passphrase, the application generates a Login token client-side that is then sent to the Authentication Service. The returned Participant Credential is mapped to the corresponding OAuth2 claims, which are finally forwarded to the Provider Service. Figure 6: A simplified overview of the Gaia-X-Med authentication flow. A Consumer submits a locally signed Login token to the Authentication Layer, which forwards it to the Authentication Service. After fetching and verifying the Consumer’s identity and checking their Compliance Credential signature, the Authentication Service responds with the now-verified Credentials, which can then be trusted and used further by the Provider. The Provider can use any of the various available OpenID Connect clients to enable this authentication method; popular choices include _Keycloak_ ([[https://www.keycloak.org](https://www.keycloak.org)]([https://www.keycloak.org](https://www.keycloak.org)) (accessed on 5 December 2024)) and proxy server modules like mod_auth_openidc ([[https://github.com/OpenIDC/mod_auth_openidc](https://github.com/OpenIDC/mod_auth_openidc)]([https://github.com/OpenIDC/mod_auth_openidc](https://github.com/OpenIDC/mod_auth_openidc)) (accessed on 5 December 2024)) for use with the _Apache HTTP Server_ ([[https://httpd.apache.org/](https://httpd.apache.org/)]([https://httpd.apache.org/](https://httpd.apache.org/)) (accessed on 5 December 2024)). The OpenID Connect method is particularly suited for easily integrating interactive Gaia-X-Med authentication for web-application-based services. Figure 7 shows a schematic overview of the OpenID Connect method. The other method is what we dubbed the Proxy method. Here, we developed a middleware solution called the _Authentication Proxy_, which is deployed in front of a Provider Service and intercepts incoming requests from Consumers. Before allowing requests to reach the Service, Consumers are required to register an authenticated session with the Authentication Proxy using a Login token.