Skip to content

OIDC Authentication

François Turbelin edited this page Nov 19, 2021 · 7 revisions

Create an account on the Authentication server

DFC prototype is using OIDC protocol to deal with authentication. The Authentication server is external and hosted here: https://login.lescommuns.org/auth/realms/data-food-consortium. It is using a dedicated Realm for Data Food Consortium project.

The objective is then to create an account on this Authentication server and get the Access token that will help to link the Provider between both platforms.

Authorize the API calls using an Authentication token

The DFC Prototype will call your application with the Access Token provided in the step 1. You need to use this token in order to authenticate the request and also to link it with the user inside your application. The Access Token will be sent through a HTTP Header Authorization: Bearer hereisthetoken123.

Actually the Access Token is formatted as JSON Web Tokens standard (https://jwt.io/introduction/) and then 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 is RS256. The token is not encrypted. So the header sent to your platform will look like Authorization: JWT hereisthetoken123.

It is very important to verify the signature to be sure the token is coming form the Authorization server. To verify the signature, 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 (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 libs 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: https://login.lescommuns.org/auth/realms/data-food-consortium/protocol/openid-connect/certs. And even for more automation, the Discovery url for the Data Food Consoritum Realm is: https://login.lescommuns.org/auth/realms/data-food-consortium/.well-known/openid-configuration.

Use https://jwt.io/ to play with JWT token. Tools like Insomnia or Postman can help you during the token implementation process to send and debug HTTP requests.

Link the users between your platform and the DFC prototype

The Access Token is actually providing an email information (inside the JWT payload) which is actually the OIDC UID, and you can use it to fetch an user of your application.

You can eventually save this email is a specific database field in your database as the DFC OIDC UID. This could be done through a small interface from your Admin allowing your Producer/Distributor to create his account on DFC Authorization platform and get the UID directly from it.