> For the complete documentation index, see [llms.txt](https://docs.dfc-standard.org/dfc-standard-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dfc-standard.org/dfc-standard-documentation/technical-specifications/authentication-strategy.md). # Authentication strategy ## Authentication strategy The current consensus at DFC about authentication relies on the [OpenID Connect (OIDC)](#openid-connect-protocol-oidc) protocol. Despites OIDC is centralized it stays relatively simple and has been proven reliable and robust since it is used by many actors of the Web for years. Decentralized authentication mechanisms exist like [Solid-OIDC](#solid-oidc). It's built on top of OIDC. As we now support [user WebIDs](https://github.com/datafoodconsortium/standard/tree/master/technical-specifications/data-storage-and-discovery/README.md#dfc-user-webids) it can make sense to move to Solid-OIDC to identify the user using its WebID. This document presents such an option in the Solid-OIDC [dedicated section](#solid-oidc). Another decentralized authentication mechanisms exist like the [Decentralized Identifiers W3C standard](#decentralized-identifiers) but it is more complicated to set up. The DFC consensus might evolve to use this kind of authentication in the future. ### OpenID Connect (OIDC) The [OpenID Connect (OIDC)](https://openid.net/connect/) is an authentication layer on top of the [OAuth2](https://oauth.net/2/) authorization framework. Clients implementing OIDC do delegate the authentication to a third-party application that allows the user to authenticate. Once the user is logged in a token is returned to the client so it can perform authenticated requests to access to protected resources. The OpenID authentication is based on the exchange of tokens following the [JSON Web Token standard](#rfc7519). Basically these tokens contains base64 encoded JSON data. A token is composed of 3 parts separated by dots: the *header*, the *payload* and the *signature*. These 3 parts are encoded using Base64url method. The algorithm used to sign DFC tokens is RS256 (RSA signature with SHA-256). DFC tokens are not encrypted. The header sent to your platform will look like `Authorization: JWT ` (*\* will be replaced by the actual token in clear, base64 encoded). You can use to play with JWT tokens. Tools like Insomnia or Postman can help you during the token implementation process to send and debug HTTP requests. The DFC OIDC implementation currently identifies the user using its email address. **TODO: put an example of a DFC token here** It is very important to verify the signature to be sure that the token is coming from the DFC server. To verify the signature, you can use the openSSL verify function or use a JWT library that will do the work you you. The signature can be controlled thanks to a public key that you can find [here](https://simonlouvet.github.io/config-private/DFC-Proto/config.json) (inside the public\_key field). Doing so, you would probably have to surround the key manually with its type headers (-----BEGIN PUBLIC KEY----- and -----END PUBLIC KEY-----). Sometimes, depending of your library, you even need to respect the .pem format by adding break line mentions in the headers (-----BEGIN PUBLIC KEY-----\n and \n-----END PUBLIC KEY-----). Nowadays, OIDC libraries can handle this token verification automatically by checking the Public key directly on the OIDC server. This method often refers as JWKS one and you have the JWKS uri for LesCommuns OIDC server here: . And even for more automation, the Discovery url for the Data Food Consoritum Realm is: . ![Platform Authentificaiton not OIDC driven](https://1588480407-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Le0FJV4LAZU5p1uZMLA%2Fuploads%2Fgit-blob-2932032daf25b9f6f868967edccf4f9f7e7255c2%2Fselection_622.png?alt=media) ![Platform Authentificaiton OIDC driven](https://1588480407-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Le0FJV4LAZU5p1uZMLA%2Fuploads%2Fgit-blob-b27f5662b1fc900d6f0ba1b01bfea03216fc84e6%2Fselection_624.png?alt=media) **Each platform wishing to join the DFC project MUST have a client configured on our Single-Sign-On server (SSO) provided by our partner lescommuns.org.** Please contact the DFC team to do so. To learn more about the OpenID Connect protocol you can browse the official [OpenId Connect specification](#openid-connect). To learn more about OAuth2 you can read *The OAuth 2.0 Authorization Framework* ([RFC 6749](#rfc6749)) and *The OAuth 2.0 Authorization Framework: Bearer Token Usage* ([RFC 6750](#rfc6750)). ### Solid-OIDC This section has to be written. ## References ### Normative references #### \[OpenID Connect] OpenID Connect Core 1.0 incorporating errata set 2. URL: . #### \[RFC6749] The OAuth 2.0 Authorization Framework. URL: . #### \[RFC6750] The OAuth 2.0 Authorization Framework: Bearer Token Usage. URL: . #### \[RFC7519] JSON Web Token (JWT). Internet Engineering Task Force (IETF). URL: . ### Informative references #### \[Decentralized Identifiers] Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, and representations. URL: . #### \[Solid OIDC] () #### \[Solid-OIDC Primer] () #### \[did:solid Method Specification] ()