In OAuth 2, warum gibt es ein Access Token, wenn es einen Autorisierungscode gibt?

Question

App tauscht Autorisierungscode für Zugriffstoken aus. Und mit Access Token App kann API-Anrufe tätigen. Wie auch immer, ich verstehe nicht wirklich, warum OAuth 2 diesen Schritt hat, scheint wie ein zusätzlicher Schritt.

1 Grund, den ich fand, ist, dass Autorisierungscode durch Redirectanruf auf Klientenseite gegeben wird, also hat es Potenzial, gefährdet zu werden, also ist es kurzlebig. Während Access-Token Server an Server übergeben wird.

Das stimmt, aber es gibt auch Secret Api-Schlüssel, die App sendet senden. Warum konnte das nicht mit dem Autorisierungscode getan werden?

Angenommen, es gab kein Access-Token, sondern nur Autorisierung. Wenn dann jemand den Autorisierungscode bekommt, wäre er nicht in der Lage, etwas zu tun, wenn der Oauth2-Server auch den Geheimschlüssel entlang des Autorisierungscodes überprüft.

Es sollte Oauth Server ermöglichen:

1. stellen Sie sicher, wurde angefordert von App (authentifizieren)
2. , welche Arten von Erlaubnis erteilt wurden (autorisieren)

Answer 1

Fähigkeit zu erhalten access_token direkt (Impliziter Grant-Typ) ist für JavaScript-Clients oder Webanwendungen erforderlich, die in einem Browser ausgeführt werden. Diese Clients sind aufgrund der verfügbaren Optionen zum Speichern des Clientgeheimnisses nicht sicher. Die Client-ID und das Geheimnis müssen den Autorisierungscode für ein access_token austauschen.

Diese beiden Grant-Typen bieten unterschiedliche Sicherheitsstufen bei der Implementierung der Authentifizierung.

Wenn die Ressource, die von der API bedient wird, extrem empfindlich ist, möchten Sie höchstens die Sicherheit, die durch den Autorisierungscode-Fluss bereitgestellt wird. In diesem Berechtigungstyp validieren Sie den Client (serverseitige API oder einen mobilen Client) und den Ressourcenbesitzer (Benutzer), bevor Sie den Zugriff auf die Ressource gewähren. Das access_token ist nicht einmal dem Browser/Benutzer ausgesetzt (da ein gestohlenes Token Zugriff auf die Ressource geben kann), wodurch ein hohes Maß an Sicherheit gegeben ist. Dieser Fluss ist komplex und umfasst mehr Umläufe zum Autorisierungsserver, bietet aber mehr Sicherheit.

Wenn Sie diese Art von Sicherheit für eine Ressource nicht benötigen, können Sie den Implicit-Grant-Typ verwenden, wenn der Browser/Benutzer Zugriff auf das Token hat. Dieser Ablauf ist einfach mit nur einer Fahrt zum Autorisierungsserver. Es wird den Client nicht validieren. Sie müssen das Client-Geheimnis nicht mit dem Browser speichern.

Hoffentlich macht das Sinn. Bitte lassen Sie mich wissen, wenn Sie irgendwelche Fragen haben.

Vielen Dank, Soma.