Le Guide API ReST | Marmicode
  • Le Guide API ReST par Marmicode
  • API ReST
    • L'Ecosystème Moderne
    • Le Besoin
    • Re.S.T. : REpresentational State Transfer
    • Les 5 règles et ½ de l’API ReST
    • Le Modèle de Maturité de Richardson
    • H.A.T.E.O.A.S. & Resource Linking
    • Avis Subjectif sur H.A.T.E.O.A.S. et le Semantic Web
    • ReST over HTTP
    • HTTP & CRUD
    • ReSTful donc Stateless
    • Pragmatisme, Idéologie et ReSTafarians
  • Conventions & Bonnes Pratiques
    • Nommage
    • Base URL
    • Media Type
    • Versioning
    • Propriété “id”
    • Polymorphisme
    • Datetime
    • Ressource d'Association
    • Pourquoi Appliquer ces Bonnes Pratiques
    • Zalando ReSTful API Guidelines
  • Les Outils
    • Swagger
    • OpenAPI Visual Editors
    • IDE Plugins
    • Postman
    • Insomnia
    • Fake & Sandbox
    • JSON Generator
    • Pact
  • Sécurité des APIs ReST
    • OWASP Top 10
    • Authentification et Session Management
    • Autorisation et Gestion des Permissions
    • Validation, Canonicalization, Escaping & Sanitization
    • Cookies are EVIL
    • C.O.R.S.
    • C.S.R.F.
    • C.S.R.F. & Media Type
    • C.S.R.F. Mitigation
    • C.S.R.F. & "Resource Linking"
    • J.O.S.E.
      • J.W.K.
      • J.W.S.
      • J.W.E.
    • J.W.T.
      • Description et Fonctionnement de JWT
      • Usages et Avantages
      • Utilisation de JWT pour l’Authentification
      • JWT, Authentification, Sessions et Risques Sécurité
      • Recommandations JWT
    • OAuth 2
      • OAuth 2 Roles
      • OAuth 2 Abstract Flow
      • OAuth 2 Authorization Code Flow
      • OAuth 2 Implicit Flow
      • OAuth 2 Resource Owner Password Credentials Flow
      • OAuth 2 Client Credentials
      • OAuth 2 Registration
      • OAuth 2 Risques & Recommandations
      • OAuth 2 Substitution Attack
    • OpenID Connect
      • Terminologie
      • Quoi de Neuf ?
      • OpenID Connect Flows
      • Que Faire ?
  • Autres Spécifications
    • JSON API
    • H.A.L.
    • JSON LD
    • Les Autres Initiatives
    • So What?
  • Quelques Liens & Ressources
  • Stay Tuned
    • 📝Blog
    • 🐦Twitter
    • 📬Newsletter
Propulsé par GitBook
Sur cette page
  1. Sécurité des APIs ReST
  2. OAuth 2

OAuth 2 Risques & Recommandations

PrécédentOAuth 2 RegistrationSuivantOAuth 2 Substitution Attack

Dernière mise à jour il y a 6 ans

TLS EVERYWHERE! OAuth 2 n’oblige malheureusement pas l’utilisation du TLS pour les "Redirect URI" mais le recommande fortement.

L'Authorization Server doit vérifier que le Client possède bien le nom de domaine associé à la Redirect URI. (E.g. : Vérification de la capacité du client à ajouter une entrée DNS TXT proposée aléatoirement par l'Authorization Server)

L'Authorization Server devrait permettre aux Clients de renouveler rapidement le Client Secret.

L'Authorization Server devrait obliger les Clients à renouveler régulièrement le Client Secret.

  • Le Client Secret est souvent stocké dans une variable d’environnement sur le serveur d’application.

  • Une erreur de configuration suffit pour compromettre tout le système.

  • L'Authorization Server peut permettre de modifier le Redirect URI simplement en présentant le Client ID et le Client Secret.

Les Redirect URIs sont des absolute URIs (scheme, fqdn, port, path) et ne doivent pas contenir de “fragment” (#…).

L'Authorization Server doit vérifier les Redirect URIs avec une égalité stricte. E.g. : est strictement différente de .

https://www.wishtack.com/oauth?source=test
https://www.wishtack.com/oauth