1. Introduction (Einführung)
1. Introduction (Einführung)
Mehrjährige Bereitstellungs- und Implementierungserfahrung mit dem OAuth-2.0-Autorisierungsrahmen [RFC6749] hat einen Bedarf aufgezeigt (unter Umständen, etwa wenn ein Autorisierungsserver eine erhebliche Anzahl unterschiedlicher Ressourcen bedient), dass der Client dem Autorisierungsserver ausdrücklich signalisiert, wo er das angeforderte Zugriffstoken (access token) einsetzen will.
Die Kenntnis der geschützten Ressource (auch Ressourcenserver, Anwendung, API usw. genannt), die das Zugriffstoken verarbeiten wird, ermöglicht dem Autorisierungsserver, das Token für diese Entität wie erforderlich zu konstruieren. Das ordnungsgemäße Verschlüsseln des Tokens (oder des Inhalts im Token) für eine bestimmte Ressource erfordert beispielsweise die Kenntnis, welche Ressource das Token empfängt und entschlüsselt. Darüber hinaus haben verschiedene Ressourcen oft unterschiedliche Anforderungen an die im Token enthaltenen (oder referenzierten) Daten, und die Kenntnis der Ressource, in der der Client das Token nutzen will, erlaubt dem Autorisierungsserver, das Token entsprechend auszugeben.
Spezifisches Wissen über die beabsichtigten Empfänger des Zugriffstokens unterstützt auch verbesserte Sicherheitseigenschaften des Tokens selbst. Bearer-Tokens, derzeit die am häufigsten genutzte Art von OAuth-Zugriffstoken, erlauben jeder Partei im Besitz eines Tokens, Zugang zu den zugehörigen Ressourcen zu erhalten. Zum Schutz vor Missbrauch müssen mehrere wichtige Sicherheitsannahmen gelten, darunter dass ein Zugriffstoken nur für eine bestimmte geschützte Ressource und einen bestimmten Zugriffsbereich (scope) gültig sein darf. Abschnitt 5.2 von [RFC6750] schreibt beispielsweise vor, die beabsichtigten Empfänger des Tokens im Token aufzunehmen, um Token-Weiterleitung zu verhindern. Wenn der Autorisierungsserver über die Ressource informiert ist, die das Zugriffstoken verarbeiten wird, kann er die beabsichtigte Audience dieses Tokens auf die genannte Ressource beschränken, sodass das Token an anderen Ressourcen nicht erfolgreich verwendet werden kann.
OAuth-Scope gemäß Abschnitt 3.3 von [RFC6749] wird mitunter überladen, um Ort oder Identität der geschützten Ressource zu übermitteln; das ist jedoch nicht immer machbar oder wünschenswert. Scope betrifft typischerweise, welcher Zugriff angefordert wird, nicht wo dieser Zugriff eingelöst wird (z. B. sind „email“, „admin:org“, „user_photos“, „channels:read“ und „channels:write“ eine kleine Stichprobe von Scope-Werten im Einsatz, die nur die Art des Zugriffs und nicht Ort oder Identität übermitteln).
Unter manchen Umständen und für manche Bereitstellungen ist ein Mittel für den Client wichtig und nützlich, dem Autorisierungsserver zu signalisieren, wo er das angeforderte Zugriffstoken einsetzen will. Eine Reihe von OAuth-2.0-Implementierungen und -Bereitstellungen hat bereits proprietäre Parameter zu diesem Zweck eingesetzt. Diese Spezifikation strebt an, künftig eine standardisierte und interoperable Alternative zu proprietären Ansätzen zu bieten.