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

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."

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.

Méthodes alternatives pour le monitoring de la session OpenID Conect et le SLO

DnC — 2021-01-29T10:30:00Z

Pour synchroniser l'état de connexion de chaque application utilisée par un même utilisateur, nous avons utilisé un code javascript pour interroger régulièrement le serveur d'authentification.

S'agissant de déconnecter les sessions de toutes les applications de l'utilisateur final (SLO), il existe des alternatives.

Les trois premières alternatives font l'objet de propositions de spécification émises en 2020. OAuthSD ne met en œuvre que OpenID Connect Session Management.
La troisième solution est plus ancienne et ne devrait pas l'emporter sur ces définitions plus récentes.

Quoiqu'il en soit, la solution de monitoring implémentée par OAuthSD fonctionne parfaitement et est extrêmement simple, ne nécessitant pas de modification du serveur. Elle a l'avantage de permettre également de signaler à l'utilisateur l'approche de la fin de la session OIDC et de lui offrir de la prolonger.

Nous ne sommes donc pas très motivés pour appliquer l'une ou l'autre de ces méthodes.

OpenID Connect Front-Channel Logout

Voir : OpenID Connect Front-Channel Logout 1.0 - draft 04 (août 2020).

OpenID Connect Back-Channel Logout

Voir : OpenID Connect Back-Channel Logout 1.0 - draft 06 (août 2020).

OpenID Connect Session Management

Nous avons décrit cette méthode ici : OpenID Connect Session Management. Son principe et sa complexité sont assez semblables aux deux précédentes.
OAuthSD met en œuvre cette méthode à des fins d'expérimentation et de suivi de la norme OpenID Connect.

Solution utilisée par Drupal et Google Accounts

Voir : https://www.drupal.org/project/openid_connect_sso

Après la connexion de l'utilisateur sur le serveur ou la déconnexion de l'un des sites du réseau, le module démarre une chaîne de redirection qui visite le script SSO de chaque site du réseau.
Le script SSO définit ensuite un cookie informant le site parent de la connexion/déconnexion en attente.
Lorsque l'utilisateur visite le site réel, le cookie est lu et l'utilisateur se connecte/déconnecte automatiquement.

Cette approche est identique à celle utilisée par les comptes Google.

Le but des redirections est de donner à chaque site la possibilité de définir un cookie valide pour son domaine contournant ainsi la politique de même origine qui interdit à un site de définir un cookie pour un autre domaine.

Les redirections sont rapides et imperceptibles, car le script SSO est autonome ... et ne définit que le cookie.

/**
* @file
* Creates cookies for each of the network sites to signal a login/logout.
*/
if (empty($_SERVER['HTTP_HOST'])) {
// Some pre-HTTP/1.1 clients will not send a Host header.
// We can't work around this.
exit;
}
// The collection of SSO script addresses which form the redirection network.
// Don't include the protocol (http://, https://).
// Example url (SSO script on subdomain): "a.firstsite.com"
// Example url (SSO script in the Drupal directory): "firstsite.com/sso.php"
$network = array(
'a.firstsite.com',
'a.shop.secondsite.com',
);
// An array of network domain names. The keys are potential origin host names
// which do not appear in the list above, and each value is the cookie domain
// name for that host.
// $domains = array();
// Enable HTTPS for all redirect URLs.
// $https = true;
// Enable adding the domain name to the cookie name.
// $cookie_name_strict = true;
// Validate the query parameters and network size.
if (!sso_validate_query_params() || count($network) < 2) {
exit;
}
// $_SERVER['HTTP_HOST'] is lowercased here per specifications.
$host = strtolower($_SERVER['HTTP_HOST']);
$origin_host = $_GET['origin_host'];
$origin_domain = isset($domains[$origin_host]) ? $domains[$origin_host] : $origin_host;
// Find the next site that needs to be visited in the $network, by removing
// the origin site re-keying the array.
foreach ($network as $delta => $site) {
if (strpos($site, $origin_domain) === 0 || strpos($site, 'a.' . $origin_domain) === 0) {
unset($network[$delta]);
}
}
$network = array_values($network);
if (ltrim($host, 'a.') == $origin_domain) {
// We are on the site which has started the process.
// No need to create the cookie, the site already handled its login / logout.
// Start from the beginning of the redirect list.
$redirect_destination = sso_redirect_url($network[0], !empty($https));
}
else {
sso_create_cookie($_GET['op']);
foreach ($network as $delta => $site) {
if (strpos($site, $host) === 0 || strpos($site, 'a.' . $host) === 0) {
$current_site_delta = $delta;
break;
}
}
if (!isset($current_site_delta)) {
trigger_error('Current site not found in network', E_USER_ERROR);
exit;
}
$next_site_delta = $current_site_delta + 1;
if (isset($network[$next_site_delta])) {
// Redirect to the next network site.
$redirect_destination = sso_redirect_url($network[$next_site_delta], !empty($https));
}
else {
// We are at the last network site. In these scenarios, we need to
// redirect to the destination, or to the original host in case of a logout.
if ($_GET['op'] == 'login') {
$redirect_destination = $_GET['destination'];
}
else {
$redirect_destination = ($https ? 'https://' : 'http://') . $_GET['origin_host'];
}
}
}
// Redirect the user. We need to prevent the redirect from being cached.
header('Cache-Control: max-age=0', TRUE);
header('Expires: Sun, 09 Aug 1987 22:00:00 +0100', TRUE);
header('Pragma: no-cache', TRUE);
header('Location: ' . $redirect_destination, TRUE, 302);
exit;
/**
* Validates the query parameters.
*
* Required parameters:
* - op: Tells us what the current operation is: login or logout.
* - origin_host: Indicates which site initiated the login/logout.
* Additional required parameter when the operation is "login":
* - destination: The url to redirect the user to after all redirects are done.
*/
function sso_validate_query_params() {
if (empty($_GET['op']) || empty($_GET['origin_host'])) {
return FALSE;
}
if (!in_array($_GET['op'], array('login', 'logout'))) {
return FALSE;
}
if ($_GET['op'] == 'login' && !isset($_GET['destination'])) {
return FALSE;
}
return TRUE;
}
/**
* Creates a cookie signaling the required operation.
*
* Removes any conflicting cookies.
*
* @param $operation
* The operation to signal, login or logout.
*/
function sso_create_cookie($operation) {
if ($operation == 'login') {
$remove = 'Drupal.visitor.SSOLogout';
$create = 'Drupal.visitor.SSOLogin';
}
else {
$remove = 'Drupal.visitor.SSOLogin';
$create = 'Drupal.visitor.SSOLogout';
}
$secure = !empty($GLOBALS['https']);
$domain = ltrim(strtolower($_SERVER['HTTP_HOST']), 'a.');
if (!empty($GLOBALS['cookie_name_strict'])) {
$remove .= '_' . $domain;
$create .= '_' . $domain;
}
setcookie($remove, '', time() - 3600, '/', $domain, $secure);
// The expiration should be less than the Drupal session duration.
// The most common Drupal `session.gc_maxlifetime` value is 200000 seconds,
// so we define the expiration to half a minute before that, accordingly.
setcookie($create, 1, time() + 200000 - 30, '/', $domain, $secure);
}
/**
* Returns an URL to which redirection can be issued.
*
* @param string $host
* @param bool $https
* @return string
*/
function sso_redirect_url($host, $https) {
if (!strpos($host, '//')) {
$host = ($https ? 'https://' : 'http://') . $host;
}
$args = array(
'op' => $_GET['op'],
'origin_host' => $_GET['origin_host'],
);
if ($_GET['op'] == 'login') {
$args['destination'] = $_GET['destination'];
}
return $host . '/?' . http_build_query($args);
}

Télécharger

Monitoring de l'état de l'authentification et SLO

DnC — 2020-09-07T11:00:00Z

Le monitoring de l'état de l'authentification a pour but de synchroniser la connexion locale d'une application avec le jeton d'accès correspondant.

OAuthSD, suivant en cela OAuth 2.0, considère que l'utilisateur final est connecté à une application tant que le jeton d'accès associé est valide.

Il n'y a pas "naturellement" de relation directe entre ce jeton et l'état de connexion local d'une application. Chaque application devra donc mettre en place un monitoring, côté client, dans le but de :
surveiller la validité du jeton d'accès,
réaliser la ré-authentification silencieuse et la connexion automatique,
compléter le mécanisme de déconnexion unique (Single Logout, SLO) en provoquant la déconnexion locale de l'application lorsque le jeton d'accès a expiré.

Plusieurs solutions se présentent pour assurer le suivi de la session OIDC :

1. La communauté se voit proposer une "norme" de gestion de la session OpenID Connect (voir : OpenID Connect Session Management ) qui s'appuie sur des iframes du côté du serveur et du côté de l'application.

Dans sa version 30 publiée en août 2020, le paragraphe 5, encore présent dans la version 28, intitulé "Back-Channel Logout", disparait.
En effet, une nouvelle proposition "OpenID Connect Back-Channel Logout" évite les dysfonctionnements prévus au paragraphe "User Agents Blocking Access to Third-Party Content" :

Notez qu'au moment de la rédaction de cet article, certains agents utilisateurs (navigateurs) commencent à bloquer l'accès au contenu tiers par défaut pour bloquer certains mécanismes utilisés pour suivre l'activité de l'utilisateur final sur les sites. Plus précisément, le contenu tiers bloqué est un contenu de site Web avec une origine différente de l'origine de la fenêtre de l'agent utilisateur ciblée. Les données du site incluent les cookies et toutes les API de stockage Web (sessionStorage, localStorage, etc.).

Cela peut empêcher la capacité des notifications de l'OP au niveau du RP d'accéder à l'état de l'agent utilisateur du RP pour mettre en œuvre des actions de déconnexion locale. En particulier, les cookies et les API de stockage Web peuvent ne pas être disponibles dans le cadre OP chargé dans le contexte RP. L'effet secondaire ici est que, selon le mécanisme utilisé (cookies ou stockage Web), les données nécessaires pour recalculer session_state peuvent ne pas être disponibles. Les implémentations basées sur les cookies peuvent alors renvoyer des modifications pour chaque appel, ce qui entraîne des boucles infinies de ré-authentifications. Par conséquent, les déploiements de cette spécification sont recommandés pour inclure un code défensif pour détecter cette situation et, si possible, informer l'utilisateur final que les déconnexions RP demandées n'ont pas pu être effectuées. Les détails du code défensif nécessaire dépassent le cadre de cette spécification ; il peut varier selon l'agent utilisateur et peut varier dans le temps, car la situation de prévention du suivi de l'agent utilisateur est fluide et continue d'évoluer. ".

Une proposition de spécification qui a connu 30 modifications mais qui n'évolue plus depuis août 2020, et qui de plus se termine sur un constat de dysfonctionnement, est morte !

De plus, il ne s'agit là que d'un procédé de communication entre une application et le serveur OIDC, communication qui peut être réalisée par d'autres moyens, et notamment par interrogation régulière du contrôleur Authorize avec prompt = 'none'. Nous pensons (peut-être à tort ?) qu'une "norme" concernant une couche ISO de niveau protocole ne doit pas introduire à ce niveau un procédé de communication particulier.

2. Notre solution est présentée ici : Implémentation du monitoring avec Javascript : exemples pour SPIP et WordPress interroge donc le contrôleur Authorise avec le paramètre display='none'.
Une implémentation côté client s'appuyant sur la norme OpenID Connect telle qu'elle existe actuellement est bien préférable à une nouvelle complication des applications clientes et permet d'éviter la violation du principe d'indépendance des couches ISO.

OpenID Connect Session Management

DnC — 2020-08-12T15:49:00Z

Nota : il s'agit d'une version périmée mais des serveurs sont fondés dessus (Publik par exemple).
Cette proposition de spécification répond au besoin de connaître l'état réel de connexion de l'utilisateur et de gérer la déconnexion unique.
Dans l'état actuel, ce document présente de multiples défauts. DnC suit l'évolution de cette spécification et OAuthSD devra intégrer les spécifications qui seront finalement approuvées.

Sans attendre, le serveur OAuthSD répond aux fonctionnalités évoquées avec la technique de la connexion unique et de la déconnexion unique qui en découle ainsi que le monitoring.

Traduction du document OpenID Connect Session Management 1.0 - draft 28

...

Cette spécification définit le terme suivant :

Session

Période continue pendant laquelle un utilisateur final accède à un RP (Relying Party) en s'appuyant sur l'authentification de l'utilisateur final effectuée par le fournisseur OpenID.

2. Découverte du point de terminaison

Pour prendre en charge la gestion de session OpenID Connect, le RP doit obtenir les URL de point de terminaison associées à la gestion de session. Ces URL sont normalement obtenues via la réponse à la découverte de l'OP, comme décrit dans OpenID Connect Discovery 1.0 [OpenID.Discovery], ou PEUVENT être apprises via d'autres mécanismes.

2.1. Métadonnées de découverte du fournisseur OpenID

Ces paramètres de métadonnées de fournisseur OpenID DOIVENT être inclus dans les réponses de découverte du serveur lorsque la gestion de session et la découverte sont prises en charge :

check_session_iframe

CHAMPS OBLIGATOIRES. URL d'un iframe de l'OP qui prend en charge les communications entre origines croisées pour les informations d'état de session avec le client RP, à l'aide de l'API postMessage de HTML5. La page est chargée à partir d'un iframe invisible incorporé dans une page du RP afin de pouvoir s'exécuter dans le contexte de sécurité de l'OP. Il accepte les requêtes postMessage en provenance de l'iframe du RP concerné et utilise postMessage pour renvoyer le statut de connexion de l'utilisateur final vers l'OP.

end_session_endpoint

CHAMPS OBLIGATOIRES. URL de l'OP sur laquelle un RP peut effectuer une redirection pour demander à l'utilisateur final d'être déconnecté de l'OP.

3. Création et mise à jour de sessions

Dans OpenID Connect, la session du RP commence généralement lorsque le RP valide le jeton d'identification de l'utilisateur final. Reportez-vous à la spécification OpenID Connect Core 1.0 [OpenID.Core] pour savoir comment obtenir un jeton ID et le valider. Lorsque l'OP prend en charge la gestion de session, il DOIT également renvoyer l'état de session en tant que paramètre supplémentaire session_state dans la réponse d'authentification. La réponse d'authentification OpenID Connect est spécifiée dans la Section 3.1.2.5 d'OpenID Connect Core 1.0.

Ce paramètre est :

session_state
Etat de session. Chaîne JSON [RFC7159] représentant l'état de connexion de l'utilisateur final sur l'OP. Il NE DOIT PAS contenir le caractère espace (""). Cette valeur est opaque pour le RP. Ceci est OBLIGATOIRE si la gestion de session est prise en charge.

La valeur de l'état de session est initialement calculée sur le serveur. La même valeur d'état de session est également recalculée par l'iframe dans le navigateur du client. La génération de valeurs appropriées pour l'état de session est spécifiée dans la section 4.2 et est basée sur un hachage cryptographique salé de l'ID client, de l'URL d'origine et de l'état du navigateur OP. Pour l'URL d'origine, le serveur peut utiliser l'URL d'origine de la réponse d'authentification, conformément à l'algorithme spécifié à la section 4 de la RFC 6454 [RFC6454].

4. Notification de changement d'état de session

Un jeton d'identité vient généralement avec une date d'expiration. Le RP PEUT s'y fier pour expirer la session du RP. Cependant, il est tout à fait possible que l'utilisateur final se soit déconnecté de l'OP avant la date d'expiration. Par conséquent, il est hautement souhaitable de pouvoir connaître le statut de connexion de l'utilisateur final à l'OP.

Pour ce faire, il est possible de répéter la demande d'authentification avec prompt = none [1]. Cependant, cela entraîne un trafic réseau, ce qui est problématique sur les appareils mobiles qui deviennent de plus en plus populaires. Par conséquent, une fois que la session est établie avec la demande d'authentification et la réponse, il est souhaitable de pouvoir vérifier l'état de la connexion sur l'opérateur sans générer de trafic sur le réseau en interrogeant un OP iframe caché à partir d'un RP iframe avec un postMessage à origine restreinte, comme suit.

4.1. RP iframe

Le RP charge un iframe invisible à partir de lui-même. Cette iframe DOIT connaître l'ID de l'OP iframe, comme décrit à la section 4.2, afin de pouvoir envoyer un message à l'OP iframe. L'iframe RP interroge l'OP iframe avec postMessage à un intervalle approprié [2] pour l'application RP. Avec chaque postMessage, il envoie l'état de session défini dans la section 4.2.

Le postMessage de l'iframe RP fournit la concaténation suivante en tant que données :

ID client + " " + état de session

Il doit également pouvoir recevoir le postMessage de l'OP iframe. Les données reçues seront soit 'changed', soit 'unchanged', sauf si la syntaxe du message envoyé est déterminée par le terminal opérateur comme étant malformée, auquel cas les données reçues seront erronées. Dès réception de la modification, le RP DOIT effectuer une nouvelle authentification avec prompt = none pour obtenir l'état de la session en cours sur le terminal opérateur. À la réception d'une erreur, le RP NE DOIT PAS effectuer de nouvelle authentification avec prompt = none, afin de ne pas causer de boucles infinies potentielles générant un trafic réseau vers le terminal opérateur.

Voici un exemple de pseudo-code non normatif pour l'iframe RP :

Javascript

var stat = "unchanged";

var mes = client_id + " " + session_state;

function check_session()

{

var targetOrigin = "https://server.example.com";

var win = window.parent.document.getElementById("op").

contentWindow;

win.postMessage( mes, targetOrigin);

}

function setTimer()

{

check_session();

timerID = setInterval("check_session()",3*1000);

}

window.addEventListener("message", receiveMessage, false);

function receiveMessage(e)

{

var targetOrigin = "https://server.example.com";

if (e.origin !== targetOrigin ) {return;}

stat = e.data;

if stat == "changed" then take the actions below...

}

Télécharger
4.2. OP iframe

Le RP charge également un OP iframe invisible à partir de check_session_iframe de l'OP. Le RP DOIT assigner un attribut id à l'iframe afin qu'il puisse l'adresser, comme décrit ci-dessus. L'OP iframe DOIT imposer que l'appelant ait la même origine que son cadre parent. Il DOIT rejeter les demandes postMessage de toute autre source.

Comme spécifié dans la section 4.1, le postMessage de l'iframe RP fournit la concaténation suivante en tant que données :

ID client + " " + session_state

L'op iframe a accès à l'état du navigateur dans l'OP (dans un cookie ou dans un stockage HTML5) qu'il utilise pour calculer et comparer l'état de session OP passé par le RP. L'OP iframe DOIT le recalculer à partir de l'ID client précédemment obtenu, de l'URL d'origine de la source (à partir de postMessage) et de l'état actuel du navigateur OP. L'état de session inclut toutes ces informations pour des raisons de confidentialité, de sorte que différents clients actifs dans le même navigateur ont des valeurs d'état de session distinctes.

Si le postMessage reçu est syntaxiquement incorrect, de sorte que l'ID client publié et l'URL d'origine ne peuvent pas être déterminés ou sont incorrects sur le plan syntaxique, l'OP iframe DOIT poster (postMessage) à la source la chaîne d'erreur. Si la valeur reçue et la valeur calculée ne correspondent pas, l'OP iframe DOIT poster à la source la chaîne modifiée. S'il y a correspondance, alors il DOIT poster la chaîne inchangée.

Voici un exemple non normatif de pseudo-code pour l'OP iframe :

Javascript

window.addEventListener("message", receiveMessage, false);

function receiveMessage(e){ // e.data has client_id and session_state

// Validate message origin

var client_id = e.data.split(' ')[0];

var session_state = e.data.split(' ')[1];

var salt = session_state.split('.')[1];

// if message syntactically invalid

// postMessage('error', e.origin) and return

// get_op_browser_state() is an OP defined function

// that returns the browser's login status at the OP.

// How it is done is entirely up to the OP.

var opbs = get_op_browser_state();

// Here, the session_state is calculated in this particular way,

// but it is entirely up to the OP how to do it under the

// requirements defined in this specification.

var ss = CryptoJS.SHA256(client_id + ' ' + e.origin + ' ' +

opbs + ' ' + salt) + "." + salt;

var stat = '';

if (session_state == ss) {

stat = 'unchanged';

} else {

stat = 'changed';

}

e.source.postMessage(stat, e.origin);

};

Télécharger

L'état du navigateur OP sera généralement stocké dans un cookie ou dans un stockage local HTML5. Il a pour origine le serveur d'autorisations. Il capture des événements significatifs tels que les connexions, les déconnexions, le changement d'utilisateur, le changement de statut d'authentification pour les clients utilisés par l'utilisateur final, etc. Ainsi, l'OP DEVRAIT mettre à jour la valeur de l'état du navigateur en réponse à de tels événements significatifs. En conséquence, le prochain appel à check_session () après un tel événement renverra la valeur modifiée. Il est RECOMMANDÉ que le terminal opérateur ne mette pas à jour l'état du navigateur trop fréquemment en l'absence d'événements significatifs, afin d'éviter un trafic réseau excessif sur le client en réponse à des événements erronés.

Le calcul de l'état de session renvoyé en réponse à des demandes d'authentification infructueuses DEVRAIT, en plus de l'état du navigateur, incorporer suffisamment d'aléa sous la forme d'un sel afin d'empêcher l'identification d'un utilisateur final lors d'appels successifs au point de terminaison d'autorisation de l'OP.

Dans le cas d'un client autorisé (réponse d'authentification réussie), l'OP DEVRAIT changer la valeur de l'état de session renvoyé au client à l'occurrence de l'un des événements suivants :

L'ensemble des utilisateurs authentifiés auprès du navigateur change (connexion, déconnexion, ajout de session).

Le statut d'authentification des clients utilisés par l'utilisateur final change.

De plus, l'état du navigateur utilisé pour vérifier l'état de la session DEVRAIT changer avec de tels événements. Les appels à check_session() renverront les modifications apportées par rapport aux versions antérieures de l'état de session après de tels événements. Il est RECOMMANDÉ que l'état du navigateur NE DEVRAIT PAS varier trop souvent en l'absence de tels événements afin de minimiser le trafic sur le réseau causé par la réponse du client aux notifications modifiées.

Dans le cas d'une demande d'authentification infructueuse, la valeur de l'état de session renvoyée DEVRAIT varier avec chaque demande. Cependant, l'état de la session du navigateur n'a pas besoin de changer sauf si un événement significatif se produit. En particulier, de nombreuses valeurs d'état de session peuvent être simultanément valides, par exemple en introduisant un sel aléatoire dans les états de session émis en réponse à des demandes d'authentification infructueuses.

Si un cookie est utilisé pour conserver l'état du navigateur OP, l'indicateur HttpOnly ne peut probablement pas être défini pour ce cookie car il doit être accessible à partir de JavaScript. Par conséquent, les informations pouvant être utilisées pour identifier l'utilisateur ne doivent pas être placées dans le cookie, car elles pourraient être lues par du JavaScript non associé.

Dans certaines implémentations, les notifications modifiées ne se produiront que lorsque la session de l'utilisateur final sera modifiée, alors que dans d'autres implémentations, elles pourront également survenir à la suite de modifications apportées à d'autres sessions entre l'agent d'utilisateur et le terminal opérateur. Les PR doivent être préparés à toute éventualité, en gérant en silence tous les faux positifs susceptibles de se produire.

5. Déconnexion initiée par le RP

Un RP peut notifier à l'OP que l'utilisateur final s'est déconnecté du site et peut également vouloir se déconnecter de l'OP. Dans ce cas, le RP, après avoir déconnecté l'utilisateur final du RP, redirige l'agent utilisateur de l'utilisateur final vers l'URL du point de terminaison de déconnexion de l'OP. Cette URL est normalement obtenue via l'élément end_session_endpoint de la réponse à la découverte de l'OP ou peut être apprise via d'autres mécanismes.

Cette spécification définit également les paramètres suivants qui sont transmis en tant que paramètres de requête dans la demande de déconnexion :

id_token_hint

CONSEILLÉ [3]. Le jeton d'ID précédemment émis a été transmis au point de terminaison de la déconnexion en tant qu'indication de la session authentifiée actuelle de l'utilisateur final avec le client. Ceci est utilisé comme indication de l'identité de l'utilisateur final que le RP demande à être déconnecté par l'OP. L'OP n'a pas besoin d'être répertorié en tant que public du jeton ID lorsqu'il est utilisé en tant que valeur id_token_hint.

post_logout_redirect_uri

OPTIONNEL. URL à laquelle le RP demande que l'agent utilisateur de l'utilisateur final soit redirigé après la déconnexion. La valeur DOIT avoir déjà été enregistrée auprès de l'OP, soit à l'aide du paramètre d'enregistrement post_logout_redirect_uris, soit via un autre mécanisme. S'il est fourni, l'OP DEVRAIT honorer cette demande après la déconnexion.

state

OPTIONNEL. Valeur opaque utilisée par le RP pour maintenir l'état entre la demande de déconnexion et le rappel au noeud final spécifié par le paramètre de requête post_logout_redirect_uri. S'il est inclus dans la demande de déconnexion, l'OP retransmet cette valeur au RP en utilisant le paramètre de requête d'état lors de la redirection de l'agent d'utilisateur vers le RP.

Au point de terminaison de la déconnexion, l'OP DEVRAIT demander à l'utilisateur final s'il souhaite également se déconnecter de l'OP. Si l'utilisateur final dit "oui", alors l'OP DOIT déconnecter l'utilisateur final.

5.1. Redirection vers RP après la déconnexion

Dans certains cas, le RP demande à ce que l'agent d'utilisateur de l'utilisateur final soit redirigé vers le RP après la déconnexion. La redirection post-déconnexion n'est effectuée que lorsque la déconnexion est lancée par le RP, auquel cas la cible de la redirection est la valeur du paramètre de requête post_logout_redirect_uri utilisée par le RP initiateur ; sinon ce n'est pas fait. Cette spécification définit ce paramètre d'enregistrement dynamique à cette fin, conformément à la section 2.1 d'OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration].

5.1.1. Métadonnées d'inscription du client

Ce paramètre de métadonnées client PEUT être inclus dans les informations d'enregistrement du client lorsque la gestion de session et l'enregistrement dynamique sont pris en charge :

post_logout_redirect_uris

OPTIONNEL. Tableau d'URL fournies par le RP auquel il PEUT demander que l'agent d'utilisateur de l'utilisateur final soit redirigé à l'aide du paramètre post_logout_redirect_uri après la déconnexion [4].

6. Validation

Si l'une des procédures de validation définies dans la présente spécification échoue, les opérations nécessitant des informations qui n'ont pas été correctement validées DOIVENT être annulées et les informations qui n'ont pas été validées NE DOIVENT PAS être utilisées.

7. Considérations de mise en œuvre

Cette spécification définit les fonctionnalités utilisées par les parties utilisatrices et les fournisseurs OpenID ayant choisi d'implémenter la gestion de session. Toutes ces parties utilisatrices et fournisseurs OpenID DOIVENT implémenter les fonctions listées dans cette spécification comme étant "REQUIRED" ou décrites avec un "MUST". Aucune autre considération d'implémentation pour les implémentations de Session Management n'est définie par cette spécification.

8. Considérations de sécurité

L'OP iframe DOIT imposer que l'appelant ait la même origine que son cadre parent. Il DOIT rejeter les demandes postMessage provenant de toute autre source, afin d'empêcher les attaques de script entre sites.

Le paramètre id_token_hint associé à une demande de déconnexion peut être utilisé pour déterminer quel RP a lancé la demande de déconnexion. Les demandes de déconnexion sans valeur id_token_hint valide constituent un moyen de déni de service potentiel ; par conséquent, les opérateurs peuvent vouloir demander une confirmation explicite de l'utilisateur avant d'agir.

...

Critique raisonnée de la méthode et solution pour OAuthSD

Rappelons tout d'abord que la méthode des iframes n'est pas celle que préconise OAuthSD, voyez : Monitoring de l'état de l'authentification et SLO et Implémentation du monitoring avec Javascript : exemples pour SPIP et WordPress. OAuthSD met en œuvre la méthode présentée précédemment à des fins d'expérimentation et de suivi de la norme OpenID Connect.

Cependant, ce document présente des erreurs de principe conduisant à des complications inutiles, résultant en une méthode de monitoring inefficace. En particulier, de très nombreux événements hors sujet nécessitent d'interroger l'OP sur la réalité de la connexion, ce qui entraîne un trafic important.

De toutes façons, les erreurs, omissions et imprécisions de ce document conduisent à un non fonctionnement du système tel que décrit.

1. Se concentrer sur notre sujet : un utilisateur et une application donnée

"L'état du navigateur ... capture des événements significatifs tels que les connexions, les déconnexions, le changement d'utilisateur, le changement de statut d'authentification pour les clients utilisés par l'utilisateur final, etc. Ainsi, l'OP DEVRAIT mettre à jour la valeur de l'état du navigateur en réponse à de tels événements significatifs."

Dans cette phrase, l'expression "les connexions, les déconnexions, le changement d'utilisateur, le changement de statut d'authentification pour les clients utilisés par l'utilisateur final, etc." est un galimatias redondant, encore embrouillé par "des événements tels que" (il y aurait encore d'autres événements à prendre en compte ?) et par le "etc." final. Le texte qui suit "Dans le cas d'un client autorisé (réponse d'authentification réussie), l'OP DEVRAIT changer la valeur de l'état de session renvoyé au client à l'occurrence de l'un des événements suivants : - L'ensemble des utilisateurs authentifiés auprès du navigateur change (connexion, déconnexion, ajout de session). - Le statut d'authentification des clients utilisés par l'utilisateur final change." n'est qu'une redite du précédent. Passons sur le fait que l'authentification n'est pas relative au client mais à l'utilisateur final : on n'est pas à une approximation près.

"De plus, l'état du navigateur utilisé pour vérifier l'état de la session DEVRAIT changer avec de tels événements."

"Il est RECOMMANDÉ que l'état du navigateur NE DEVRAIT PAS varier trop souvent en l'absence de tels événements afin de minimiser le trafic sur le réseau causé par la réponse du client aux modifications notifiées". C'est une absurdité : s'il n'y a pas d'événement, il n'y a pas de notification de changement.

Il apparaît que les changements d'états relatifs à toutes les applications et tous les utilisateurs donnent lieu à notification d'un changement d'état.

La seule chose qui nous intéresse est de savoir si l'utilisateur de l'application ouverte sur le navigateur considéré est connecté ou non.

2. Obtenir directement l'état de connexion, et non l'indication d'un changement

"Les appels à check_session() renverront les modifications apportées par rapport aux versions antérieures de l'état de session après de tels événements.

Dès réception de la modification, le RP DOIT effectuer une nouvelle authentification avec prompt = none pour obtenir l'état de la session en cours sur le terminal opérateur..

L'idée est de notifier un changement d'état, et de réinterroger le serveur pour savoir si l'utilisateur est toujours vu connecté.

Solution OAuthSD : L'état de connexion est relatif à une application et à un utilisateur. Il est traduit par la validité du jeton d'accès.

[1] Cette solution a notre préférence, voir la note suivante.

[2] Il est donc inexact d'affirmer, comme indiqué au paragraphe précédent, que la connaissance de l'état de session peut être effectué "sans générer de trafic sur le réseau". Pour réduire le trafic, il conviendra d'augmenter l'intervalle d'interrogation de l'OP. Chez DnC, nous préférons tester la connexion avec prompt = none, le serveur OAuthSD étant optimisé pour répondre très rapidement à une requête de type XMLHttpRequest.

[3] Obligatoire pour OAuthSD

[4] Nous considérons cette fonctionnalité comme très dangereuse, car elle permet à un malware de rediriger l'utilisateur final sur une page étrangère à l'application initiale, favorisant ainsi le physing.