Sécurisation des APIs HTTP

HTTPS :

• Offre des services d'authentification clé en main.s

• Offre des services d'autorisation clés en main.

• Chiffre une communication HTTP afin que seuls le client et le serveur ne puissent la voir.

• Chiffre une communication HTTP afin que seuls le client, le serveur, et les proxys intermédiaires ne puissent la voir.

Une personne malintentionnée peut modifier les certificats de mon navigateur :

• Elle peut se débrouiller pour écouter mes communications, même en HTTPS.

• Elle peut se débrouiller pour écouter mes communications en HTTP.

• Je risque de ne plus avoir la petite coche ou le petit bouclier quand je consulte un site.

Je suis gestionnaire d'un site web, dont certaines pages contiennent des données personnelles, voire confidentielles.

• Je force toutes les requêtes concernant ces pages à passer en HTTPS.

• Je demande à l'utilisateur de choisir entre HTTP et HTTPS.

• Je m'astreins à gérer, ou faire gérer, les certificats de ce site.

• J'achète un certificat qui n'a pas de limite de temps.

J'ai besoin d'une solution de SSO, je peux :

• Développer mon propre fournisseur d'identité avec OpenIdConnect.

• Partager mes Cookies de session entre mes différents sites.

• Me brancher sur un fournisseur d'identité déjà existant (type OpenIdConnect).

• Demander à l'utilisateur de mettre les mêmes mots de passe sur tous les sites que je gère.

Pour OpenIdConnect, un JWT est :

• Toujours signé, mais jamais chiffré.

• Toujours signé et chiffré.

• Toujours chiffré.

• Signé, voire signé et chiffré.

Je veux récupérer le nom et le prénom de l'utilisateur pour l'afficher sur mon site. Or, ces informations sont dans l'IDentity Provider d'OpenId Connect.

• Je demande à l'utilisateur de le retaper.

• Je mets en place un batch pour récupérer toutes les nuits ces informations de l'IDentity Provider.

• Je tire ces informations de l'ID token

• Je mets <insérer votre nom ici> à la place du nom (et je mets la faute sur le dos des développeurs Front).