La portée de l’autorisation est définie par les Scopes. C’est sans doute le point le plus ouvert du standard et donc un concept difficile à maîtriser pour le développeur d’une application utilisant OpenID Connect.
La possibilité de moduler les portées d’autorisation en fonction de (…)
Le règlement général sur la protection des données (RGPD) impose une gestion rigoureuse des données personnelles ce qui implique de demander à leur propriétaire l’autorisation d’y accéder. Quels sont les cas de figure à distinguer ? Comment gérer les demandes de consentement sur les portées (…)
Les requêtes HTTP de type multi-origines (Cross-Origin Resource Sharing) sont des requêtes pour des ressources localisées sur un domaine différent de celui qui est à l’origine de la requête.
C’est exactement la configuration dans laquelle nous nous trouvons quand nous voulons appliquer les (…)
Documents essentiels
Synthèse : OAuth 2.0 Code : Brent Shaffer’s OAuth Server PHP
Documents de l’IETF RFC 6749 L’architecture d’authentification OAuth 2.0. L’architecture d’autorisation OAuth 2.0 permet à une application tierce d’obtenir un accès limité à un service HTTP, soit au nom d’un (…)
Dans cet article, nous traitons de l’accès à une ressource protégée suivant le protocole HTTP REST, avec les bonnes pratiques.
Envoi d’une requête à une ressource protégée
Il y a trois méthodes pour l’envoi d’une requête à une ressource protégée : une bonne, une acceptable et une non recommandée. Ce qui suit est une traduction de parties de la RFC 6750, section 2 :
2. Requêtes authentifiées
Cette section définit trois méthodes d’envoi de jetons d’accès aux serveurs de ressources. Les clients NE DOIVENT PAS utiliser (...)
OpenID Connect OAuth Server dédié
Plus de sécurité et de confidentialité avec un serveur d’authentification indépendant