OpenID-Provider für OAuth-Anforderungen mit zwei Beteiligten konfigurieren
Beim typischen OAuth-Datenfluss gibt es drei "Beteiligte" oder Phasen der Interaktion zwischen einem Client und einem Berechtigungsserver. Bei OAuth-Szenarien mit zwei Beteiligten verwendet der Client vorab autorisierte Bereiche, sodass keine Interaktion mit dem Benutzer erforderlich ist und einer der Beteiligten bzw. eine der Interaktionsphasen des typischen Datenflusses entfällt. Konkret bedeutet dies, dass der Benutzer sich nicht gegenüber dem Berechtigungsserver authentifizieren muss und keine Zustimmung zur gemeinsamen Nutzung der von den angeforderten Bereichen angegebenen Informationen geben muss. Stattdessen werden alle angeforderten Bereichsparameter als vorab autorisiert betrachtet und dem Anforderungstoken automatisch hinzugefügt, das dann an den Berechtigungsserver gesendet wird.
Vorbereitende Schritte
Informationen zu diesem Vorgang
Bei Szenarien mit zwei Beteiligten oder Phasen kann ein OpenID Connect-Client eine HTTP-Anforderung mit zwei Beteiligten mit dem Grant-Typ (grant type) client_credential oder resource owner password senden. Diese Anforderungen passieren nicht den Berechtigungsendpunkt, sodass es keine Einwilligungserklärung für Bereiche gibt, in denen Benutzer den angeforderten Bereichen zustimmen. Der OpenID Connect-Provider muss aber dennoch die autorisierten Bereiche in seinem access_token-Inhalt bearbeiten.
Als OpenID Connect-Provider konfigurierte Liberty-Server, die für die Bearbeitung von OAuth-Anforderungen mit zwei Beteiligten ausgestattet sind, genehmigen die vorab autorisierten Bereiche unter Verwendung der folgenden Kriterien:
- Wenn der Parameter grant_type einer Anforderung den Wert client_credential oder resource owner password hat und die Anforderung eine OAuth 2.0-Anforderung ist, werden alle in der Anforderung definierten Bereiche genehmigt und in den Inhalt des Zugriffstokens kopiert. Dies ist das bestehende Verhalten des OAuth 2.0-Features.
- Wenn die Anforderung eine OpenID Connect- oder JWT-Token-OAuth-Anforderung ist, werden die folgenden Kriterien verwendet:
- Wenn in der Anforderung kein Bereichsparameter angegeben ist, akzeptiert der OpenID Connect-Provider die Anforderung nicht.
- Die angeforderten Bereiche müssen in der Liste der Bereiche enthalten sein, die mit dem Attribut scope der Clientkonfiguration definiert sind. Sie müssen außerdem in der preAuthorizedScope-Liste der Clientkonfiguration angegeben sein.
In dieser Aufgabe wird beschrieben, wie ein als OpenID Connect-Provider agierender Liberty-Server für OAuth-Anforderungen mit zwei Beteiligten konfiguriert wird.
Vorgehensweise
<oauthProvider id="OAuthConfigSample" ...>
....
<localStore>
<client name="client01" secret="{xor}..."
displayname="client01"
scope="profile email phone"
preAuthorizedScope="profile email"
enabled="true" />
....
</localStore>
</oauthProvider>