Article
OAuth est né du web social, initialement motivé par un désir de permettre aux utilisateurs de définir les permissions d’autorisation sans divulguer les identifiants des réseaux sociaux, communément appelé mot de passe antipattern.
OAuth 2.0 prend en charge les configurations d’autorisation déléguée du web des consommateurs mais aujourd’hui il est également adapté aux entreprises et au cloud. Par exemple, Salesforce.com utilise OAuth pour protéger les nombreuses API qu’elle offre à ses clients professionnels. Les entreprises utilisent OAuth pour protéger les API qu’elles proposent à leurs partenaires et à leurs clients ainsi qu’aux clients internes en s’inspirant du « cloud privé ».
Le protocole OAuth 2.0 est explicitement conçu pour prendre en charge divers types de clients, accédant aux REST API. Elles incluent les applications fonctionnant sur des serveurs web au sein de l’entreprise en sollicitant le cloud, ainsi que les applications fonctionnant sur les terminaux mobiles des employés et des clients. Le protocole OAuth prend en charge cette variété de types de clients en définissant de multiples mécanismes pour obtenir un jeton lorsque les différents mécanismes reconnaissent les contraintes du client type.
OpenID Connect est construit sur un profil d’OAuth, et fournit des fonctionnalités supplémentaires en transmettant l’identité de l’utilisateur utilisant l’application, et pas seulement l’application.
Un fondement technique clé du cloud est l’interface de programmation d’application (API). Les API procurent des méthodes cohérentes pour que les entités externes puissent accéder aux services hébergés sur le cloud et manipuler ceux-ci. Les données du cloud vont de plus en plus transiter par des API plutôt que par le navigateur. Pour les API basées sur des standards SOAP (Simple Object Access Protocol), les standards tels que WS-Trust et WS-Security définissent comment les clients des API sont authentifiés. Les services de REST n’ont pas, quant à eux, de fonctions standardisées équivalentes.
Alors que WS-Trust et WS-Security fournissaient des services aux clients des API SOAP pour obtenir des identifiants d’authentification et rattacher ces identifiants aux requêtes des API, les clients des API REST géraient les identifiants utilisés pour s’authentifier aux API ainsi qu’aux API définies par divers mécanismes pour cette authentification.
OAuth 2.0 fournit les mêmes fonctionnalités que celles des API REST, puisque WS-Trust et WS-Security fournissent des services web SOAP. En particulier, fournir des mécanismes standardisés pour permettre aux clients des API d’« obtenir » et d’« utiliser » des jetons ; par exemple, présenter le jeton lors de la requête de l’API pour s’authentifier.
Lancez-vous dès Aujourd'hui
Découvrez comment Ping peut vous aider à protéger vos employés et améliorer l'expérience de vos clients dans un monde digital en constante évolution.
Démonstration Gratuite
Nous vous remercions ! Veuillez consulter votre boîte email.