OpenID Connect OAuth Server dédié

JWT : Un module de validation en Python

DnC — 2026-02-14T07:50:26Z

Un module utilitaire pour :

décoder un JWT,
vérifier sa signature (HMAC ou RSA),
protèger contre les attaques par timing,
lèver des exceptions explicites,
valider les claims pour garantir que le token est encore valable et destiné au service.

C'est une implémentation qui évite les boîtes noires, donc parfaitement maîtrisée.

Ce module Python fournit une implémentation bas niveau. Il ne dépend pas de bibliothèques haut niveau comme PyJWT : on maîtrise entièrement le processus.

Comment cela fonctionne (étape par étape)

1) Découpage du JWT
Le token doit avoir la forme :

header.payload.signature

Le code vérifie :
qu'il y a bien 3 segments,
qu'ils sont valides en Base64URL,
qu'ils contiennent du JSON correct.

En cas de problème → `JWTFormatError`.

2) Décodage Base64URL
Chaque segment est décodé en bytes, avec ajout automatique du padding `=` si nécessaire.

En cas d'erreur → `JWTFormatError`.

3) Analyse du header
Le header doit contenir un champ :

"alg" : "HS256" | "RS256" | ...

Si l'algorithme est absent ou non autorisé → `JWTAlgorithmError`.

4) Vérification de la signature
Selon l'algorithme :

HMAC (HS256 / HS384 / HS512)
Recalcul du HMAC avec la clé secrète
Comparaison en temps constant (Time Constant Comparison) : `compare_digest`
→ protège contre les attaques par timing

Si la signature ne correspond pas → `JWTSignatureError`.

RSA (RS256 / RS384 / RS512)
Chargement de la clé publique PEM
Vérification via `cryptography` + PKCS#1 v1.5

Si la signature est invalide → `JWTSignatureError`.

5) Retour du payload
Si tout est correct, la fonction renvoie le **payload décodé** (dict Python).

Voici le code :

# jwt_validation.py
# coding: utf8
"""
Décodage et validation d'un Jeton d'Identité JSON Web Token (JWT).
Auteur :
B.Degoy bertrand@degoy.com
copyright (c) 2026 B.Degoy
licence : MIT
"""
import json
import base64
import hmac
import hashlib
from typing import Any, Dict
class JWTDecodeError(Exception):
"""Base class for all JWT decoding errors."""
pass
class JWTFormatError(JWTDecodeError):
"""Raised when the JWT structure is invalid."""
pass
class JWTAlgorithmError(JWTDecodeError):
"""Raised when the algorithm is missing or not allowed."""
pass
class JWTSignatureError(JWTDecodeError):
"""Raised when the signature is invalid."""
pass
class JWTUtils:
"""
A static utility class providing low-level JWT decoding and signature
verification, equivalent to the provided PHP implementation but using
Python exceptions instead of returning False.
This class does NOT validate claims (exp, nbf, iss, etc.).
"""
# ----------------------------------------------------------------------
# Base64URL decoding
# ----------------------------------------------------------------------
@staticmethod
def urlsafe_b64decode(data: str) -> bytes:
"""
Decode a Base64URL string into raw bytes.
Adds required padding if missing.
"""
padding = "=" * (-len(data) % 4)
try:
return base64.urlsafe_b64decode(data + padding)
except Exception as e:
raise JWTFormatError(f"Invalid Base64URL segment: {data}") from e
# ----------------------------------------------------------------------
# HMAC signing
# ----------------------------------------------------------------------
@staticmethod
def sign(message: str, key: bytes, algo: str) -> bytes:
"""
Compute an HMAC signature for the given message using HS256/384/512.
"""
if algo == "HS256":
return hmac.new(key, message.encode(), hashlib.sha256).digest()
if algo == "HS384":
return hmac.new(key, message.encode(), hashlib.sha384).digest()
if algo == "HS512":
return hmac.new(key, message.encode(), hashlib.sha512).digest()
raise JWTAlgorithmError(f"Unsupported HMAC algorithm: {algo}")
# ----------------------------------------------------------------------
# Constant-time comparison
# ----------------------------------------------------------------------
@staticmethod
def hash_equals(a: bytes, b: bytes) -> bool:
"""Constant-time comparison to avoid timing attacks."""
return hmac.compare_digest(a, b)
# ----------------------------------------------------------------------
# RSA signature verification
# ----------------------------------------------------------------------
@staticmethod
def verify_rsa(signature: bytes, message: str, key_pem: str, algo: str) -> bool:
"""
Verify an RSA signature using a PEM-encoded public key.
Supported algorithms: RS256, RS384, RS512.
"""
from cryptography.hazmat.primitives import serialization, hashes
from cryptography.hazmat.primitives.asymmetric import padding
public_key = serialization.load_pem_public_key(key_pem.encode())
hash_algo = {
"RS256": hashes.SHA256(),
"RS384": hashes.SHA384(),
"RS512": hashes.SHA512(),
}.get(algo)
if hash_algo is None:
raise JWTAlgorithmError(f"Unsupported RSA algorithm: {algo}")
try:
public_key.verify(
signature,
message.encode(),
padding.PKCS1v15(),
hash_algo
)
return True
except Exception:
return False
# ----------------------------------------------------------------------
# Signature verification dispatcher
# ----------------------------------------------------------------------
@staticmethod
def verify_signature(signature: bytes, input_data: str, key: Any, algo: str) -> None:
"""
Verify the signature for the given algorithm.
Raises JWTSignatureError on failure.
"""
if algo in ("HS256", "HS384", "HS512"):
key_bytes = key if isinstance(key, bytes) else key.encode()
expected = JWTUtils.sign(input_data, key_bytes, algo)
if not JWTUtils.hash_equals(expected, signature):
raise JWTSignatureError("Invalid HMAC signature")
return
if algo in ("RS256", "RS384", "RS512"):
if not JWTUtils.verify_rsa(signature, input_data, key, algo):
raise JWTSignatureError("Invalid RSA signature")
return
raise JWTAlgorithmError(f"Unsupported or invalid signing algorithm: {algo}")
# ----------------------------------------------------------------------
# Main decode function
# ----------------------------------------------------------------------
@staticmethod
def decode(jwt: str, key: Any = None, allowed_algorithms: Any = True) -> Dict:
"""
Decode a JWT token, validate its structure, optionally verify its
signature, and return the payload as a dictionary.
Raises:
JWTFormatError: Invalid structure or Base64URL segments.
JWTAlgorithmError: Missing or disallowed algorithm.
JWTSignatureError: Signature verification failed.
"""
# Basic structure check
if "." not in jwt:
raise JWTFormatError("JWT must contain at least one dot")
parts = jwt.split(".")
if len(parts) != 3:
raise JWTFormatError("JWT must contain exactly 3 segments")
head_b64, payload_b64, sig_b64 = parts
# Decode JSON header and payload
try:
header = json.loads(JWTUtils.urlsafe_b64decode(head_b64))
except Exception as e:
raise JWTFormatError("Invalid JWT header") from e
try:
payload = json.loads(JWTUtils.urlsafe_b64decode(payload_b64))
except Exception as e:
raise JWTFormatError("Invalid JWT payload") from e
signature = JWTUtils.urlsafe_b64decode(sig_b64)
# Algorithm checks
if allowed_algorithms:
if "alg" not in header:
raise JWTAlgorithmError("Missing 'alg' in JWT header")
algo = header["alg"]
if isinstance(allowed_algorithms, list) and algo not in allowed_algorithms:
raise JWTAlgorithmError(f"Algorithm '{algo}' not allowed")
signing_input = f"{head_b64}.{payload_b64}"
JWTUtils.verify_signature(signature, signing_input, key, algo)
return payload

Télécharger

Validation des déclarations (claims)

L'utilitaire ci-dessus décode le JWT et vérifie la signature — mais **il ne valide pas les claims**, c'est‑à‑dire les champs qui définissent *quand* et *dans quelles conditions* le token est valable.

Quels claims doivent être validés ?

Les principaux champs standardisés dans un JWT sont :

Claim	Signification	Validation
`exp`	Expiration time	Le token doit être encore valide
`nbf`	Not Before	Le token ne doit pas être utilisé trop tôt
`iat`	Issued At	Optionnel : vérifier que la date n'est pas aberrante
`iss`	Issuer	Vérifier que le token vient du bon émetteur
`aud`	Audience	Vérifier que le token est destiné à ton service
`sub`	Subject	Optionnel : vérifier l'identité attendue

Fonction validate_claims()

Voici comment ajouter cette validation :
On ajoute une fonction **validate_claims(payload, options)** qui :
lit les champs du payload,
compare avec l'heure actuelle,
lève des exceptions explicites si quelque chose ne va pas.

from datetime import datetime, timezone
class JWTClaimsError(Exception):
"""Raised when JWT claims validation fails."""
pass
class JWTUtils:
# ... (tout le reste de ta classe ici)
@staticmethod
def validate_claims(
payload: dict,
issuer: str = None,
audience: str = None,
leeway: int = 0
) -> None:
"""
Validate standard JWT claims (exp, nbf, iss, aud).
Parameters:
payload (dict): The decoded JWT payload.
issuer (str|None): Expected 'iss' value.
audience (str|None): Expected 'aud' value.
leeway (int): Allowed clock skew in seconds.
Raises:
JWTClaimsError: If any claim is invalid.
"""
now = datetime.now(timezone.utc).timestamp()
# --- exp: expiration time ---
if "exp" in payload:
if now > payload["exp"] + leeway:
raise JWTClaimsError("Token has expired")
# --- nbf: not before ---
if "nbf" in payload:
if now < payload["nbf"] - leeway:
raise JWTClaimsError("Token is not yet valid (nbf)")
# --- iat: issued at ---
if "iat" in payload:
if payload["iat"] > now + leeway:
raise JWTClaimsError("Token issued in the future (iat)")
# --- iss: issuer ---
if issuer is not None:
if payload.get("iss") != issuer:
raise JWTClaimsError(f"Invalid issuer: {payload.get('iss')}")
# --- aud: audience ---
if audience is not None:
aud = payload.get("aud")
if isinstance(aud, list):
if audience not in aud:
raise JWTClaimsError(f"Audience '{audience}' not allowed")
else:
if aud != audience:
raise JWTClaimsError(f"Invalid audience: {aud}")
</python>
{{intégration dans `decode()`}}
On ajoute un paramètre optionnel :
<code class="python">
@staticmethod
def decode(jwt, key=None, allowed_algorithms=True, validate=False, issuer=None, audience=None):
payload = ... # comme avant
if validate:
JWTUtils.validate_claims(payload, issuer=issuer, audience=audience)
return payload
</python>
Et on l'appelle comme ceci :
<code class="python">
payload = JWTUtils.decode(
token,
key=public_key,
allowed_algorithms=["RS256"],
validate=True,
issuer="https://auth.example.com",
audience="my-api"
)

Télécharger

Validation du jeton d'identité ID Token (JWT signé ou JWS)

DnC — 2026-02-13T07:23:00Z

Les Jetons d'identité ne doivent jamais être approuvés tels quels. Les jetons peuvent être réutilisés par un malware, interceptés ou falsifiés par des attaquants. Lorsqu'une application ou une ressource protégée reçoit un jeton d'Identité JWT, elle doit toujours le valider.
Cependant, valider le jeton n'est pas tout : il faut encore vérifier qu'il est présenté par une application qui le détient légitimement.

Problématique

Le jeton d'identité, de type JWT signé (JWS), doit être validé dans deux situations :

Dès sa réception, conformément à ce qui est défini dans la spécification d'OpenID Connect [1].

Pour autoriser l'accès à une ressource protégée. Voyez comment le problème se pose de façon générale : Validation du jeton par une ressource protégée.
Deux cas se présentent :
soit on passe la clé publique au serveur de ressource protégée RS qui procède localement à sa validation ; si ce RS n'est pas lié à l'organisation qui contrôle le serveur d'authentification, il peut utiliser la fonction API OpenID Connect : Découverte,
soit on utilise une méthode dite "introspection" consistant à demander l'authentification du jeton JWT au serveur d'authentification qui l'a délivré : API Open ID Connect : Introspection (Introspection Endpoint) .

Procédure pour la Validation et la Consommation du jeton JWT signé (JWS)

La validation d'un jeton d'identité nécessite plusieurs étapes. Que le jeton soit validé du côté du serveur d'authentification ou à distance, la méthode est la même.

Le décodage et la validation du jeton suivent la méthode définie ici : Spécification OpenID Connect : Validation du jeton d'identité :

Les clients DOIVENT valider le jeton ID dans la réponse au jeton de la manière suivante :

Si le jeton d'identification est chiffré, déchiffrez-le à l'aide des clés et des algorithmes spécifiés lors de l'enregistrement par le client, que l'OP devait utiliser pour chiffrer le jeton d'identification. Si le chiffrement a été négocié avec l'OP au moment de l'enregistrement et que le jeton d'identification n'est pas chiffré, le RP [2] DEVRAIT le rejeter.
L'identifiant de l'émetteur pour le fournisseur OpenID (qui est généralement obtenu lors de la découverte) DOIT correspondre exactement à la valeur de la déclaration iss (issuer).
Le client DOIT valider que la déclaration aud (audience) contienne la valeur client_id enregistrée auprès de l'émetteur identifié par la déclaration iss (émetteur) en tant qu'audience. La déclaration aud (audience) PEUT contenir un tableau avec plus d'un élément. Le jeton ID DOIT être rejeté si le jeton ID ne répertorie pas le client en tant qu'audience valide, ou s'il contient des audiences supplémentaires non approuvées par le client.
Si le jeton d'identification contient plusieurs audiences, le client DEVRAIT vérifier qu'une déclaration azp est présente.
Si une déclaration azp (partie autorisée) est présente, le client DEVRAIT vérifier que son client_id est la valeur de la déclaration.
Si le jeton ID est reçu via une communication directe entre le client et le point d'extrémité du jeton (qui se trouve dans ce flux), la validation TLS du serveur PEUT être utilisée pour valider l'émetteur au lieu de vérifier la signature du jeton [3]. Le client DOIT valider la signature de tous les autres jetons ID conformément à JWS [JWS] en utilisant l'algorithme spécifié dans le paramètre d'en-tête JWT alg. Le client DOIT utiliser les clés fournies par l'émetteur.
La valeur alg DEVRAIT être la valeur par défaut de RS256 ou l'algorithme envoyé par le client dans le paramètre id_token_signed_response_alg lors de l'enregistrement.
Si le paramètre d'en-tête JWT alg utilise un algorithme basé sur MAC, tel que HS256, HS384 ou HS512, les octets de la représentation UTF-8 du secret client correspondant à l'identifiant client contenu dans la déclaration aud (audience) sont utilisés comme clé de validation de la signature. Pour les algorithmes basés sur MAC, le comportement n'est pas spécifié si l'aud est multivalué ou si une valeur azp est différente de la valeur aud.
L'heure actuelle DOIT être antérieure à l'heure représentée par la déclaration exp.
La déclaration Iat peut être utilisé pour rejeter des jetons qui ont été émis trop loin de l'heure actuelle, limitant ainsi la durée de stockage des clés pour prévenir les attaques. La plage acceptable est spécifique au client.
Si une valeur nonce a été envoyée dans la demande d'authentification, une déclaration de nonce DOIT être présente et sa valeur vérifiée pour contrôler qu'il s'agit de la même valeur que celle qui a été envoyée dans la demande d'authentification. Le client DEVRAIT vérifier la valeur de nonce pour les attaques par relecture. La méthode précise pour détecter les attaques par relecture est spécifique au client.
Si la déclaration acr a été mentionnée, le client DEVRAIT vérifier que la valeur de réclamation revendiquée est appropriée. La signification et le traitement des déclarations acr sont hors du domaine d'application de la présente spécification.
Si la déclaration auth_time a été mentionnée, par le biais d'une demande spécifique pour cette déclaration ou du paramètre max_age, le client DEVRAIT vérifier la valeur de la déclaration auth_time et demander une nouvelle authentification s'il détermine qu'il s'est écoulé trop de temps depuis la dernière authentification de l'utilisateur final.

Exemple de code pour la vérification locale de la signature du jeton d'identité JWT signé (JWS)

La plupart de ces vérifications ne nécessitent qu'une simple comparaison de chaînes. La validation de la signature est plus complexe. L'implémentation qui en est faite par OAuthSD est décrite maintenant. La fonction suivante, tirée de OAuth 2.0 Server PHP, sépare les composantes du jeton, détecte les erreurs de format, vérifie éventuellement la signature et retourne la charge utile ou false en cas d'erreur.

La variable $key passe la clé publique qui a servi à générer le jeton JWT.

Si $key = null, la vérification de la signature n'est pas effectuée (on suppose le jeton déjà validé par introspection), et le contenu de la charge utile est retourné sous la forme d'un tableau associatif.

PHP

/**
* @author Brent Shaffer
* @license MIT License
*/
/**
* Sépare les composantes du jeton, détecte les erreurs de format, vérifie la signature et retourne la charge utile ou false en cas d'erreur.
*
* @param mixed $jwt : le jeton JWT
* @param mixed $key : la clé publique
* @param mixed $allowedAlgorithms : un array des codes d'algorithmes autorisés (sous ensemble de HS256, HS384 ou HS512, RS256, RS384 et RS512). Si ce paramètre est précisé, le jeton doit indiquer l'algorithme et celui-ci doit être compris dans l'array.
* @param mixed return : charge utile (tableau associatif) ou false.
*/
function decode($jwt, $key = null, $allowedAlgorithms = true)
{
if (!strpos($jwt, '.')) {
return false;
}
$tks = explode('.', $jwt);
if (count($tks) != 3) {
return false;
}
list($headb64, $payloadb64, $cryptob64) = $tks;
if (null === ($header = json_decode($this->urlSafeB64Decode($headb64), true))) {
return false;
}
if (null === $payload = json_decode($this->urlSafeB64Decode($payloadb64), true)) {
return false;
}
$sig = $this->urlSafeB64Decode($cryptob64);
if ((bool) $allowedAlgorithms) {
if (!isset($header['alg'])) {
return false;
}
// check if bool arg supplied here to maintain BC
if (is_array($allowedAlgorithms) && !in_array($header['alg'], $allowedAlgorithms)) {
return false;
}
if (!$this->verifySignature($sig, "$headb64.$payloadb64", $key, $header['alg'])) {
return false;
}
}
return $payload;
}
function verifySignature($signature, $input, $key, $algo = 'HS256')
{
// use constants when possible, for HipHop support
switch ($algo) {
case'HS256':
case'HS384':
case'HS512':
return $this->hash_equals(
$this->sign($input, $key, $algo),
$signature
);
case 'RS256':
return openssl_verify($input, $signature, $key, defined('OPENSSL_ALGO_SHA256') ? OPENSSL_ALGO_SHA256 : 'sha256') === 1;
case 'RS384':
return @openssl_verify($input, $signature, $key, defined('OPENSSL_ALGO_SHA384') ? OPENSSL_ALGO_SHA384 : 'sha384') === 1;
case 'RS512':
return @openssl_verify($input, $signature, $key, defined('OPENSSL_ALGO_SHA512') ? OPENSSL_ALGO_SHA512 : 'sha512') === 1;
default:
throw new \InvalidArgumentException("Unsupported or invalid signing algorithm.");
}
}

Télécharger

Voici un autre exemple en Python :

import json
import base64
import hmac
import hashlib
from typing import Any, Dict, Optional
class JWTDecoder:
# -----------------------------
# Base64URL decode
# -----------------------------
def urlsafe_b64decode(self, data: str) -> bytes:
padding = '=' * (-len(data) % 4)
return base64.urlsafe_b64decode(data + padding)
# -----------------------------
# HMAC signature
# -----------------------------
def sign(self, message: str, key: bytes, algo: str) -> bytes:
if algo == "HS256":
return hmac.new(key, message.encode(), hashlib.sha256).digest()
if algo == "HS384":
return hmac.new(key, message.encode(), hashlib.sha384).digest()
if algo == "HS512":
return hmac.new(key, message.encode(), hashlib.sha512).digest()
raise ValueError("Unsupported HMAC algorithm")
# -----------------------------
# Constant‑time comparison
# -----------------------------
def hash_equals(self, a: bytes, b: bytes) -> bool:
return hmac.compare_digest(a, b)
# -----------------------------
# RSA signature verification
# -----------------------------
def verify_rsa(self, signature: bytes, message: str, key_pem: str, algo: str) -> bool:
from cryptography.hazmat.primitives import serialization, hashes
from cryptography.hazmat.primitives.asymmetric import padding
public_key = serialization.load_pem_public_key(key_pem.encode())
hash_algo = {
"RS256": hashes.SHA256(),
"RS384": hashes.SHA384(),
"RS512": hashes.SHA512(),
}.get(algo)
if hash_algo is None:
raise ValueError("Unsupported RSA algorithm")
try:
public_key.verify(
signature,
message.encode(),
padding.PKCS1v15(),
hash_algo
)
return True
except Exception:
return False
# -----------------------------
# Signature verification
# -----------------------------
def verify_signature(self, signature: bytes, input_data: str, key: Any, algo: str) -> bool:
if algo in ("HS256", "HS384", "HS512"):
return self.hash_equals(
self.sign(input_data, key if isinstance(key, bytes) else key.encode(), algo),
signature
)
if algo in ("RS256", "RS384", "RS512"):
return self.verify_rsa(signature, input_data, key, algo)
raise ValueError("Unsupported or invalid signing algorithm.")
# -----------------------------
# Main decode function
# -----------------------------
def decode(self, jwt: str, key: Optional[Any] = None, allowed_algorithms: Any = True) -> Optional[Dict]:
if "." not in jwt:
return False
parts = jwt.split(".")
if len(parts) != 3:
return False
head_b64, payload_b64, sig_b64 = parts
try:
header = json.loads(self.urlsafe_b64decode(head_b64))
payload = json.loads(self.urlsafe_b64decode(payload_b64))
except Exception:
return False
signature = self.urlsafe_b64decode(sig_b64)
# Algorithm checks
if allowed_algorithms:
if "alg" not in header:
return False
algo = header["alg"]
if isinstance(allowed_algorithms, list) and algo not in allowed_algorithms:
return False
signing_input = f"{head_b64}.{payload_b64}"
if not self.verify_signature(signature, signing_input, key, algo):
return False
return payload

Télécharger

Avertissement à propos du paramètre 'alg'

La spécification prévoit d'appliquer la valeur du paramètre 'alg' pour le choix de l'algorithme de validation de la signature : RFC 7515, section 4.1.1. : "... This Header Parameter MUST be present and MUST be understood and processed by implementations ...".

C'est une faille de sécurité, et donc une erreur de la spécification. OAuthSD applique la méthode définie pour chaque application, quelle que soit la valeur de alg. Il est intéressant de constater que OAuthSD passe les tests de validation de l'OIDF comme cela.

En savoir plus sur la validation du JWT :

API Open ID Connect : Introspection (Introspection Endpoint)
API OpenId Connect : Point d'extrémité d'informations sur les clefs (Keys Endpoint)
OpenID Connect : Exemples complets du flux d'Autorisation via un code puis requête UserInfo

Voyez également :
Validation du jeton d'accès avec la déclaration at_hash du jeton d'identité
Table Users

Notons que la validation du jeton ne suffit pas au serveur de ressource pour s'assurer que l'application qui présente le jeton le détient légitimement et éviter de répondre à une application étrangère. Voir à ce sujet :
Vérification de l'origine de la requête reçue par un serveur de ressource.

[1] Voici pourtant ce que dit Google : "Normalement, il est essentiel de valider un jeton d'identification avant de l'utiliser, mais puisque vous communiquez directement avec Google via un canal HTTPS sans intermédiaire et que vous utilisez le secret de votre client pour vous authentifier auprès de Google, vous pouvez être sûr que le jeton que vous recevez vient vraiment de Google et est valide." C'est à dire que le jeton peut être n'importe quoi, une tartine, un cafard ou un cheval, du moment que l'on a une réponse c'est bon !!! Autant dire que le jeton ne sert à rien. Tiens, on reconnait là l'erreur qui avait prévalu avec le jeton d'accès d'OAuth 2.0. Heureusement il y a la suite : "Si votre serveur transmet le jeton d'identification à d'autres composants de votre application, il est extrêmement important que les autres composants le valident avant de l'utiliser. " (https://developers.google.com/ident...).

[2] Relying Party : l'application cliente ou le serveur de ressource protégée etc..

[3] Autrement dit, si la liaison entre le client et le serveur est sécurisée par TLS, on pourrait se passer de valider la signature. C'est ce que dit Google ici : https://developers.google.com/ident... . Cependant, nous considérons qu'il faut toujours valider la signature du jeton quel que soit l'utilisation, et pas seulement dans le cas où le jeton est retransmis à une application ou ressource tierce.

Voir aussi :
https://www.pingidentity.com/fr/company/blog/posts/2019/the-hard-parts-of-jwt-security-nobody-talks-about.html

APACHE mod_auth_openidc

DnC — 2024-11-07T13:55:00Z

APACHE mod_auth_openidc est un module d'authentification pour le serveur HTTP Apache 2.x qui délègue l'authentification des utilisateurs à un fournisseur OpenID Connect. Cela permet de contrôler l'accès à tout ou partie d'un domaine Web.

Il est ainsi possible d'accéder à des applications sans avoir à les modifier pour OIDC.

Ce module permet à un serveur Web Apache 2.x de fonctionner en tant que partie de confiance OpenID Connect (RP) ou 'client' d'un fournisseur OpenID Connect (OP).

Il délègue l'authentification des utilisateurs à l'OP, dont il reçoit en retour un jeton d'identité (ID Token) contenant les informations d'identité de l'utilisateur.
Il transmet ces informations aux applications hébergées et protégées par le serveur Web Apache.

Le contenu et/ou les applications protégés peuvent être servis par le serveur Apache lui-même ou peuvent être servis depuis un autre endroit lorsqu'Apache est configuré en tant que proxy inverse devant le(s) serveur(s) d'origine.

See : https://github.com/zmartzone/mod_auth_openidc

Préparation

Tout d'abord il faut vérifier la présence du module mod_auth_openidc :

# apachectl -M
 ...
 auth_openidc_module (shared)
 ...

Si absent, il faut installer le module mod_auth_openidc.so :

# yum install mod_auth_openidc
 ...

et relancer Apache.

Configurer un VirtualHost

Dans l'exemple qui suit, un serveur à l'URL example.com comporte un répertoire '/protected' protégé par OIDC.

Il y a trois sections dans cet exemple : d'abord la définition du serveur, puis la configuration OIDC et enfin la définition d'un emplacement protégé par OIDC.

NameVirtualHost *:80
 
 
 ServerAdmin webmaster@example.com
 ServerName example.com
 ServerAlias www.example.com
 DocumentRoot /home/example/public_html/
 DirectoryIndex index.html
 ErrorLog /var/log/oidc/error.log
 CustomLog /var/log/oidc/access.log
 
 OIDCProviderMetadataURL https://oa.dnc.global/.well-known/openid-configuration
 OIDCClientID openidc_example
 OIDCClientSecret ...
 OIDCRedirectURI http://example.com/protected/redirect_uri
 OIDCCryptoPassphrase 
 OIDCJWKSRefreshInterval 3600
 
 
 AuthType openid-connect
 Require valid-user

OIDCProviderMetadataURL : URL du document de découverte (Discovery metadata). Par convention il s'agit du fichier openid-configuration se trouvant à la racine des documents de l'OP dans le répertoire /.well-known/.
OIDCClientID, OIDCClientSecret : les identifiants du module en tant que client de l'OP (ou relying party, RP).
OIDCRedirectURI : une URI factice qui doit pointer dans un répertoire protégé par ce module (dans notre exemple à l'intérieur du répertoire 'protected') mais ne doit PAS pointer vers un contenu. Il faut l'enregistrer en tant qu'URI de redirection dans la configuration du client sur l'OP.
OIDCCryptoPassphrase : un mot de passe aléatoire à des fins de cryptage de la session.
OIDCJWKSRefreshInterval : Durée de vie de l'authentification.

Déclarations renvoyées depuis OpenID Connect via le module Apache

Le module passe les déclarations du jeton d'identité ID_TOKEN aux applications hébergées et protégées par le serveur web Apache.

Par défaut, le module définit la variable REMOTE_USER sur la revendication id_token [sub], concaténée avec l'identifiant de l'émetteur de l'OP ([sub]@[iss]).

Les autres déclarations du jeton d'identité ID_TOKEN sont transmises dans les en-têtes HTTP et/ou les variables d'environnement avec celles (éventuellement) obtenues à partir du point de terminaison UserInfo.

La super globale $_SERVER contient ces déclarations sous la forme :
OIDC_XXX

On peut par exemple les lister comme suit :
PHP

foreach ($_SERVER as $key=>$value) {
if ( preg_match("/OIDC_/i", $key) ) {
echo "$key : $value";
}
}

Télécharger

Autorisation Apache Require

Les règles d'autorisation Apache Require standard peuvent être appliquées avec l'ensemble des déclarations fournies par le jeton d'identité.

...

Gestion de la session OIDC : Fonctionnalités

DnC — 2024-04-28T10:33:30Z

SSO, SLI, SLO, SRA : ces fonctionnalités offertes par OAuthSD simplifient la gestion des sessions et des connexions pour les utilisateurs, en garantissant une expérience fluide et sécurisée lors de l'utilisation d'applications multiples compatibles avec OpenID Connect.

Avant de détailler comment OAuthSD met en œuvre ces fonctionnalités, assurons-nous de bien les distinguer :

SSO (Single Sign-On) : Il s'agit d'un mécanisme qui permet à un utilisateur de se connecter une seule fois pour accéder à plusieurs applications, sans avoir à se reconnecter à chaque fois. Avec OAuthSD, le SSO est mis en place pour offrir une authentification unique pour un groupe d'applications, évitant ainsi à un même internaute de devoir s'authentifier plusieurs fois pour accéder à des applications différentes.

SLI (Single Login In) : Le SLI est un concept similaire au SSO, mais il se concentre sur le fait qu'une fois connecté, un utilisateur peut accéder à plusieurs applications sans avoir à se reconnecter. OAuthSD utilise le SLI pour faciliter la navigation et l'échange de données au sein d'une application multiple.

SLO (Single Log-Out) : Le SLO est le pendant du SSO, mais pour la déconnexion. Il permet à un utilisateur de se déconnecter une seule fois pour se déconnecter de toutes les applications auxquelles il est connecté. Cela garantit une déconnexion globale et renforce la sécurité en cas de départ de l'utilisateur de son poste de travail.

SRA (Single Re-Authentication) : Le SRA est un mécanisme qui permet à un utilisateur de se ré-authentifier de manière transparente lorsqu'un cookie d'authentification n'est plus valide. Cela garantit une sécurité renforcée en cas de besoin de ré-authentification.

Cet article a été écrit à l'aide de i-Tego ChatBot, en réponse à la question : "Dans le contexte d'OAuthSD, expliquer SSO, SLI, SLO, SRA."

OIDC et les Application à page unique : exemple d'une belle mascarade !

DnC — 2022-09-16T16:37:00Z

Une application à page unique (SPA) est une application Web qui charge une seule page HTML à partir du serveur Web, puis la met à jour de manière dynamique en réponse à l'interaction de l'utilisateur et à d'autres événements.

Tirant argument des progrès des navigateurs, permettant à Javascript de mettre en œuvre les règles CORS et d'accéder au cryptage, certains préconisent de mettre en œuvre le flux de code avec autorisation plutôt que le flux implicite.

La magie du flux "Authorization Code" est alors évoquée pour prétendre que l'accès aux données est sécurisé. Ce n'est que pure mascarade ! Bling bling bling ...

Une application à page unique est une application "sans back-end"

Plusieurs architectures permettent de créer des applications à page unique. La tendance est l'architecture "serveur léger", qui installe sur l'agent utilisateur ( en général le navigateur de l'utilisateur ) la page initiale contenant du code Javascript. Ce code assurera la logique et les transitions d'état de l'application, celle-ci obtenant ses données d'API RESTful protégées par OAuth 2.0. Dans cette configuration, l'application réside sur l'agent utilisateur et non sur le serveur : une application à page unique est donc une application "sans back-end".

Les SPA pourraient (maintenant ?) mettre en œuvre le flux de code avec autorisation (Authorization Code Grant)

Il est de nombreuses configurations dans lesquelles les hôtes de l'application et les points de terminaison des services se situent sur des serveurs différents : serveur d'authentification, ressources protégées (RS) ou API.

Les applications à page unique en sont un bon exemple.

En utilisation Web normale, cette approche multi-hôte ou, plus précisément, "multi-origines" est restreinte pour de bonnes raisons de sécurité. Les déclarations de partage de ressources multi-origines ( Cross-Origin Resource Sharing, CORS ) permettent de contourner la contrainte.

Les navigateurs se sont améliorés depuis la conception du flux implicite. La mise en œuvre de CORS pour autoriser la demande de jeton à partir de JavaScript est maintenant disponible, ainsi que les API de cryptographie nécessaires pour valider la signature du jeton JWT.
Il est donc techniquement possible d'utiliser le flux de code d'autorisation pour l'authentification et l'autorisation des applications sans back-end, y compris pour les applications à page unique.

Faut-il en déduire pour autant que l'utilisation de ce flux, dans cette configuration, garantit la sécurité des données ?

Avec les SPA, les problèmes de la sécurité de l'authentification restent posés

Les SPA sont des applications "sans-back-end". Leur code se trouve sur l'agent utilisateur, donc n'importe où, contrairement aux applications "avec back-end" dont le code, unique, est protégé au sein d'un serveur. A ce titre :

Sont exposés dans le code, de façon plus ou moins accessible au public :
- l'identifiant et le secret de l'application,
- les jetons d'accès ou d'identité.

Avec l'identifiant et le secret, une application malicieuse peut se procurer des jetons. Avec les jetons, elle pourrait demander des données au nom de la véritable application.

L'URL de redirection est celle de l'application, donc celle de son hôte, c'est à dire l'user-agent. Elle ne peut être inscrite sur le serveur et doit être fournie par l'application.
Si on est dans le cas d'user-agent de station de travail ( desktops ) situés dans un espace de confiance ( un ou plusieurs domaines connus ), il reste encore possible de comparer cette URL à un modèle enregistré sur le serveur d'autorisation. Mais même dans ce cas, si l'application malveillante se trouve sur le même hôte [1], la distinction est impossible. Si on a affaire à une application de mobile, cela devient vraiment risqué.

Dans le cas d'une application de mobile, la demande de jeton au point d'entrée Token et la réponse ne circulent pas dans une liaison de serveur ( celui de l'application ) à serveur ( le serveur d'authentification ) dans laquelle les deux extrémités sont identifiées, mais entre différents mobiles non identifiés et le serveur d'authentification. Ainsi disparaît une des qualités reconnues du flux de code d'autorisation appliqué aux clients avec back-end.

Il existe bien des méthodes complémentaires permettant de lier les jetons à l'user-agent ou bien à l'identifiant de connexion TLS (TLS Token Binding). Cela permet de prouver que l'user-agent ( ex. le navigateur de l'utilisateur final ) est bien celui avec lequel l'authentification a été effectuée et le jeton créé. Mais cela ne permet pas de discriminer la bonne application d'un malware exécuté sur la même liaison TLS. Dans le même ordre d'idées, la technique de preuve de possession Proof of Possession (PoP) semble conduire à la même conclusion.

En particulier, la méthode "Proof Key for Code Exchange, PKCE" , appliquée aux applications sans back-end dans le cadre du flux Authorization Code, renforce la sécurité en évitant le détournement du code d'autorisation. Avec cette technique, le secret de l'application n'est pas utilisé, ce qui permet de ne pas le divulguer. Cependant, cela interdit d'identifier l'application. PKCE permet de s'assurer que l'application qui présente le code d'autorisation est bien celle dans laquelle a été effectuée la procédure d'identification de l'utilisateur final, quelle que soit cette application.

Dans le cas d'une SPA comme dans celui de toute application sans back-end [2], il n'est pas possible de s'assurer que l'application qui présente le jeton est bien l'application attendue, et pas un malware.
De fait, il revient à l'utilisateur d'identifier l'application ! Cela va bien dans le premier paradigme (protéger les données de l'utilisateur), mais pas dans le deuxième (protéger les données de l'entité).

Encapsuler les données cryptées dans une classe Javascript ???

Avec les SPA, il n'est pas possible de stocker des informations d'identification selon les méthodes classiques, telles que les jetons d'accès dans les cookies et le stockage de session. Au lieu de cela, on imagine de conserver les données sensibles dans des variables JavaScript.

Certains recommandent alors d'utiliser une classe Javascript pour stocker et fournir ces variables. Cette méthode reçoit le joli nom d'"encapsulation" qui donne un aspect sérieux et innovant à une méthode pourtant bien banale.

Cependant, il ne s'agit là que d'une méthode d'obfuscation dont l'efficacité est insuffisante face à un attaquant déterminé. Un simple debugger web (tous les navigateurs modernes en intègrent un) permet d'exécuter pas à pas le code et de voir passer les variables.

Pourquoi les spécifications confirment-elles une pratique douteuse ?

On peut lire dans le document Health Relationship Trust Profile for OAuth 2.0 [3]

2.1.3. Client intégré au navigateur avec délégation d'utilisateur

Ce type de client s'applique aux clients qui agissent pour le compte d'un propriétaire de ressource particulier et nécessitent la délégation des droits de cet utilisateur pour accéder à la ressource protégée. De plus, ces clients sont intégrés à un navigateur Web et partagent efficacement une session active entre les systèmes.

Ces clients utilisent le flux implicite de OAuth 2 en envoyant un propriétaire de ressource au point terminal Authorize pour obtenir une autorisation. L'utilisateur DOIT s'authentifier auprès du point terminal Authorize. Le navigateur Web de l'utilisateur est ensuite redirigé vers un URI hébergé par le client, à partir duquel le client peut directement obtenir un jeton d'accès. Étant donné que le client lui-même ne s'authentifie jamais auprès du serveur et que le jeton est mis directement à la disposition du navigateur, ce flux ne convient que pour les clients incorporés dans un navigateur Web, tel qu'un client JavaScript sans composant de serveur principal. Dans la mesure du possible, il est préférable d'utiliser le flux de code d'autorisation en raison de ses propriétés de sécurité supérieures.

Ce type de client NE DOIT PAS demander ou recevoir un jeton d'actualisation. Les jetons d'accès émis à ce type de client DOIVENT être de courte durée et DEVRAIENT être rejetés à l'expiration de la session authentifiée de l'utilisateur avec le client.

Il est donc bien reconnu qu'il y a un problème que le flux de code d'autorisation ne résoudra pas. Ce flux est sans doute "de sécurité supérieure", mais dans le cas des applications sans back-end il échoue à authentifier l'application, à laquelle peut se substituer un malware situé sur l'agent utilisateur.

Pourtant, la rédaction du paragraphe donne à penser que le flux de code d'autorisation fera mieux que le flux implicite. Et on évite de façon simple l'exposition du secret de l'application, et pour cause : "le client lui-même ne s'authentifie jamais auprès du serveur".

Dans ce contexte, évoquer la sécurité offerte par le flux "Authorization Code" est une mascarade : n.f. comédie hypocrite, mise en scène trompeuse.

Un article présentant le contre et concluant sur le pour

Voici un article intéressant pour l'analyse qui est faite : SECURELY USING THE OIDC AUTHORIZATION CODE FLOW AND A PUBLIC CLIENT WITH SINGLE PAGE APPLICATIONS.

L'auteur préconise l'utilisation du flux d'autorisation avec code pour les SPA publiques, mais en fait une analyse détaillée qui met bien en évidence les multiples insuffisances de la configuration. Contrairement au titre "Securely ..." et à la conclusion de l'article, voilà encore une ambigüité.

En titrant sur les applications publiques, l'auteur évite au moins la divulgation du secret de l'application, puisqu'il n'y en a pas. Cela va faciliter le travail des applications malicieuses ! n'allons pas demander des données protégées comme cela.

Incompétence ou mensonge de marketing ?

Notre article a été motivé par la lecture de celui-ci : https://www.ubisecure.com/single-si....

Le fil rouge de cet article est simple :

1. Les progrès des navigateurs (CORS et cryptographie) permettent à Javascript de mettre en œuvre le flux authorization code.

2. Donc, il ne faut plus mettre en œuvre le flux implicite avec les SPA, mais le flux Authorization Code.
Sous entendu : puisque vous savez bien que le flux Authorization Code est celui qu'il faut employer avec OIDC, et qu'on vous avait bien dit que le flux implicite était de sécurité douteuse, vous comprenez que tout va bien maintenant.

3. Bien sûr, on doit stocker les jetons. Il faut les encapsuler dans une classe, comme cela ils seront bien cachés.

Alors, incompétence ou intox ? Ne s'agirait-il pas de faire croire à un dispositif nouveau et créditer ainsi l'existence d'un avantage comparatif sur la concurrence ?

Pourquoi mentir ?

OpenID Connect a une bonne image, cela se vend bien. Tant pis si les données ne sont sécurisées que dans le cas des applications Web classiques. Vous voulez suivre la tendance des applications pour mobile ? Alors les marketeurs vous vendront OIDC sans vous avertir des limitations.
Mieux : ils mettront en avant les méthodes complémentaires, telles que PKCE ou POP, en laissant croire qu'elles apportent la solution au problème de l'authentification d'une l'application cliente sans back-end.

Qu'en est-il des serveurs headless ?

La configuration "serveur headless" est une architecture qui permet aux rédacteurs de produire et d'organiser du contenu, tout en fournissant aux développeurs des données structurées qui peuvent être affichées à l'aide d'un système distinct sur le front-end d'un site Web ou d'une application.

On aboutit souvent, côté front-end, à une SPA.
Mais, puisque les données sont servies par une application avec back-end, il y a moyen de demander à l'utilisateur final une authentification OIDC sur cette application, inscrite comme cliente du serveur OIDC. Si cela donne une garantie sur l'habilitation de l'utilisateur à accéder aux données, cela ne permettra pas d'identifier la SPA et ce qu'elle fait des données.

Il n'y a donc aucun espoir de sécuriser les SPA ?

Il y a une piste intéressante avec les applications installées sur mobile en mode Progressive Web App (PWA). Sous certaines conditions, le code et les données des PWA sont maintenus, côté mobile, identiques à leur modèle côté serveur. Une telle architecture SPA - Serveur Headless (voyez SPIP CMS headless + Gatsby) pourrait donc être convenablement sécurisée avec OIDC.

i-Tego vous accompagne

i-Tego (héritière de DnC) exerce un conseil et une assistance. Nous aidons nos clients à mettre en œuvre leur propre serveur OAuthSD. Nous accompagnons les Dev/Ops en leur transférant notre compétence, ce qui aboutit à n'utiliser OIDC que dans des configurations sécurisées.
Et nous reconnaissons à sa juste valeur le travail des IT pour protéger l'accès au réseau, et créer ainsi "l'espace de confiance" requis pour la bonne application d'OpenID Connect.

[1] ce qui est non seulement le cas courant mais aussi le cas ( worst case ) que l'on doit prendre en compte pour une analyse de sécurité

[2] Tout comme dans le cas d'une application native de mobile et de toute application sans back-end. C'est le même problème, sauf peut-être pour les applications de desktop dans un espace de confiance

[3] Qui peut traduire "Health Relationship Trust Profile" ? Google Translator donne "Profil de confiance des relations de santé". Ce titre incompréhensible aurait-il pour but de donner un aspect pseudo-scientifique à un texte par ailleurs bien obscur ?

La fin des mots de passe : NoPassConnect

DnC — 2021-05-25T14:43:00Z

i-Tego [1] développe NoPassConnect pour le serveur OAuthSD, une application de mobile permettant une identification très sécurisée de l'utilisateur final sans mot de passe.

Fondée sur les meilleures pratiques cryptographiques, cette méthode est fermée à une utilisation publique et se trouve donc particulièrement adaptée à la sécurisation des accès aux données dans un domaine d'entreprise.

OAuthSD + NoPassConnect est une solution idéale pour sécuriser les accès aux applications des entreprises dans le cadre du télétravail.

La vidéo suivante montre comment ouvrir une session OpenID Connect en un clic et sans mot de passe :

Pour fonctionner, NoPassConnect nécessite :
l'application mobile NoPassConnect installée sur un smartphone. Celui-ci doit être connecté à Internet ou connecté au réseau WiFi de l'entreprise ce qui permet une utilisation sanctuarisée dans un espace restreint.
un serveur OAuthSD avec le module d'identification NoPassConnect.
Les applications compatibles OpenID Connect n'ont pas besoin d'être modifiées.

OAuthSD peut intégrer NoPassConnect comme méthode d'identification primaire, qui remplacera avantageusement des systèmes fondés sur des lecteurs de carte par exemple.
NoPassConnect peut également être utilisé comme identification secondaire (Identification à deux facteurs, TFA).

Les avantages de NoPassConnect :

Productivité : NoPassConnect permet une connexion ultra-rapide en mode SSO : il suffit de scanner un QR-Code présenté à l'écran par OAuthSD (une fois au début d'une séance de travail), le reste est automatique.
SmartConnect élimine le besoin de mot de passe et épargne le temps perdu à rétablir les identifiants égarés.

Economie : NoPassConnect est installé sur un mobile ordinaire [2] sans nécessiter de matériel supplémentaire ni de protocoles d'installation complexes. Une entreprise peut envisager d'équiper un très grand nombre d'utilisateurs, y compris extérieurs, pour une fraction du prix d'un système d'identification matériel, avec un gain de temps pour l'administration et la maintenance. C'est l'idéal pour le télétravail !

Faible surface d'attaque : les mots de passe sont le maillon faible de l'identification. NoPassConnect les remplace par des informations cryptographiques robustes, à usage unique.
Les échanges sont limités à une liaison cryptée mobile-serveur OAuthSD.
Il n'y a pas de logiciel à installer sur les stations de travail ou sur les navigateurs (contrairement à un lecteur d'ID card) ; ceux-ci n'interviennent pas dans le protocole d'identification de NoPassConnect, ni a fortiori leurs liaisons publiques, ce qui permet d'éviter deux cibles d'attaques particulièrement vulnérables.

De plus :
NoPassConnect est fondé sur une communication par le réseau de données mobiles (et non l'Internet) entre un mobile connecté et le serveur d'authentification (OP) auquel les applications ont délégué l'identification des utilisateurs.

NoPassConnect ne répond jamais à une demande et ne nécessite pas d'entrée au clavier (pas d'identifiant, de mot de passe ou de code) ce qui ferme la plupart des possibilité d'attaques et distingue la solution de ses concurrentes.

Ces deux caractéristiques sont innovantes et constituent un apport original.

Sécurité : Mieux qu'un mot de passe qui peut être compromis, un smartphone est un objet très personnel, mieux gardé par son propriétaire que tout autre objet. Sa perte ou son vol sont rapidement constatés (alors qu'il n'y a généralement pas moyen de savoir si un mot de passe a été compromis), ce qui permet à un administrateur d'invalider rapidement son enregistrement sur le serveur OAuthSD.

De plus, les smartphones sont équipés de systèmes de reconnaissance biométrique de plus en plus performants. L'identification au moyen du smartphone permet donc de préjuger valablement de l'identité de l'utilisateur final.

Segmentation géographique : Par défaut, l'usage de NoPassConnect peut se faire à partir de n'importe quelle connexion de données, qu'il s'agisse du réseau d'un opérateur ou d'un réseau WiFi. L'usage de NoPassConnect peut-être limité au réseau WiFi de l'entreprise, jusqu'à sélectionner par leur IP locale les bornes autorisées. Il serait également possible d'autoriser une connexion domestique donnée pour permettre le travail à domicile. Il est également possible, sur un réseau d'entreprise, de définir les postes de travail capables ou non de se connecter avec NoPassConnect .

Authentification : NoPassConnect impose l'identifiant OpenID de l'utilisateur, qui est intégré au moment de la configuration initiale du mobile sous le contrôle d'un administrateur. Au cours de cette opération, le mobile doit scanner un QR-Code présenté par l'administrateur, ce qui permet d'identifier l'utilisateur avec rigueur ( à l'opposé de l'enregistrement à distance tel que pratiqué par WebAuthn par exemple ).

Les administrateurs peuvent affecter en temps réel les autorisations ou dénier les accès. Plusieurs dispositifs permettent de détecter et de bloquer automatiquement des usages détournés, comme par exemple l'utilisation d'une autre station de travail que celles qui auront été autorisées, etc.

En résumé, les avantages déterminants pour la sécurité des données d'une entreprise sont : l'utilisation de moyens privés, l'identification de l'utilisateur assurée par un administrateur, la possibilité de limiter l'usage à des lieux déterminés.

Entendu ...

Bah, trop simple le QR-Code qui sert de mot de passe !

Pas du tout : le QR-Code n'est qu'un identifiant de session pour les échanges qui vont suivre entre le serveur et le smartphone. Il est éphémère et ne peut donc être réutilisé. L'authentification résulte d'un échange de données faisant appel à des techniques cryptographiques fortes. Le navigateur n'intervient pas dans les échanges qui se font directement entre le smartphone et le serveur OAuthSD.

Ah oui, c'est un Time-based One-time Password (TOTP) comme Google Authenticator !
Eh bien non :

NoPassConnect est un dispositif privé, ne faisant pas appel à des systèmes tiers, pour une meilleure sécurité et une parfaite confidentialité.

NoPassConnect impose l'identité de l'utilisateur de l'entreprise, configurée par un administrateur. Un TOTP ne fait que vérifier que l'utilisateur est bien celui qui s'est inscrit lui-même sur le système. En somme, un TOTP protège l'utilisateur tandis que NoPassConnect protège l'entreprise propriétaire du serveur OAuthSD.

OAuthSD propose le TOTP Google Authenticator pour l'authentification à deux facteurs : jugez de la différence par vous même.

Ah oui, c'est comme la confirmation par SMS !
Eh bien non :

Le 2FA par SMS n'est pas sécurisé, alors que NoPassConnect échange des données cryptées sur un canal sécurisé avec SSL/TLS.

De plus le code reçu par SMS doit être retourné par le même canal (le navigateur), ce qui ouvre la porte à de nombreuses techniques d'interception telles que le l'ingénierie sociale, l'interception de trafic, le key-login ; avec NoPassConnect le navigateur n'intervient pas dans ces échanges, l'identification se fait entre le smartphone et le serveur OAuthSD.

Et si c'est l'utilisateur final lui-même qui a fourni son numéro de portable au moment de son inscription, on n'a absolument aucune information sur son identité réelle ! NoPassConnect impose la configuration du smartphone sous le contrôle d'un administrateur.

J'ai trouvé : c'est comme WebAuthn !

C'est assez proche en apparence, mais très différent : NoPassConnect concoure à l'ouverture et à la fermeture d'une session OpenID Connect à partir d'une application qui lui est extérieure, tandis que WebAuthn se limite à l'identification directe de son porteur.

C'est également très différent en termes de sécurité :

WebAuthn présente un désavantage important pour la sécurité d'une entreprise : comme la plupart des système de login, WebAuthn est un système public dans le sens où c'est l'utilisateur qui enregistre de façon anonyme son mobile, rien ne permet de l'identifier. Permettre à un utilisateur de s'enregistrer sans qu'il y ait une étape d'identification physique, c'est exactement comme lui permettre de fabriquer lui-même sa carte d'identité, et encore : en remplaçant son nom par un pseudo.

A l'inverse, l'enregistrement d'un mobile NoPassConnect est fait à l'initiative et sous le contrôle d'un administrateur de l'entreprise, en présentiel, ce qui permet d'enregistrer dans le serveur OpenID Connect l'identité réelle de l'utilisateur.

Enfin, répétons-le : avec NoPassConnect, le navigateur n'intervient pas dans le processus d'identification qui se fait directement entre le smartphone et le serveur OAuthSD.

Ah oui, c'est un peu comme un lecteur d'ID card ...
Presque ! En mieux :

C'est plus économique, plus facile à déployer, moins vulnérable.

De plus, NoPassConnect n'étant pas lié physiquement à un poste de travail, il peut être déployé hors du périmètre de l'entreprise. Cela n'interdit pas de limiter l'utilisation de NoPassConnect à un ou plusieurs postes de travail, c'est l'un des avantages de scanner le QR-Code affiché par le poste de travail !

Enfin, si un utilisateur peut oublier sa carte dans le lecteur en quittant le bureau, il est probable qu'il n'oubliera pas de prendre son smartphone avec lui...

[1] i-Tego est une nouvelle société créée en juillet 2021 après la fermeture de DnC en décembre 2020. B.D. a commencé le développement de SmartConnect dans l'intervalle en utilisant provisoirement ce site web en attendant qu'i-Tego possède son propre site documentaire

[2] Actuellement sur système Android, IOS en cours de développement.

[DR] Composants logiciels de OAuthSD / SmartConnect

SmartConnect est une application de mobile (4) ( Android ou iOS) qui nécessite un serveur OAuthSD (1). Pour son fonctionnement, l'application SmartConnect est en relation avec un module d'authentification (2) (Pluggable Authentication Module, PAM) intégré à OAuthSD, mais n'est pas connecté aux applications compatibles OpenID Connect (3).
SmartConnect se situe au sein des distributions OAuthSD comme représenté dans le le tableau suivant :

Dans ce tableau, les composants sur fond bleu-clair sont développés par DnC :

OAuthSD comprend trois groupes de composants :
le Superviseur, est une application Web permettant aux administrateurs d'enregistrer les applications clientes d'OAuthSD, de contrôler l'inscription des utilisateurs et de leurs droits sur les applications et enfin de suivre le fonctionnement des authentifications.
Le Daemon (le serveur OIDC à proprement parler) qui est construit sur des modules intermédiaires (middleware) développés par DnC fournissant la version haut-niveau des contrôleurs Authorize, Token etc., et finalement sur des bibliothèques open-source pour le code de bas-niveau.
Des modules d'authentification (Pluggable Authentification Modules (PAM)) intégrés à OAuthSD assurant l'identification primaire et secondaire pour l'identification à deux facteurs.

Le module NoPassConnect (ex IdentMaster, SmartConnect) assure la communication entre le mobile équipé de l'application NoPassConnectet le serveur. Il comporte également une application qui permet aux administrateurs de configurer l'instance NoPassConnectd'un mobile donné et de l'enregistrer sur le serveur.

Pour pouvoir déléguer l'authentification au serveur OAuthSD, les applications doivent être dotés d'un module OpenID Connect. De plus en plus d'applications professionnelles intègrent un tel module. Les applications qui ne sont pas directement compatibles offrent souvent un système de modules qui permet d'ajouter la fonctionnalité OIDC. Il en est ainsi de WordPress et de phpBB.

Les applications d'Identité sont des logiciels dédiés installés sur le mobile au-dessus du système d'exploitation Android, iOS, BlackBerry, etc. Ce sont donc des applications natives, à l'inverse par exemple de l'authentification par SMS qui s'appuie sur une application existante ou d'autres procédés s'appuyant sur le navigateur. L'application NoPassConnect est une application native, développée en Java, qui peut être installée par l'utilisateur.

[CONF] Particularités du procédé en faveur de la sécurité

[CONF] Comparé au principe du TOTP ou de la vérification par SMS (un code dépendant de l'utilisateur et limité dans le temps), SmartConnect est beaucoup plus sécurisé : le QR-Code est à usage unique, et la réponse de l'application SmartConnect intègre l'identifiant OpenID de l'utilisateur et l'ID du mobile, mixé avec un alea qui rend la réponse unique, le tout transmis au moyen d'un jeton crypté.

[CONF] Notons également que, contrairement à un système de confirmation TFA, l'utilisateur n'est pas interrogé à l'initiative d'un système dont il ignore le lien réel avec l'application légitime (celle qu'il veut lancer), mais c'est lui qui prend l'initiative de poursuivre (en scannant le QR-Code) le dialogue d'authentification qu'il a initialisé depuis l'application. L'utilisateur est actif au lieu d'être passif. Le mobile ne traite pas de connexion entrante, mais utilise le canal de retour de la connexion qu'il a lui-même établie, le mettant ainsi à l'abri d'attaques web.

[CONF] Enfin, le terminal sur lequel s'affiche le QR-Code se trouve lié dans le processus d'authentification, ce qui permet au serveur OAuthSD de s'assurer que l'utilisateur est bien devant le terminal. Ainsi, les authentifications ne peuvent être initiées que depuis des terminaux répertoriés.

Expérimental : téléchargez et installez l'application sur votre mobile Android

Sur votre mobile Android :

Téléchargez l'APK :
i-tego.com/store/app-release.apk
Activez les sources inconnues :
Allez dans les paramètres, puis Sécurité
Recherchez l'APK sur votre téléphone (à l'aide d'un explorateur de fichiers par exemple)
Lancez le fichier APK et suivez les instructions
Désactivez les sources inconnues

OAuthSD vers la Certification OpenID (r)

DnC — 2021-04-28T18:10:00Z

OAuthSD a satisfait aux tests en vue de la certification OpenID.

L'auteur (B.D.) est membre de l'OpenID Foundation, ce qui lui permet d'introduire OAuthSD dans le processus de certification en vue d'obtenir le label "OpenID Certified".

Avril 2021 - Nouvelle série de tests

Les tests OIDF Conformance ont évolué, OAuthSD aussi, de nouveaux tests ont été effectués pour les flux OpenID Authorization Code et Implicit.

Tests de certification du flux Authorization Code (response_type 'code')
Le résultat est visible à l'URL :
https://www.certification.openid.net/plan-detail.html?plan=5pu5MgJdbusGd&public=true

Commentaires :
test "oidcc-unsigned-request-object-supported-correctly-or-rejected-as-unsupported" : EXPERIMENTAL : OAuthSD implémente le paramètre 'request' sous sa forme JWT non signé et passé par valeur (comme l'attend ce test).
test 'oidcc-claims-essential' : Notre avis et qu'il s'agit là d'un écart inutile par rapport à la rigueur de la spécification générale, préjudiciable à la sécurité des données personnelles. OAuthSD n'implémente pas le paramètre 'claims' ainsi que l'indique son document de découverte, le test devrait donc être sauté. Cependant, le test se traduit par un avertissement, ce qui n'est pas un obstacle à la certification.
test "oidcc-refresh-token" : ce test est sauté car le client de test a été configuré sans le flux "refresh_token".

Test de certification du flux Implicit (response_type 'token' et 'id_token token')

Le résultat est visible à l'URL :
https://www.certification.openid.net/plan-detail.html?plan=7Z0tOWnMttGlm&public=true

Cette série appelle les mêmes commentaires que la précédente.

Mai 2019 - Configuration Basic OP : succès à 100% !

Cette configuration teste OAuthSD en tant que OP (OpenID Connect Provider) avec le flux Authorization Code.
Le résultat des tests peut être vu ci-dessous. On voit que OAuthSD remplit 100% des exigences (Il est normal que le test OP-redirect_uri-NotReg reste à l'état non complété) [1]

La certification OpenID peut être obtenue avec quelques tests à l'état "Warning". Notre engagement de qualité nous commande de satisfaire à 100% des tests.

[1] Il est normal que le test OP-redirect_uri-NotReg reste à l'état non complété car "Ce test devrait avoir pour résultat que le fournisseur OpenID affiche un message d'erreur dans votre agent d'utilisateur. Vous devez ignorer le statut de ce test dans l'outil de test, car il sera incomplet."

API Open ID Connect : Introspection (Introspection Endpoint)

DnC — 2021-04-15T08:15:00Z

L'introspection permet à une application cliente ou à un serveur de ressource (RS) de valider un jeton auprès du serveur d'authentification (AS) .

Les jetons soumis peuvent être du type Access Token, Identity Token (JWT) ou Json Web Encryption (JWE).

Implémentation de l'Introspection

Il n'y a pas (à ce jour) de "norme" définissant l'Introspection pour OpenID Connect. Cependant, OAuthSD, ainsi que les implémentations courantes, se fonde sur la proposition de standard RFC 7662 : OAuth 2.0 Token Introspection. DnC a proposé une fonction d'introspection pour la bibliothèque OAuth 2.0 PHP.

Proposition de standard RFC 7662

Traduction d'un extrait du document RFC 7662 : OAuth 2.0 Token Introspection

2.2. Réponse d'introspection

Le serveur répond avec un objet JSON [RFC7159] dans le format "application/json "avec les membres de niveau supérieur suivants.

active
CHAMPS OBLIGATOIRE. booléen indiquant si le jeton présenté est actuellement actif ou non. Les spécificités de l'état "actif" d'un jeton variera en fonction de la mise en œuvre du serveur d'autorisation et les informations qu'il conserve sur ses jetons, mais une "vraie"
valeur retournée pour la propriété "active" indiquera généralement qu'un jeton donné a été émis par ce serveur d'autorisation, n'a pas été révoqué par le propriétaire de la ressource et relève de sa fenêtre de validité donnée (par exemple, après son heure d'émission et avant son heure d'expiration). Voir la section 4 pour des informations sur la mise en œuvre de ces contrôles.

scope
OPTIONNEL. Une chaîne JSON contenant une liste de portées associées à ce jeton, dans le format décrit dans la Section 3.3 de OAuth 2.0 [RFC6749].

client_id
OPTIONNEL. Identifiant de client pour le client OAuth 2.0 qui a demandé ce jeton.

username
OPTIONNEL. Identifiant lisible par l'homme pour le propriétaire de la ressource qui a autorisé ce jeton.

token_type
OPTIONNEL. Type de jeton tel que défini dans la section 5.1 de OAuth 2.0 [RFC6749].

exp
OPTIONNEL. Horodatage entier, mesuré en nombre de secondes depuis le 1er janvier 1970 UTC, en indiquant la date d'expiration de ce jeton, comme défini dans JWT [RFC7519].

iat
OPTIONNEL. Horodatage entier, mesuré en nombre de secondes depuis le 1er janvier 1970 UTC, en indiquant quand ce jeton a été publié à l'origine, tel que défini dans JWT [RFC7519].

nbf
OPTIONNEL. Horodatage entier, mesuré en nombre de secondes depuis le 1er janvier 1970 UTC, en indiquant quand ce jeton ne doit pas être utilisé auparavant, comme défini dans JWT [RFC7519].

sub
OPTIONNEL. Sujet du jeton, tel que défini dans JWT [RFC7519].
Généralement, un identifiant lisible par machine du propriétaire de la ressource qui a autorisé ce jeton.

aud
OPTIONNEL. chaîne Identifiant spécifique au service ou liste de chaînes identifiants représentant le public visé pour ce jeton, comme défini dans JWT [RFC7519].

iss
OPTIONNEL. Chaîne représentant l'émetteur de ce jeton, sous la forme définie dans JWT [RFC7519].

jti
OPTIONNEL. Identificateur de chaîne pour le jeton, tel que défini dans JWT [RFC7519].

Des implémentations spécifiques PEUVENT étendre cette structure avec leurs propres noms de réponse spécifiques aux services en tant que membres de niveau supérieur de cet objet JSON. Les noms de réponse destinés à être utilisés sur plusieurs domaines DOIVENT être inscrit dans le registre "OAuth Token Introspection Response" défini à la section 3.1.

Le serveur d'autorisation PEUT répondre différemment à différentes ressources protégées faisant la même demande. Par exemple, un serveur d'autorisation PEUT limiter les portées d'un jeton donné retourné pour chaque ressource protégée pour empêcher une ressource protégée d'en apprendre davantage sur le réseau que nécessaire pour son fonctionnement.

La réponse PEUT être mise en cache par la ressource protégée pour améliorer les performances et réduire la charge sur le point final d'introspection, mais au prix de la qualité de la validité des informations utilisées par la ressource protégée pour prendre des décisions d'autorisation. Voir la section 4 pour plus d'informations en ce qui concerne le compromis lorsque la réponse est mise en cache.

DnC s'est inspiré de cette proposition de standard pour étendre les jetons acceptés aux trois types Access Token, Identity Token (JWT) ou Json Web Encryption (JWE).

Point d'extrémité d'introspection

Point d'extrémité d'introspection (Introspection Endpoint)

https://oa.dnc.global/introspect

Forme de la demande d'Introspection

La demande ne doit être effectuée que par la méthode POST.

Note :
OAuthSD ne nécessite pas l'enregistrement d'un scope réservé pour autoriser le client à utiliser l'introspection, contrairement à d'autres implémentations. Le scope 'openid' est également inutile, le controleur fonctionnant aussi bien dans le cadre de OAuth 2.0 que celui d'OpenID Connect.

Contrôle de l'accès

Les demandes adressées au point de terminaison d'introspection doivent être authentifiées avec les informations d'identification du client (Client Credentials Grant) ou autorisées avec un jeton d'accès au porteur (Bearer Token).
En conséquence, l'application appelante (ou le serveur de ressource) doit être enregistrée comme cliente sur le serveur d'authentification

Client Credentials Grant
C'est l'approche la plus simple et celle qui est recommandée.
L'application appelante (ou le serveur de ressource) doit être enregistrée comme cliente sur le serveur d'authentification [1].
L'authentification est effectuée en utilisant l'authentification HTTP Basic (cf. section 2.3.1 de OAuth 2.0 [RFC6749]). Les identifiants client_id et client_secret sont ceux qui ont été définis lors de l'inscription de l'application cliente sur le serveur.

Bearer Token
Cette approche nécessite un jeton d'accès pour autoriser la demande d'introspection.
Pour un serveur de ressource, cela est plus compliqué du fait de la durée limitée de validité du jeton d'accès, contraignant à une nouvelle demande de jeton. Une façon d'obtenir un tel jeton consiste à inscrire l'application pour le flux Client Credential Grant.
L'authentification est effectuée en passant le jeton dans l'en-tête Authorization de la demande d'introspection.

Note :
OAuthSD permet de sauter cette étape en réglant la constante de configuration AUTHENTICATE_INTROSPECT_REQUEST à false.
De fait, la rfc indique que l'objectif de cette authentification client est "Pour empêcher les attaques par balayage de jetons ..."
Les attaques par balayage (scanning) pourraient être mieux atténuées de certaines autres manières, en particulier au niveau du réseau.
De plus, donner à un client inconnu des informations sur la validité du jeton n'est pas un problème de sécurité élevé.

Requête

Les paramètre suivants doivent être postés :

token (OBLIGATOIRE) : le jeton à valider. Les jetons soumis peuvent être du type Access Token, Identity Token (JWT) ou Json Web Encryption (JWE).
Si un jeton JWE est reconnu, il est déchiffré et le processus se poursuit avec la charge utile du JWE, qui n'est autre que le JWT.

requester_ip (OPTIONNEL) : Lorsque l'Introspection est demandée par une ressource protégée (distincte de l'application cliente à l'origine de l'authentification), il importe de ne pas répondre à un malware ayant intercepté le jeton et tentant de le ré-utiliser.
Pour cela, la ressource protégée doit transmettre l'IP du demandeur au moyen du paramètre 'requester_ip'.
La fonction d'introspection d'OAuthSD vérifie que l'IP indiquée est celle qui a été enregistré avec l'application cliente ou, à défaut, se trouve dans le sous réseau de l'application cliente tel qu'il peut être déterminé à partir de l'URL de retour.

Notes :
OAuthSD ne nécessite pas le paramètre token_type.
Avertissement à propos du paramètre 'alg' : la RFC 7515, section 4.1.1 prévoit d'appliquer la valeur du paramètre 'alg' pour le choix de l'algorithme de validation de la signature.
C'est une faille de sécurité sévère, et donc une erreur de la spécification. L'introspection d'OAuthSD applique la méthode définie pour chaque application, avec laquelle les jetons sont signés, quelle que soit la valeur de 'alg' et génère une erreur si la valeur est différente.

Réponse du serveur

En cas de succès, le serveur retourne une réponse HTTP 200.

Le corps de la réponse contient un tableau portant les informations suivantes :

index	type	valeur
status	entier	code HTTP
headers	string	Headers de la réponse
page	string	JSON Array : active : true, scope : (JSON string Array) scopes associés au jeton. client_id : ID de l'application cliente qui a demandé ce jeton. username : ID OAuth de l'utilisateur final (human-readable). exp : (long) (secondes depuis le 1° janvier 1970). Unix Time de la fin de validité du jeton. iat : (long) (secondes depuis le 1° janvier 1970). Unix Time de création du jeton iss : (string) issuer : serveur d'authentification qui a diffusé ce jeton. sub : identifiant interne de l'utilisateur qui a autorisé ce jeton. aud : audience définie pour ce jeton.

Si le jeton n'est pas valide, alors que la requête n'a pas échoué, l'introspection ne retourne un code HTTP 200 et une réponse active : false.

Note :
Le traitement des erreurs d'introspection décrit dans ce qui suit est propre à cette version de OAuthSD, destinée au développement et à la mise au point d'une application mettant en oeuvre la délégation d'authentification. Conformément à la spécification, les serveurs OAuthSD de production ne donnent pas de détail sur l'erreur, mais retournent simplement un code HTTP 401 et une réponse active : false.

En cas d'échec de la requête, le corps de la réponse contient :

index	type	valeur
page	string	JSON Array : error : titre de l'erreur, error_description : description de l'erreur

La réponse HTTP ainsi que les valeurs de error et error_description sont données par le tableau suivant :

Réponse	error titre de l'erreur	error_description description de l'erreur	Explication
400	invalid_request	Only one method may be used to authenticate at a time (Auth header, GET or POST)	La requête est mal formée
400	invalid_request	Missing parameters : "token" is required	La requête Introspection requiert le paramètre 'token'.
400	invalid_request	When putting the token in the body, the method must be POST or PUT	Si on place le token dans le corps de la requête, la méthode ne peut être que POST ou PUT
400	invalid_request	The content type for POST requests must be "application/x-www-form-urlencoded	l'IETF spécifie ce type de contenu. NB : tous les serveurs Web ne remplissent pas cette variable _SERVER voir http://tools.ietf.org/html/rfc6750#section-2.2
401	invalid_token	JWT is malformed	le jeton JWT ne peut être décodé.

Exemples

Demande de validation d'un jeton d'identité, méthode Auth Header (ou "JWT Bearer" ) :

PHP

/*
Autorisation avec OAuth Server by DnC
OpenID Connect : Introspection, méthode Auth Header
*/
function oauth_authorize($idtoken) {
$Ok = false;
if ( !empty( $idtoken) ) {
$h = curl_init(AUTHENTICATION_SERVER_URL . 'introspect');
curl_setopt($h, CURLOPT_RETURNTRANSFER, true);
curl_setopt($h, CURLOPT_TIMEOUT, 10);
curl_setopt($h, CURLOPT_HTTPHEADER,
array('Authorization: Bearer ' . $idtoken));
$response = curl_exec($h);
if ( (int)curl_getinfo($h)['http_code'] === 200 ) {
$jwt = json_decode($response, true);
$Ok = ( $jwt['active'] == true );
}
}
if ( $Ok AND isset($_SERVER["HTTP_REFERER"]) ) {
$urlParts = parse_url($_SERVER["HTTP_REFERER"]);
if ( $urlParts['host'] !== $_SERVER["HTTP_HOST"] ) {
// CORS : autoriser l'origine
$issuer = $urlParts['scheme'] . "://" . $urlParts['host'];
include_spip('inc/headers');
header('Access-Control-Allow-Origin', $issuer);
}
}
return $Ok;
}

Télécharger

Variante avec méthode GET pour SPIP :
SPIP

/*
Autorisation avec OAuth Server by DnC
OpenID Connect : Introspection, méthode GET
*/
function oauth_authorize($idtoken) {
$Ok = false;
if ( !empty( $idtoken) ) {
// Interroger l'introspection de OAuth Server by DnC
include_spip('inc/distant');
$url = "http://oa.dnc.global/introspect?token=" . $idtoken;
$response = recuperer_url($url);
if ( (int)$response['status'] === 200 ) {
$jwt = json_decode($response['page'], true);
if ( $jwt['active'] == true ) {
if ( isset($_SERVER["HTTP_ORIGIN"]) ) {
// Accès HTTP (CORS) : autoriser l'origine
include_spip('inc/headers');
$issuer = trim(strtr($_SERVER["HTTP_ORIGIN"], '<>"\'', '[]##'));
header('Access-Control-Allow-Origin', $issuer);
}
$Ok = true;
}
}
}
return $Ok;
}

Télécharger

Un exemple plus complet, faisant apparaître la totalité des erreurs possibles, figure ici : OpenID Connect : Exemples complets du flux d'Autorisation via un code puis requête UserInfo.

Notes :

Dans le cas où l'application cliente et le serveur de données protégées se trouvent dans des domaines différents, il faut gérer l'autorisation HTTP, comme cela est fait dans l'exemple ci-dessus. Voyez Contrôle d'accès HTTP (CORS).

L'interrogation du serveur d'autorisation à chaque accès d'une ressource protégée peut le surcharger. Pour éviter cela, on peut mettre en cache la réponse du serveur du côté du serveur de ressource. Avec SPIP, c'est le rôle de la fonction recuperer_url_cache() qui pourra remplacer recuperer_url() dans l'exemple précédent. La fonction permet de régler le délai de garde en cache, qu'il convient de fixer à une durée assez courte (10 secondes par exemple), l'essentiel étant de ne pas bombarder le serveur. Voici un exemple :

SPIP

10) ); // Délai de 10s">

$res = recuperer_url_cache( $url, array('delai_cache' => 10) ); // Délai de 10s

La fonction décrite précédemment peut être utilisée dans une fonction d'autorisation d'accès à un objet SPIP ( ici l'objet gis de radar ) :

SPIP

function _autoriser_gis($faire, $quoi, $id, $qui, $options) {
if ( $qui['statut'] == '0minirezo' ) {
// Toujours autoriser un administrateur
return true;
} else {
if ( $idtoken = $_GET['token'] ) {
// Vérifier le jeton d'accès
return oauth_authorize($idtoken);
} else return false;
}
}

Télécharger

Il faut cependant noter que la mise en cache expose à la réutilisation du jeton par un malware.

Exemple d'appel, avec le jeton passé par la méthode Auth Header et le paramètre 'requester_ip' par Post :
PHP

// Method Bearer + parameters by Post
$data = array(
'requester_ip' => $_SERVER['SERVER_ADDR'],
);
$authorization = "Authorization: Bearer ". $res1['id_token'];
$h = curl_init($introspection_endpoint);
curl_setopt($h, CURLOPT_HTTPHEADER, array(
'Content-Type: application/x-www-form-urlencoded',
'Authorization: Bearer ' . $id_token
));
curl_setopt($h, CURLOPT_RETURNTRANSFER, true);
curl_setopt($h, CURLOPT_POST, 1);
curl_setopt($h, CURLOPT_POSTFIELDS, http_build_query($data));
...

Télécharger

Avantages et inconvénients de l'Introspection

La validation du jeton d'identité (ID Token) auprès du serveur d'authentification (introspection) présente quatre avantages importants :
elle permet de savoir si le jeton a été révoqué, contrairement à la validation locale ; c'est là un avantage fondamental pour la sécurité : si vous décidez de révoquer un jeton d'accès, alors il faut bien que les applications réagissent, le seul moyen est l'introspection.
cette méthode ne nécessite pas de connaître la clé publique de l'application cliente pour valider la signature du jeton, ce qui permet à des serveurs de ressource étrangers à l'organisation de valider les jetons reçus ;
on peut obtenir des informations sur l'utilisateur final (qui est à l'origine de l'autorisation) qui permettent d'identifier cet utilisateur et, donc, d'agir en fonction de la confiance à accorder d'après son profil ;
il est possible de mettre en œuvre la déclaration "jti" (JWT ID) qui permet au serveur d'autorisation de vérifier que le jeton n'a pas déjà été utilisé ;
OAuthSD propose également la vérification de l'IP du demandeur : si une ressource protégée a transmis l'adresse IP de son propre demandeur avec le paramètre 'requester_ip', on vérifie que cette adresse IP se trouve dans le sous-réseau de l'application cliente identifiée par la déclaration 'aud'. Cela est essentiel pour ne pas répondre à un malware ayant intercepté le jeton.

Elle a pour seul inconvénient d'augmenter le trafic avec le serveur d'autorisation.

Remarque quant au lien entre jeton d'identité et jeton d'accès et l'intérêt réel de ce dernier

Justin Richer : (openid-specs-ab)

"Il n'y a pas de relation 1:1 entre le jeton d'accès et jeton d'identité (ID Token), surtout si vous considérez que le jeton d'accès peut être actualisé ou ne pas expirer, alors que le jeton d'identité doit expirer. Le ID Token représente l'événement authn (et la session, dans une certaine mesure), alors que le jeton d'accès représente une autorisation déléguée d'accès aux informations de profil de l'utilisateur. Vous pouvez obtenir des informations sur l'événement d'authentification qui a généré le jeton d'accès à partir de l'introspection, mais il est important de se rappeler que le jeton d'accès n'est pas destiné à être étroitement lié à cet événement d'authentification. En fait, c'est toute la question d'OAuth qui lie de façon lâche l'authentification au jeton d'accès et maintient le jeton d'accès valide alors que l'utilisateur n'est plus là.

Cette remarque à propos de la faiblesse du lien entre jeton d'accès et jeton d'identité rejoint la conclusion émise à propos de la requête Userinfo : toute requête Userinfo devrait suivre le cycle : demande d'autorisation, validation du ID Token, demande Userinfo, vérification de la concordance des user_id. C'est ce qui est décrit dans les exemples.

Que vaut réellement un jeton d'accès si :
on ne peut vérifier sa validité sans introspection [2] (autant alors faire l'introspection pour le jeton d'identité),
on n'est pas certain du lien avec le jeton d'identité ?

Plus généralement, ne devrait-on pas conclure ainsi : plutôt que d'utiliser le jeton d'accès ne vaudrait-il pas mieux utiliser exclusivement le jeton d'identité ? C'est pour cela qu'il existe un flux OpenID Connect ne retournant que l'ID Token.

[1] OAuthSD autorise tous les clients enregistrés à accéder au point de terminaison d'introspection. Il est donc inutile de spécifier un scope ou une métadonnée particuliers.

[2] Une piste consiste à Emettre un jeton d'accès en tant que JWT.

API OpenId Connect : Point d'extrémité d'informations sur les clefs (Keys Endpoint)

DnC — 2021-04-14T10:15:00Z

Le protocole OpenID Connect utilise un jeton d'identité (ID Token) fondé sur JWT. La norme décrit comment une application cliente doit valider un ID Token reçu en réponse à une demande d'authentification. Cette vérification peut se faire localement (ou sinon par introspection), ce qui nécessite d'accéder aux informations sur les clés publiques.

C'est ce que permet le

Point d'extrémité d'informations sur les clefs (Keys Endpoint)

https://oa.dnc.global/keys

Forme de la demande d'informations sur les clés

La demande ne doit être effectuée que par la méthode POST.

Le client doit inclure ses informations d'authentification telles que décrites à la section 2.3. du document [RFC6749].

Exemple de requête :

POST /keys HTTP/1.1
 Host: oa.dnc.global
 Content-Type: application/x-www-form-urlencoded
 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

Réponse

En cas de succès le serveur retourne une réponse HTTP 200.
Le corps de la réponse contient une liste de définitions des clés publiques.

Chaque définition de clé est représentée sous un format JSON telle que défini dans le document JSON Web Key (JWK).

Exemple
Voici un exemple de réponse au format JSON :
[JSON]

{"keys":[{
 "kid":"618584200ef916a154008d898a1e7edc",
 "kty":"RSA",
 "alg":"RS256",
 "use":"sig",
 "e":"AQAB",
 "n":"ykcWIXjQ-f61XCJutT4JcgpmmobtB0U7ZcejT8tBD8rOZPkQDYf0Q3pMjCkNT8RRKzMYtkelY2CNn3U7kVJMgbJAtvZsCdlChVHAKvRnjwh1GR_6Zpmajm5cuz4bjQWWUIPIoXe_4JbC8nCrHdaagzB_6PrV_NILyn5unG1RLOrWx7_yzLaterDKxHTCBeOlqv_5VGFey0Ecf-X7Bj8YRx6fpamK4BcEAZSAbZMtAnTckp3hOYJgZo3MOXDxSQw1YR83i5Udcoaf7sxfhEA_b7r9CeNfgj76MKM7sdCfBMI7_JSz-YU_pJKCuT9Ny3IJQ0fQHpDzSq2oD_3cDcLjfXTGM67rXElwr9l8yrSNa29UGK4q2u9cFCQmJGlxVhZU6bzs7l4202LTJdPlzm_29jwLVvtqnVJSovMLHx84ReFtus1RdKRGB2plDQccvBNvp92D9lOnM3bAu1fKRAJwNh3hg1d6k7MVCHxoo9HVnkxzW48rAAJE2nk44a2Y0cclufBhvKRdNavldS1XOyZ_qf3qCAzsuYF1VAga8I-QOb6OyXp0KGLptbyYD-ZXISGPw3pDD3aAof_PMfFhSB96GHDnm-UCRpFHndQ_fZgtZhWugU8z22rV-irYCySqVkpE0ToWbNXNFZ9Jo1GXdwkpi1WjB7S-ipjzRFOlxhwbvZ0"},
 ...

kid

Comme différentes applications clientes peuvent utiliser la même paire de clé publique/privée, les clés sont indexées par un identifiant "kid" plutôt que par un client_id.

Cet identifiant est notamment présent dans la charge utile du jeton JWT, ce qui permettra de sélectionner la clé publique nécessaire pour valider la signature du jeton JWT.

jwks_uri, fichier jwks.json

La norme prévoit que le document de découverte .well-known/openid_configuration définisse une constante jwks_uri donnant l'URL du fichier jwks.json, sous la forme :
"jwks_uri" : "https://oa.dnc.global/jwks/jwks.json",

Cette URL permet d'obtenir la même information que par le Point d'extrémité d'informations sur les clefs. Cependant, ces données sont statiques, alors que l'appel au contrôleur Keys recalcule le fichier jwks.json à chaque fois afin de prendre en compte un éventuel changement.

UpdatekeysController

OAuthSD propose un point d'entrée "updatekeys" qui provoque le re-calcul des paires de clés publiques-privées de tous les clients ainsi que la mise à jour des informations sur les clés.
Ce contrôleur n'est accessible qu'à partir de la même adresse que le serveur et sera donc soit lancé localement par le Superviseur soit par une tâche CRON à l'aide de wget.

Notes :
Outre le fichier jwks.json, le dossier /jwks contient un fichier au format JSON pour chaque clé publique, sous le nom .json.
Compte-tenu de la charge de calcul nécessaire à l'établissement du fichier, l'appel au point d'extrémité Keys doit être réservé à des applications de confiance ou être protégé contre les attaques de type déni de service.
Pour éviter le recalcul du fichier jwks.json à chaque appel de Keys, il est possible de modifier la règle de réécriture dans le fichier .htaccess pour :
RewriteRule ^keys /jwks/jwks.json [QSA,L]
Une clé publique peut également être lue au moyen de l'API HTTP REST + TreeQL.

Lien de (re)connexion

DnC — 2021-04-02T15:30:00Z

Il peut être utile de permettre à un utilisateur de se connecter sans passer par une procédure d'identification. Par exemple lorsque le login ou le mot de passe a été perdu et pour éviter la fastidieuse procédure de récupération du "mot de passe oublié".

Nous décrivons ici comment créer un lien de reconnexion qui pourra, par exemple, être adressé à l'utilisateur dans un e-mail.

Plutôt que faire figurer le jeton d'identité dans le lien, qui peut être trop grand pour être passé en URL, on prendra l'ID Token dans une table où il se trouve indexé par son hash, et ce sera cette valeur qui sera passée dans le lien de reconnexion.

En tête de chaque page pouvant être appelée avec reconnexion, on appellera avec :

{fond=inclure/autoconnect}{env}>

la noisette suivante :

SPIP

[(#REM) 150b Autoconnect : connexion OIDC avec la méthode id_token_hint
Remplace la noisette identification pour assurer l'authentification avec l'ID Token passé par le paramètre d'URL token
auteur : B.Degoy i-Tego
licence : GNU/GPL
]
[(#ENV{token}|autoconnect{#SELF}|non)
[(#SESSION{id_auteur}|non)
<:oauth:vous_devez_vous_identifier:>.
<:oauth:vous_pas_compte:> #ENV{lang}"><:oauth:creer_compte_auteur:>
#LOGIN_PUBLIC
]
]

Télécharger

Voici le code du filtre autoconnect :

PHP SPIP

/**
* Autoconnect pour DnC SaaS (base SPIP)
* @auteur : B.Degoy i-Tego
* SPIP, Systeme de publication pour l'internet
* Arnaud Martin, Antoine Pitrou, Philippe Riviere, Emmanuel Saint-James
* Ce programme est un logiciel libre distribue sous licence GNU/GPL.
* Pour plus de details voir le fichier COPYING.txt ou l'aide en ligne.
*/
//[dnc150b]
/**
* Lancer une (re)connexion par la méthode OIDC id_token_hint avec le token fourni.
* Ceci suppose que la dernière connexion de l'utilisateur ait été enregistrée dans la table jwt.
* La table jwt est indexée par le hash de l'ID Token.
* C'est cette valeur, plus courte que l'ID token lui-même, qui est passée dans l'URL d'autoconnexion.
*
* @param mixed $idt_hash : le hash de l'ID Token
*/
function filtre_autoconnect_dist( $idt_hash, $url=null ) {
//DebugBreak("435347910947900005@127.0.0.1;d=1"); //DEBUG
// Récupérer l'ID Token et le client avec idt_hash
include_spip('base/abstract_sql');
$res = sql_fetsel('client_id, id_token', 'spip_jwt', 'idt_hash=' . sql_quote($idt_hash));
if ( ! is_null($res) ) {
// Générer un state
include_spip('inc/session');
$state = md5($idt_hash);
$state= substr($state, 0, 16);
session_set('state', $state);
// Page à laquelle rediriger après l'authentification.
if ( empty($url) ) $url = './';
$url = parametre_url($url, 'token', ''); // sans le token évidemment (car il ne sera plus valide après la (re)connexion.
session_set('caller', $url); // voir plugin oidcclient : oidc_setps.php.
// lancer une (re)connexion par la méthode OIDC id_token_hint
$redirect = '/authorize';
$redirect = parametre_url($redirect, 'response_type', 'code', '&');
$redirect = parametre_url($redirect, 'scope', 'openid sli', '&');
$redirect = parametre_url($redirect, 'prompt', 'none', '&');
$redirect = parametre_url($redirect, 'client_id', $res['client_id'], '&');
$redirect = parametre_url($redirect, 'state', $state, '&');
$redirect = parametre_url($redirect, 'url', $url, '&');
$redirect = parametre_url($redirect, 'id_token_hint', $res['id_token'], '&');
include_spip('inc/headers');
redirige_par_entete($redirect);
} else {
// idt_hash non valide ou erreur plus générale.
return ""; // pour faire échouer le test
}
}

Télécharger

Cette procédure de reconnexion revient exactement à une nouvelle connexion de l'utilisateur. Cela veut dire en particulier que le cookie SLI et les jetons seront régénérés.

Comme le jeton d'identité change, son hash change et il en résulte que le jeton passé dans le lien de reconnexion est à usage unique.