2017-12-09 1 views
1

Wir prüfen eine Option, wenn das "gleiche" azur AAD-Zugriffstoken für den Zugriff auf mehrere Webapis verwendet wird. Hier ist der Fluss:Gleiches Azure AD-Zugriffstoken für mehrere Ressourcen

Client -> webapi1 -> webapi2 

1) client authenticates against AAD and acquires token1 <br> 
2) client calls webapi1 with token1<br> 
3) webapi1 calls webapi2 with token1 

Können sagen, sowohl die WebAPI die konfiguriert sind, das gleiche Publikum (‚xxxx‘) und Autorität zu bestätigen, gibt es irgendwelche Komplikationen/Sicherheitsproblem die gleiche Token zu nutzen, sowohl für den Apis.

Jede Eingabe wird sehr geschätzt.

+0

Ich bin neugierig, warum Sie das tun möchten? Ich kann über einige Gründe nachdenken, würde aber gern hören, was Ihre Argumentation ist. – juunas

+0

Ein Grund ist, einen Hin- und Rückweg zum AAD zu vermeiden, um ein für webapi2 spezifisches Token zu holen. – Chilu

+0

Richtig, obwohl Sie das Token zwischenspeichern können :) Hoffentlich optimieren Sie nicht zu früh. – juunas

Antwort

1

In diesem Fall sind webapi1 und webapi2 im Wesentlichen die gleiche API, soweit es Azure AD betrifft.

Eine Konsequenz dieses Ansatzes ist möglicherweise zu viele Privilegien auf den APIs.

Nehmen wir an, API A benötigt Zugriff auf die E-Mails aller Benutzer in der Organisation. Jetzt, da API B aus Sicht von AAD tatsächlich die gleiche App ist, bekommt es auch das Recht, obwohl es es nicht brauchte.

In der Regel versuchen wir, dem Prinzip der geringsten Rechte zu folgen, bei dem jeder Teil der App genau den Zugriff hat, den er benötigt, und nicht mehr. Das gleiche Publikum erneut zu erreichen, kann dagegen gehen.

Ein weiteres Problem ist, dass eine andere App, die Rechte API A auch Rechte API B.

ich Ihre Argumentation verstehen, die Hin- und Rückfahrt zur Vermeidung einer zusätzlichen Token des Abrufens kann anrufen wird anrufen, aber Token zwischengespeichert werden können .

Verwandte Themen