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

Q : le flux d'autorisation est-il aussi bon pour le natif/mobile ?

DnC — 2024-03-14T09:55:29Z

Bénéficiant des travaux de Bertrand Degoy, i-Tego maîtrise l'IA générative à partir des données de votre entreprise. Nous pouvons ainsi vous fournir des outils de recherche avancés sur un très grand nombre de documents de tout type, explorer vos bases de données, vos e-mails etc. Le tout avec une traduction automatique !


i-Tego chat bot: i-Tego offers businesses a chatbot whose document database includes their own data : https://chat.i-tego.com/

Voici l'exemple d'un chat exploitant la documentation d'i-Tego :

Q:le flux d'autorisation est-il aussi bon pour les applications natives/mobiles que pour les applications Web ?

R : Le flux d'autorisation est généralement considéré comme plus adapté pour les applications Web que pour les applications natives ou mobiles. En effet, les applications Web sont plus faciles à sécuriser car elles fonctionnent dans un environnement contrôlé et dépendent d'une connexion permanente au serveur, ce qui facilite l'utilisation du flux "Authorization Code" pour protéger les données.

En revanche, les applications natives ou mobiles peuvent rencontrer des difficultés avec le flux d'autorisation, notamment en ce qui concerne l'authentification de l'application elle-même. Les méthodes de sécurité telles que le "Proof Key for Code Exchange" ou le "Proof of Possession" peuvent renforcer la sécurité des jetons émis, mais ne permettent pas toujours d'authentifier pleinement une application sans back-end.

Il est donc recommandé d'utiliser le flux de code d'autorisation pour les applications natives ou mobiles, mais il est important de prendre en compte les spécificités de ces types d'applications en matière de sécurité.

Sources :

Document "Authentifier l'application - OpenID Connect OAuth Server dédié" (pages 8, 9, 14, 15)"

Il est important de noter que la question à une réponse libellée en français est fondée sur des documents différents que celle répondant à une question libellée en anglais. En effet, la base documentaire fournie par i-Tego au chatbot est principalement en langue française. Dans le choix des sources, la priorité est donnée à la langue de la question.

L'authentification dans le cadre de l'IIoT

DnC — 2022-10-23T10:00:38Z

Assurer la sécurité de la transmission des données entre les applications et les objets connectés de l'Industrie du Futur :
Outre la sécurisation des données en provenance des capteurs, l'étude et le démonstrateur du projet "AuthSec" seront particulièrement orientés vers la sécurité des ordres passés aux actionneurs en vue d'éviter les dysfonctionnements et les accidents.
Deux techniques seront combinées : l'authentification de bout en bout, au niveau applicatif, pour compléter la sécurité du niveau réseau ; des algorithmes basés sur l'apprentissage profond pour détecter et bloquer les commandes à risque.
Cette démarche s'inscrit dans une réflexion sur les conditions de la Cyber-résilience de l'Usine du Futur.

Le contexte dans lequel se conçoit la sécurité de l'Usine du Futur

Une ouverture encore mal maîtrisée

S'agissant de la sécurité des applications informatiques des entreprises le modèle initial consistait (et consiste toujours pour beaucoup) à sanctuariser les données et les traitements dans un réseau local isolé des services extérieurs et auquel seuls les utilisateurs du site pouvaient accéder. Ce modèle radicalement efficace est devenu inapplicable compte tenu de l'intérêt que pourraient présenter certains services externes pour une application particulière et de la nécessité d'ouvrir l'accès au réseau à des utilisateurs extérieurs : collaborateurs, clients, usagers. Il paraît inutile de justifier plus avant ce qui est maintenant une évidence.
S'agissant des collaborateurs hors site, une première ouverture a consisté à permettre l'accès à des utilisateurs ou des applications depuis le réseau Internet à l'aide de pare-feu, de tunnels ou d'une console distante, l'accès étant contrôlé en une seule fois à l'entrée. Le collaborateur distant se trouve alors dans la même situation que s'il se trouvait sur le site de l'entreprise. Bien que ce modèle périmétrique soit à l'origine de nombreux et graves problèmes de sécurité, sa simplicité conceptuelle, son application dès les débuts de l'informatique et sa facilité de mise en œuvre en font une solution trop largement adoptée.
Parallèlement, le besoin s'est fait sentir de mettre à la disposition du public des applications leur permettant d'interagir avec les données de l'entreprise ou de l'administration. C'est tout naturellement que les applications Web sont nées. L'utilisateur distant n'accède plus au réseau avec des outils omnipotents, mais au niveau applicatif, de son navigateur au « site web », c'est à dire à une application résidant sur un serveur. Une authentification de niveau applicatif, gérée par l'application elle même, permet de limiter son accès aux seuls traitement et données qui sont autorisés à l'utilisateur qui s'y connecte.
On aurait pensé que les applications Web auraient été développées dans le même temps pour permettre le télétravail, mais cela n'a pas été anticipé par les grandes entreprises restées positionnées sur le travail sur site, ou accoutumées aux tunnels ( établissant des réseaux virtuels privés ou virtual private network, ou tunnel VPN ) pour le travail de site à site, et qui ont naturellement adopté le modèle périmétrique pour le télétravail.
Outre les facteurs historiques et culturels, il faut reconnaître le frein que représente la nécessité de modifier les applications « natives » pour en faire des applications web capables d'authentification, avec des délais et des coûts considérés comme improductifs. Face à l'urgence d'organiser le télétravail, un marketing opportuniste a fait admettre le tunnel VPN comme la panacée, alors que cela consiste à étendre le réseau de l'entreprise aux réseau locaux des box familiales au domicile des employés, avec les risques que l'on imagine - eh bien non, justement, on ne l'imagine pas. Alors que la sécurité des tunnels de site à site avait soigneusement été établie, la précipitation et les mauvaises pratiques prévalent dans le cadre du télétravail.

La tentation du Cloud

Une certaine image de l'Usine du Futur est aujourd'hui déterminée par des facteurs qui lui sont largement étrangers :
la domination du marché grand public sur le marché professionnel, imposant ses produits et ses schémas mentaux ainsi que ses méthodes de marketing,
le besoin de connexion à distance pour le télétravail, malheureusement fondé sur des réseaux conçus pour le grand public et des équipements domestiques,
le désir de mobilité, recherche quasi ludique d'une facilité de connexion permanente, sans distinction de moyens, de techniques ou de comportement entre l'espace professionnel et la vie extérieure,
l'approche commerciale des entreprise de services du numérique qui, à la suite des GAFAMs ayant largement promu la technique d'externalisation des services dans le Cloud, proposent de plus en plus des plateformes en tant que service (PaaS) qui leur sont particulièrement avantageuses, en évitant de trop mentionner ni traiter les problèmes de sécurité que cela implique.

A ces facteurs extérieurs, on pourrait ajouter deux tendances bien ancrées dans l'esprit de certains dirigeants et qui devraient pourtant appartenir au passé :
l'externalisation de fonctions relevant de compétences considérées comme inaccessibles ou rangées par principe hors du « cœur de métier »,
l'incompréhension des techniques de sécurité, la confiance excessive, la négligence au nom de la rapidité de développement et de la productivité, ou encore le classement des investissements de sécurité dans les charges improductives,
la crainte de se voir reprocher des choix technologiques hasardeux plutôt que le maintien de techniques dont la fiabilité serait justifiée par leur ancienneté et leur large adoption,
le sentiment de propriété des ITs sur la sécurité, qui - de leur point de vue - devrait être de leur seule compétence et donc appliquée exclusivement au niveau réseau, faussement en concurrence avec une sécurité au niveau applicatif présentée comme alternative et non comme complémentaire.

Ainsi, il est donné aux public et aux chefs d'entreprise une vision de l'Usine du Futur dans laquelle tout est connecté à tout, sur le modèle applicable au grand public.
L'une des implications les plus lourdes pour la sécurité des réseaux est la multiplication des connexions extérieures non seulement à la périphérie des réseaux, mais encore dans leur profondeur.
Or, un grand désordre existe dans la sécurité des réseaux, à l'origine de nombreux accidents de sécurité ou de sûreté de fonctionnement. Pour l'Usine du Futur, de tels accidents sont inacceptables car ils pourront se traduire en perte de propriété industrielle et en arrêt de production.

Le modèle « Jéricho »

Depuis longtemps déjà les entreprises ont ouvert l'accès à leur réseau en contrôlant l'accès à leur périmétrie. Cependant, de multiples attaques aux conséquences graves ont démontré la faillite du modèle périmétrique.
Ce constat a été fait il y a de nombreuses années déjà. En 2004, le Jericho Forum introduisait le concept de dépérimétrisation, une stratégie de défense qui consiste en un système de sécurité segmenté et multicouche basé sur le chiffrement et l'authentification, incluant les ressources hors site. Plus proche de nous, le concept de « zéro confiance à l'accès réseau » ( Zero Trust Network Access, ZTNA ) en reprend quelques principes, sous une forme plus médiatique, mettant l'accent sur l'authentification.
Selon le modèle « Jéricho », la sécurité est appliquée là où se trouvent les données et les traitements à protéger, c'est à dire au niveau applicatif de chaque service ( applications, services Web, machines, objets connectés etc. ). C'est bien ce qu'applique l'OTAN avec le principe de protection "Data-centric Security (DCS) :" rather than focusing on network perimeter defence focuses on securing access to the data itself. [1]".

Il ne faut pas concevoir l'authentification au niveau applicatif comme un moyen de suppléer à une mauvaise sécurité du réseau. Assurer la sécurité à travers les applications web exige que l'on ne puisse pas accéder directement aux données au niveau réseau. Le principe sera d'isoler les services dans un périmètre réduit ( résultant de la segmentation multicouche ), bien sécurisé au niveau réseau et accessibles seulement au niveau applicatif avec authentification. En particulier, cela exige de ne pas permettre l'accès direct au gestionnaire de données, ce qui implique que toute opération administrative devrait être effectuée à partir d'une connexion locale. L'idéal serait de n'ouvrir au niveau réseau que les ports strictement nécessaires aux protocoles de la couche ISO n° 5, à la limite seulement 443 pour HTTP et MQTT sécurisés par TLS.

L'Usine du Futur sera sécurisée ou ne sera pas

Mais de quoi parle-t-on ? L'usine du Futur n'existe-t-elle pas déjà ? Les chaînes de construction automobile ne sont-elles pas déjà totalement informatisées et robotisées ? Le système CATIA ne permet-il pas de concevoir, développer et réaliser de nouveaux produits, son succès mondial témoignant de sa sécurité ? A l'évidence les grandes entreprises ont maîtrisé le sujet. Il est certain qu'elles ne sont pas sensibles à l'image médiatique, ayant les moyens d'étude nécessaires à la conduite de leur évolution.
Ce sont les TPE/PME qui se trouvent à la merci du tapage médiatique – y compris sur les revues « professionnelles » - et la cible de démarches commerciales mal adaptées. Ce sont elles qui doivent être accompagnées au cours de leur création ou de leur transformation.

Sûreté de fonctionnement, Contrôle des accès et Sécurité des données

Si on se réfère aux offres d'un marketing dominant, il faut s'en remettre à l'Internet pour délocaliser les données et les traitements dans le Cloud. Les données font alors le tour du monde : où et par qui sont-elles traitées, et par quelles applications ? Où sont-elles sauvegardées ? Comment sont-elles protégées ?
Avant de répondre à ces questions, il faut définir la notion de Cloud .

Cloud ou Cloud privé ?

Il convient tout d'abord de distinguer :
La définition initiale du Cloud qui est née de la virtualisation des traitements et du stockage des données chez les grands hébergeurs, permettant de mettre à disposition des abonnés des ressources virtuelles. Dans cette configuration, il s'agit de "Cloud privé" dont l'accès et la configuration sont sous le contrôle de l'entreprise ( ou a minima d'un sous-traitant de confiance ). Des offres telles que IBM Cloud, Amazone AWS ou OVH Private Cloud offrent les garanties de propriété attendues par les entreprises.
Une externalisation générale des traitements et des données confiés à des sous-traitants extérieurs à l'entreprise, qui eux-mêmes peuvent faire appel à d'autres intervenants sans que ce soit identifiable et contrôlable par l'entreprise, ni même stable dans le temps. Parmi ces offres, il existe des services de données ou de traitement sans doute très commodes, mais dont la qualité et la pérennité est incontrôlable. L'opacité de cette configuration a conduit au terme de nuage, qui par un effet de sablier a été érigé au niveau d'un principe largement véhiculé par les médias.

Un enjeu de sécurité

Avec des données et des traitements distribués dans un tel Cloud, tous les enjeux de sécurité se situent hors de la portée de l'entreprise :
• Sécurité des accès : l'authentification des utilisateurs et des applications est déléguée hors du contrôle de l'entreprise.
• Sécurité des données des utilisateurs du public : peut-on réellement appliquer le RGPD ?
• Sécurité des données de l'entreprise non garantie, exposant à l'espionnage industriel et à la contrefaçon.
• Sauvegarde des données de l'entreprise : il lui est impossible de s'en assurer, au risque d'une perte totale.
De plus dans une telle configuration, la surface d'attaque est indéfinie et probablement immense.

Un enjeu de sûreté, de rapidité et de continuité de fonctionnement

• Sûreté de fonctionnement : trop de composants hors du champ d'action de l'entreprise, totalement contraire à toute démarche de qualité.
• Rapidité : les processus industriels sont quasi temps réel. Des interruptions de service de quelques secondes, ou des temps de réponse présentant de temps en temps des valeurs inacceptables, peuvent déstabiliser une chaîne de production, voire provoquer son arrêt.
• Continuité : la disponibilité des réseaux est également en question, en commençant par le raccordement de l'entreprise au réseau. Certes, le maillage de l'Internet assure la sûreté du transport à longue distance, mais le même problème de disponibilité se retrouve du côté des fournisseurs, à moins qu'il s'agisse de grands hébergeurs.

Pas totalement convaincu ? Voyez : David Heinemmeier Hansson : « Why we are leaving the cloud ».

"On premise" ou cloud privé ?

L'analyse ci-dessus conduit à :
ne pas tout mettre dans un Cloud mal défini et hors contrôle, mais s'en tenir aux Cloud privés des grands hébergeurs, voire à un datacenter de proximité ( ou Cloud de proximité ).
envisager la technique du "serveur edge" pour réduire la surface d'attaque, réduire le temps de réponse, contribuer à la résilience et conforter la souveraineté.
identifier les tâches sensibles aux délais de transmission ou d'interruption de service (voire aux attaques de déni de service) et les assurer localement (résilience),
veiller à confier les tâches sensibles à des sous-traitants proches.

Une approche radicale de la résilience conduirait à distinguer un ensemble indépendant de machines, d'applications de contrôle et de gestion quotidienne de la production capable d'assurer la production sans connexion extérieure.

Quel choix pour un serveur d'authentification ?

Le principe de l'authentification avec OpenID Connect est que les applications délèguent le processus au serveur, le dialogue d'identification étant effectué directement entre l'utilisateur et le serveur, sans intervention de l'application. Il en résulte que toutes les données relatives à l'authentification des applications et des utilisateurs, leurs données personnelles et les données cryptographiques sont situées sur le serveur.

De plus, les échanges entre les différents pôles pour l'authentification se produisent très fréquemment au rythme des échanges de données et doivent être extrêmement rapides. Quelques dizaines de millisecondes est l'ordre de grandeur visé. Le serveur est le coopérant obligé de toute transaction sécurisée. Il doit donc être parfaitement disponible.

Enfin, la plus dangereuse des attaques serait le détournement du trafic vers un serveur pirate. Pour se prémunir contre tout détournement d'adresse Internet (IP) il convient de situer le serveur d'authentification dans un "système autonome" cohérent avec le réseau de l'entreprise. Une solution radicale serait de placer le serveur dans le réseau de l'entreprise. Sinon, il convient de choisir un ensemble de réseaux gérés par une même entité (fournisseur de service, hébergeurs, intermédiaires techniques, etc.).

La sécurité et la sûreté imposent donc de situer le serveur d'authentification "à proximité" du réseau de l'entreprise.

[1] Konrad Wrona "Towards Data-centric Security for NATO Operations" DIGILIENCE 2020

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 ?

i-Tego vous offre plusieurs centaines de pages...

DnC — 2021-08-04T15:35:17Z

En relation avec i-Tego, nous vous offrons plusieurs centaines de pages de documentation et de code sur l'authentification avec OpenID Connect et ses applications.

Vous êtes ici au niveau le plus détaillé.

Les documents sont distribués sur trois niveaux :

Le site i-Tego.com présente rapidement les concepts généraux et fournit des entrées vers les points essentiels de la documentation.
i-Tego SAS : la documentation offre un premier niveau de détail déjà très suffisant pour une bonne connaissance d'OpenID Connect et des opportunités de travail avec l'équipe i-Tego. De nombreux liens en font un guide pour aborder le niveau de détail suivant.

Peut-être pourriez-vous commencer ici ?

.
le présent site OpenID Connect OAuth Serveur Dédié s'adresse aux développeurs. Avec quelques centaines de pages (dont du code), le site leur permettra d'acquérir une connaissance approfondie d'OpenID Connect et du serveur OAuthSD développé par DnC.

En savoir plus sur l'accompagnement proposé par i-Tego : authentification des utilisateurs et des applications avec OpenID Connect.

SaaS et OIDC : un mariage réussi grâce à OAuthSD !

DnC — 2021-07-29T16:44:00Z

Une des fonctionnalités que DnC a développées au plus haut niveau avec son serveur Open ID Connect (OIDC) consiste à transmettre des informations sécurisées au moyen du jeton d'identité JWT signé (JWS).

Nous décrivons dans cet article l'application i-Tego SaaS, un système de diffusion de logiciel en tant que service (Software as Service, SaaS). Dans cette application, OAuthSD fournit l'authentification OIDC et transmet de façon sécurisée aux applications SaaS les paramètres relatifs aux abonnements des souscripteurs.

Position du problème

La plupart des système SaaS intègrent l'application et le système de vente dans un même logiciel.

Si différentes applications web doivent être diffusées en mode SaaS par une même entité, le premier problème à résoudre consiste à assurer le service de connexion unique (SSO) entre le système de vente et les différentes applications, sans oublier les sites support tels que la plateforme CRM et les sites de communauté. Pas de problème, c'est le rôle d'un serveur OIDC, OAuthSD fait cela très bien.

Le deuxième problème, plus intéressant, consiste à transmettre des informations du système de vente vers les applications.
S'agissant de la validité de l'abonnement et des options (payantes), il faut sécuriser ces données, c'est à dire permettre à l'application destinataire de contrôler :
l'intégrité (les données n'ont pas été falsifiées),
l'authenticité de leur origine (elles ont bien été délivrées par le système SaaS),
l'actualité (ce sont bien des données valides à l'instant considéré),
la destination (ce sont bien des données relatives à cette application),
et bien sûr l'identité de l'utilisateur final (ce n'est pas un intrus qui utilise l'application).

La solution : OAuthSD

OAuthSD permet d'intégrer les données SaaS sous forme de déclarations supplémentaires dans la charge utile du jeton JWT. Il suffira à l'application destinataire (cliente du serveur OIDC) de valider le jeton d'identité par introspection (et non localement afin d'assurer l'actualité) pour réaliser en une seule opération les contrôles décrits ci-dessus.

Le système i-Tego SaaS et l'une de ses applications NSS Lite illustrent parfaitement cette technique.

Pour réaliser cela, nous avons :
intégré dans une même application le serveur OIDC et le système de vente,
développé des plugin d'extension OIDC-SaaS notamment pour des applications fondées sur SPIP ou Wordpress .

Le flux des échanges est le suivant :
1 : l'utilisateur s'inscrit sur le système SaaS et souscrit un abonnement.
2 : Il se connecte depuis une application cliente du système SaaS.
3 : Le serveur d'authentification adresse à l'application cliente un jeton JWT signé dont la charge utile a été complétée avec :
les données relatives à l'abonnement, en particulier sa date de fin,
les droits de l'utilisateur sur l'application,
les options souscrites.

Rappelons que, selon le protocole OpenID Connect :
le jeton adresse également les portées de l'autorisation (claims) donnant les droits de l'application sur les données de l'utilisateur.
le serveur d'authentification agit comme un service d'inscription et de connection unique (Single Sign On, SSO) . Ainsi, l'utilisateur connecté à une application cliente SaaS est également connecté aux autres applications pour lesquelles il a souscrit un abonnement

Notre offre de services

Nous serions heureux de pouvoir assister les PME pour leur permettre de développer leur propre système de SaaS et d'adapter leurs applications web.
Notre positionnement de conseil et d'assistance permettrait un développement indépendant de prestataires extérieurs coûteux. Et de systèmes tiers hasardeux en termes de sécurité : pourquoi nourrir le big-data au profit de vos concurrents ?

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