# Do's and Dont's

Hier finden Sie für die Implementierung hilfreiche Do's and Don'ts.

# Do's:

  • Auch wenn Sie OAuth2 nicht verwenden, um Userdaten abzurufen, SOLLTEN Sie den Access-Token-Endpunkt verwenden, um zu validieren, dass der Authorization Code von DocCheck generiert wurde.
    Sie SOLLTEN den Nutzer ablehnen, wenn die Antwort mit „invalid token“ zurückkommt.
  • Verwenden Sie den „state“-Parameter, um einen eindeutigen Wert durch den Prozess zu schleusen.
    Auch wenn dies mit einigem Aufwand gefälscht werden könnte, wird so typischen Fällen entgegengewirkt, bei denen ein Link weitergegeben wurde.
    Wenn Sie einen verschlüsselten Zeitstempel verwenden, um Aufrufe derselben URL zu einem späteren Zeitpunkt abzulehnen, verringern Sie zusätzlich die Möglichkeit, dass jemand seine Zugriffs-URL weitergibt.
  • Beim Aufrufen eines OAuth-Endpunkts MÜSSEN Sie dokumentierte Fehlerrückmeldungen verarbeiten.
    Ihr Anmeldeprozess SOLLTE NICHT stillschweigend oder unkontrolliert scheitern, wenn beispielsweise ein Access-Token abgelaufen ist oder widerrufen wurde. Sie SOLLTEN dem User eine entsprechende Fehlerseite anzeigen und das jeweilige Problem innerhalb Ihrer IT-Systeme eskalieren.

# Dont's:

  • Access-Tokens oder andere sensible Informationen DÜRFEN NICHT in einem Cookie gespeichert werden.
    Bedenken Sie, dass der Access-Token alles ist, was benötigt wird, um auf Userdaten zuzugreifen.
  • Die Überprüfung, ob ein User über DocCheck gekommen ist, SOLLTE NICHT über Referrer-Prüfungen erfolgen.
    Referrer stehen vollständig unter der Kontrolle des Users, können daher gefälscht werden, sind oft unzuverlässig und die Domain und IP-Adressen der DocCheck-Server können sich ohne Vorankündigung ändern.
  • Sie DÜRFEN sich NICHT auf etwas verlassen, das in dieser Dokumentation nicht ausdrücklich dokumentiert ist. Das Vorhandensein oder Nichtvorhandensein von URL-Parametern DARF NICHT genutzt werden, um zu entscheiden, ob ein Nutzer akzeptiert oder abgelehnt wird.
  • Das Vorhandensein von nicht dokumentierten oder anderen zusätzlichen Parametern DARF Ihren Login-Prozess NICHT zum Scheitern bringen.
    Wenn Sie beispielsweise den Userdaten Endpunkt aufrufen und mehr Parameter erhalten als zuvor erwartet, DARF dies NICHT zu einem Fehler führen. Solche Parameter SOLLTEN ignoriert werden.

Info

Die Schlüsselwörter „MUSS“, „DARF NICHT“, „ERFORDERLICH“, „SOLL“, „SOLL NICHT“, „SOLLTE“, „SOLLTE NICHT“, „EMPFOHLEN“, „KANN“ und „OPTIONAL“ in diesem Dokument sind gemäß der Beschreibung in RFC 2119 zu interpretieren.

ON THIS PAGE