Table of Contents

Pourquoi l'authentification et l'autorisation comptent dans les architectures sans serveur

L'informatique sans serveur a transformé la façon dont les équipes construisent et déploient des applications en abstractionnant la gestion de l'infrastructure, en réduisant les frais généraux opérationnels et en permettant une mise à l'échelle automatique. Cependant, la nature éphémère et événementielle des fonctions sans serveur pose des défis de sécurité uniques. Sans un serveur persistant pour maintenir l'état de session, chaque invocation de fonction doit vérifier indépendamment qui est l'appelant et s'il est autorisé à effectuer l'action demandée.

Contrairement aux applications monolithiques où la logique d'authentification peut vivre à l'intérieur d'un serveur central, les applications sans serveur distribuent l'authentification sur les passerelles API, les services d'identité et les fonctions individuelles. Cette distribution exige une stratégie claire qui équilibre la sécurité, les performances et l'expérience du développeur.

Authentification vs autorisation: une distinction claire

Bien que souvent utilisés de façon interchangeable, l'authentification et l'autorisation servent à des fins distinctes. L'authentification répond à la question - -Qui êtes-vous? - typiquement en validant des identifiants tels qu'un nom d'utilisateur et un mot de passe, un code unique ou un facteur biométrique.

Dans les environnements sans serveur, l'authentification se fait fréquemment à la passerelle de l'API ou par l'intermédiaire d'un fournisseur d'identité dédié (IdP) avant qu'une fonction ne soit déclenchée. L'autorisation peut être gérée au niveau de la passerelle par l'intermédiaire de documents de politique, dans la fonction par le biais d'un code qui inspecte les revendications dans un JSON Web Token (JWT), ou par une combinaison des deux.

Stratégies d'authentification pour les applications sans serveur

L'authentification sans serveur se divise en trois catégories : services tiers entièrement gérés, authentification personnalisée dans les fonctions et identité fédérée à l'aide de OAuth2/OpenID Connect. Chaque approche offre des compromis entre facilité d'implémentation, contrôle et coût.

Fournisseurs d'identité tiers

La plupart des applications sans serveur utilisent un IdP dédié pour gérer l'authentification. Ces services gèrent les répertoires utilisateurs, le hachage des mots de passe, la gestion de session et l'intégration avec les fournisseurs de login social.

  • Amazon Cognito — Un service entièrement géré qui s'intègre nativement à AWS API Gateway et Lambda. Cognito fournit des piscines d'utilisateurs pour l'inscription/l'inscription, des piscines d'identité pour les identifiants AWS temporaires, et prend en charge MFA, l'authentification adaptative et les workflows personnalisés via les déclencheurs Lambda. Documentation officielle
  • Auth0 — Une plateforme d'identité basée sur le cloud offrant un accès universel, des connexions sociales, un accès sans mot de passe et une personnalisation étendue. Auth0 fournit des SDK pour plusieurs langues et peut être intégrée à n'importe quelle passerelle API. documentation Auth0
  • Authentification de Firebase[ — Partie de la suite Firebase de Google, elle prend en charge les courriels/mots de passe, le téléphone et les fournisseurs sociaux populaires. Firebase Auth s'intègre en douceur aux fonctions Firebase et Cloud Run.
  • Azure Active Directory B2C — Pour les applications d'entreprise nécessitant une intégration Azure AD, B2C fournit une gestion d'identité pour les applications orientées consommateurs avec support pour les normes comme OAuth2 et SAML.

L'utilisation d'un IdP tiers décharge le fardeau du stockage sécurisé des justificatifs, du chiffrement et de la conformité. Il simplifie également la mise en œuvre de fonctionnalités avancées comme MFA, la récupération de compte, et la protection contre les forces brutes.

Authentification personnalisée dans les fonctions sans serveur

Lorsque vous avez besoin d'un contrôle complet du flux d'authentification — par exemple, lors de l'intégration avec une base de données utilisateur existante ou de l'application de protocoles d'authentification propriétaires — vous pouvez implémenter la logique d'authentification directement à l'intérieur d'une fonction Lambda ou d'une autre fonction sans serveur.

Cependant, construire l'authentification personnalisée à partir de zéro est risqué. Les fonctions sans serveur sont apatrides, de sorte que vous devez gérer en toute sécurité le hachage de mot de passe (en utilisant bcrypt ou Argon2), la génération de jetons, et la gestion de session.

OAuth2 et OpenID Se connecter sans serveur

OAuth2 est la norme industrielle pour l'autorisation déléguée, permettant aux applications d'accéder aux ressources pour le compte d'un utilisateur sans partager d'identifiants. OpenID Connect (OIDC) se base sur OAuth2 pour ajouter une vérification d'identité. De nombreuses applications sans serveur utilisent les flux OAuth2/OIDC pour permettre aux utilisateurs de se connecter avec Google, GitHub ou Facebook, puis de délivrer des JWT qui portent des réclamations d'utilisateur.

Connexion sociale et MFA

L'authentification par Google et GitHub peut être intégrée via les SDK de la plate-forme ou en implémentant manuellement le flux de code d'autorisation OAuth2. L'appariement de la connexion sociale avec MFA ajoute une couche supplémentaire de sécurité : même si un compte social est compromis, l'attaquant ne peut accéder à l'application sans serveur sans un second facteur. La plupart des IdPs prennent en charge MFA hors de la boîte, mais vous devez le configurer dans le tableau de bord d'IdPs et le faire appliquer en option pour les opérations sensibles.

Authentification basée sur les jetons : l'os de l'Auth sans serveur

Comme les fonctions sans serveur sont apatrides, les jetons — en particulier les jetons JSON Web (JWT) — sont le mécanisme privilégié pour transmettre des informations d'authentification et d'autorisation entre les services. Un jeton JWT est un jeton compact, sécurisé par URL, qui consiste en un en-tête, une charge utile (réclamations) et une signature. La signature garantit que le jeton n'a pas été falsifié.

Structure et validation du JWT

La charge utile contient des revendications standard (émetteur, sujet, expiration) et des revendications personnalisées (rôles, permissions, identifiant d'utilisateur). Dans un contexte sans serveur, les fonctions valident la signature, l'expiration et l'émetteur du jeton avant de procéder. De nombreux fournisseurs de cloud offrent des autorisants Lambda préconstruits ou des autorisants API Gateway JWT qui gèrent automatiquement la validation du jeton, en retournant une politique IAM qui accorde ou refuse l'accès au paramètre.

Par exemple, lorsque vous utilisez Auth0 avec AWS Lambda, vous configurez un autorisant personnalisé qui vérifie le jeton contre le paramètre JWKS d'Auth0. L'autorisant fixe ensuite les revendications décodées au contexte de l'événement, permettant à la Lambda de prendre des décisions d'autorisation à grain fin sans effectuer de nouveau la validation de jeton.

Authentification de la séance par rapport à l'authentification de la marque

Les applications traditionnelles basées sur le serveur dépendent des cookies de session stockés sur le serveur. Dans les sessions sans serveur, les sessions deviennent difficiles parce que les fonctions sont éphémères et l'échelle à zéro briserait les magasins de session dans la mémoire. L'authentification basée sur les jetons déplace l'état vers le client: le jeton porte toutes les informations nécessaires, et le serveur n'a besoin que de valider sa signature. Cette approche apatride s'évalue sans effort, mais nécessite des stratégies de révocation de jetons prudentes (par exemple, en utilisant des jetons de blacklists ou de courts délais d'expiration combinés avec des jetons de rafraîchissement).

Modèles d'autorisation pour les serveurs sans serveur

Après l'authentification, l'autorisation détermine ce que cette identité peut faire. Trois modèles communs sont le contrôle d'accès fondé sur les rôles (RAC), le contrôle d'accès axé sur les attributs (ABAC) et le contrôle d'accès fondé sur les politiques (PBAC).

Contrôle d'accès axé sur les rôles (CARAR)

Dans RBAC, les autorisations sont regroupées en rôles (par exemple, admin, éditeur, visualisateur). Les utilisateurs se voient attribuer un ou plusieurs rôles et le système vérifie si le rôle de l'utilisateur permet l'action demandée. RBAC est simple à implémenter : après avoir décodé le JWT, vérifiez si la revendication de rôle contient le rôle requis pour le paramètre.

Contrôle d'accès par attributs (ABAC)

L'ABAC évalue l'accès en fonction d'une combinaison d'attributs utilisateurs (p. ex., niveau de décharge, niveau de vérification), d'attributs de ressources (p. ex., classification des documents) et de conditions environnementales (p. ex., heure de la journée, adresse IP). Par exemple, un utilisateur ne peut voir des documents dans son propre ministère que pendant les heures d'ouverture.

Contrôle d'accès fondé sur les politiques (CACGP)

Les services Cloud comme AWS Identity and Access Management (IAM) vous permettent de définir des politiques JSON qui précisent quelles actions sont autorisées sur quelles ressources. Ces politiques peuvent être attachées aux rôles assumés par la fonction ou à la session user. Combinés avec API Gateway, vous pouvez faire respecter l'autorisation sans écrire de code — la passerelle évalue la politique avant d'invoquer la fonction. Ce modèle est particulièrement puissant pour les microservices où la cohérence entre les services est critique.

Mise en œuvre de l'autorisation dans les applications sans serveur

Il y a trois couches primaires où l'autorisation peut être appliquée : à la passerelle API (avant les opérations de la fonction), à l'intérieur d'un autorisant Lambda, ou à l'intérieur de la fonction elle-même.

Autorisation de passerelle API (construire)

Par exemple, API Gateway , Azure API Management et Google Cloud Endpoints prennent en charge la validation JWT native et l'autorisation basée sur les politiques. L'API HTTP de API Gateway , par exemple, peut valider un JWT à partir d'un émetteur spécifié, puis cartographier les revendications de droits de route. Cette approche est rapide car la validation se produit au bord du réseau, réduisant les invocations et les coûts de Lambda.

Autorisateurs de fonction Lambda

Un Lambda Authorer (anciennement appelé authorer personnalisé) est une fonction qui reçoit le jeton (en tant qu'en-tête ou paramètre de requête au porteur) et renvoie une politique IAM que l'API Gateway applique. L'autorisant peut décoder le JWT, appeler un service externe ou demander une base de données pour déterminer les permissions de l'utilisateur. Parce que l'autorisant est lui-même une fonction sans serveur, il peut implémenter n'importe quelle logique. Cependant, il ajoute latence — généralement 50–200ms de plus par requête — et peut devenir un goulot d'étranglement si ce n'est pas conçu avec soin.

Autorisation directe Fonctions intérieures

Dans certaines architectures, en particulier celles qui ne sont pas placées sous la passerelle d'une API (p. ex. fonctions animées par des événements, résolveurs GraphQL), l'autorisation doit se faire à l'intérieur de la fonction. Ce modèle consiste à décoder le JWT et à vérifier les autorisations par rapport à une base de données ou un cache.

Par exemple, en utilisant le middleware pour Lambda, vous pouvez créer un middleware d'autorisation qui analyse le JWT, valide les rôles et renvoie une réponse 403 ou passe le contrôle au gestionnaire. Cela maintient le code de fonction propre et fait appliquer un point d'autorisation unique.

Pratiques exemplaires pour l'authentification et l'autorisation sans serveur sécurisé

Au-delà de la sélection des bons outils et modèles, une couche d'auth sans serveur sécurisée nécessite le respect des meilleures pratiques opérationnelles. Les recommandations suivantes sont tirées de la documentation du fournisseur de cloud et des lignes directrices OWASP.

Utiliser HTTPS partout

Toute communication entre les clients, la passerelle API et les fonctions de backend doit être cryptée avec TLS. Le pinning de certificat peut être ajouté pour les clients mobiles, mais s'assurer que les certificats sont régulièrement tournés.

Appliquer le moindre privilège

Chaque fonction ne devrait être accordée que les permissions dont elle a besoin. Utilisez des rôles IAM à grain fin pour les fonctions Lambda, et évitez d'attribuer des permissions larges comme . De même, les autorisants de passerelle API devraient retourner des politiques qui limitent l'accès à des ressources spécifiques.

Mettre en œuvre l'authentification multi-facteurs (AMF)

Activer MFA pour toute opération sensible, en particulier les paramètres d'administration. Les IdPs comme Cognito et Auth0 supportent MFA avec TOTP ou SMS. Dans les serveurs, vous pouvez forcer la vérification MFA pour des routes API spécifiques en vérifiant une réclamation dans le JWT (par exemple, .

Valider les jetons à chaque frontière

Ne présumez pas qu'un jeton passé à une fonction a déjà été validé par un service en amont. Chaque fonction devrait vérifier indépendamment la signature du jeton, l'expiration et l'émetteur. Cette défense en profondeur empêche un seul point de défaillance.

Gérer les secrets en toute sécurité

N'utilisez jamais les clés d'API du code dur, les clés secrètes ou les identifiants de base de données dans le code de fonction. Utilisez un gestionnaire de secrets comme AWS Secrets Manager, AWS SSM Parameter Store ou HashiCorp Vault. Pour le développement local, utilisez les variables d'environnement avec prudence et ne les engagez jamais au contrôle de version.

Rotation régulière des clés

Rotation des clés de signature, des clés API et des secrets clients sur un horaire régulier (par exemple tous les 90 jours). Automatiser la rotation à l'aide des outils du fournisseur de cloud. Pour les JWT, assurez-vous que l'URL de la clé publique (JWKS end) est mise à jour avant que les anciennes clés expirent pour éviter les défaillances de validation.

Accès au journal et au moniteur

Activer la connexion détaillée pour les journaux d'accès aux passerelles API et les journaux Lambda CloudWatch. Surveiller les modèles anormaux tels que les erreurs répétées 401, les emplacements géographiques inhabituels ou les tentatives d'accès à des ressources non autorisées.

Mettre en œuvre la limitation des taux et le throttling

Utilisez des plans d'utilisation de passerelles API, des throttlings ou un WAF (Web Application Firewall) pour protéger les paramètres d'authentification (p. ex. /login) contre les attaques de force brute.

Tester la logique avec soin

Écrire des tests unitaires et des tests d'intégration pour votre code d'authentification et d'autorisation. Inclure des tests pour les jetons expirés, les jetons mal formés, les revendications manquantes et tenter de contourner l'autorisation.

Restez à jour sur les patchs de sécurité

L'écosystème sans serveur évolue rapidement. Abonnez-vous aux avis de sécurité de votre fournisseur d'IDP et de cloud. Appliquez régulièrement les correctifs aux versions et dépendances d'exécution de Lambda (par exemple, les bibliothèques JWT, les clients HTTP).

Conclusion

En exploitant les fournisseurs d'identité gérés, les authentifications basées sur des jetons et les modèles d'autorisation en couches, vous pouvez créer une fondation sécurisée qui s'élargit à mesure que votre base d'utilisateurs grandit. Les modèles décrits dans cet article — IdPs tiers, validation JWT, autorisants de passerelle API et RBAC/ABAC — sont prouvés dans les environnements de production et adaptables à tout fournisseur de cloud majeur.

N'oubliez pas que la sécurité est une pratique continue, pas une configuration unique. Passez régulièrement en revue vos politiques d'authentification, les journaux de vérification et les dépendances de mise à jour. Avec la bonne approche, l'authentification et l'autorisation sans serveur deviennent des moteurs, et non des obstacles, pour construire des applications rapides, sécurisées et évolutives. Pour plus de détails, consultez les OWASP Top Ten et JWT.io[ pour les meilleures pratiques de validation des jetons.