Warum senden Sie nicht gleichzeitig Zugriffs- und Aktualisierungstoken (OAuth2)?

Question

Warum kann der Client nicht einfach sowohl den Zugriffs- als auch den Aktualisierungstoken für jede autorisierte Anforderung zusammen senden? Wenn das Zugriffstoken abgelaufen ist, würden zwei zusätzliche Auslösungen nicht erforderlich sein, um ein neues Zugriffstoken abzurufen und schließlich die entsprechende Anfrage zu stellen.

Ich weiß, dass diese Operation amortisiert ist, aber es würde die Anzahl der Anfragen für sehr kurze Zugriffsmarken verringern. Und unter SSL sehe ich nicht, wie das Hinzufügen des Refresh-Tokens dieses anfälliger macht. Oder tut es?

Answer 1

Ich denke, der Hauptgrund ist, dass das Aktualisierungstoken und das Zugriffstoken an verschiedene Orte gesendet werden. Das Zugriffstoken wird an den Ressourcenserver gesendet und das Aktualisierungstoken wird an den Autorisierungsserver gesendet. Im allgemeinen Fall gibt es nichts, was der Ressourcenserver mit dem Aktualisierungstoken tun kann.

Answer 2

Einige Gründe:

Der Zugriffstoken bietet eine Abstraktionsschicht, unterschiedliche Berechtigungs Konstrukte (z.B. Benutzername und Passwort) mit einer einzigen Token durch die Ressourcen-Server verstanden ersetzen. Diese Abstraktion ermöglicht das Ausgeben von Zugriffstoken, die restriktiver sind als die Autorisierungszuteilung , die zum Abrufen verwendet werden, sowie das Entfernen des Ressourcenservers , um eine breite Palette von Authentifizierungsmethoden zu verstehen.

https://tools.ietf.org/html/rfc6749#section-1.4

• der Ressource-Server versteht Refresh-Token für sie bedeutet mehr Arbeit zu haben, wenn es entfernt (mit dem Autorisierungsserver) abstrahiert werden kann/soll.

...

Da Refresh-Token sind in der Regel lang anhaltende Anmeldeinformationen verwendeten Anfrage zusätzlicher Zugriffstoken werden die Aktualisierungs-Token an den Client gebunden wurde, erteilt an denen. Wenn der Clienttyp vertraulich ist oder dem Client Client-Anmeldeinformationen (oder andere Authentifizierungsanforderungen) zugewiesen wurden, MUSS der Client mit dem Autorisierungsserver wie in Abschnitt 3.2.1 beschrieben authentifizieren.

https://tools.ietf.org/html/rfc6749#section-6

• Eine Auffrischanforderung erfordert Anmeldeinformationen Client. Der Ressourcenserver sollte die Anmeldeinformationen des Clients nicht sehen müssen.

• Refresh-Tokens sind langlebig, während Access-Tokens nicht (oder nicht) sind.