In OpenID Connect hat ein Zugriffstoken eine Ablaufzeit. Für den Fluss des Autorisierungscodes ist dies normalerweise kurz (z. B. 20 Minuten). Danach verwenden Sie das Aktualisierungstoken, um ein neues Zugriffstoken anzufordern.

Das ID-Token hat auch eine Ablaufzeit. Meine Frage ist, was ist die Absicht davon?

Jede ID-Token-Ablaufzeit, die kürzer als die Ablaufzeit des Aktualisierungstokens ist, bedeutet, dass Sie möglicherweise ein abgelaufenes ID-Token, aber ein gültiges Zugriffstoken haben.

Also sollst du:

• Geben Sie Ihrem ID-Token einen längeren Ablauf als den Ablauf des Aktualisierungstokens
• Stellen Sie den gleichen Ablauf wie das Zugriffstoken ein und ergreifen Sie Maßnahmen (was?), wenn es abläuft, oder
• Verbrauchen Sie einfach das ID-Token in Ihrem Client nach Erhalt und ignorieren Sie danach die Ablaufzeit?

Die OpenID Connect-Spezifikation besagt lediglich, dass bei der Validierung eines ID-Tokens

"The current time MUST be before the time represented by the exp Claim."

was (möglicherweise) die obige dritte Option unterstützt.

BEARBEITEN

Da OpenID Connect auf OAuth2 aufbaut, finden Sie die Antwort auf die folgende Zusatzfrage in der OAuth2-Spezifikation :

expires_in
     RECOMMENDED.  The lifetime in seconds of the access token.

Eine verwandte Frage ist, wenn Sie einen Autorisierungscode gegen die Token austauschen. Dieselbe Spezifikation besagt, dass Sie möglicherweise eine Antwort erhalten, wie zum Beispiel:

{
 "access_token": "SlAV32hkKG",
 "token_type": "Bearer",
 "refresh_token": "8xLOxBtZp8",
 "expires_in": 3600,
 "id_token": "eyJhbG[...]"
}

Aber worauf bezieht sich "expires_in" in diesem Fall? Das Zugriffstoken, das Aktualisierungstoken oder das ID-Token?

(Zur Information setzt IdentityServer3 dies auf die Ablaufzeit des Zugriffstokens.)

Ich beantworte meine eigene Frage, da ich festgestellt habe, dass einige der Annahmen hinter meiner Frage falsch waren. Daher ist es hier einfacher, sie zu klären, als die Frage neu zu schreiben.

Ein ID-Token soll einem Client beweisen, dass der Benutzer sich authentifiziert hat und wer er als Ergebnis ist.

Wenn ein Client ein ID-Token erhält, konvertiert er es im Allgemeinen in eine ClaimsIdentity und behält dies bei, z. B. mithilfe eines Cookies.

Das ID-Token muss an diesem Verwendungsort nicht abgelaufen sein (was es sein sollte, da es gerade ausgestellt wurde). Danach wird es jedoch nicht mehr verwendet, sodass es keine Rolle spielt, ob es abläuft, während der Benutzer noch eine aktive Sitzung hat. Der Client verfügt über die erforderlichen Authentifizierungsinformationen und kann wiederum eine eigene Richtlinie für die Dauer der Sitzung auswählen, bevor sich der Benutzer erneut anmelden muss.

Meine falsche Annahme beim Stellen der Frage war, dass ein ID-Token und ein Zugriffstoken zusammen verwendet werden sollten und daher beide gültige Ablaufdaten haben mussten. Dies ist aus verschiedenen Gründen falsch:

• ID-Token dienen nur zur Authentifizierung bei einem Client (wie oben beschrieben).
• Zugriffstoken haben nichts mit Clients zu tun. Sie dienen dem Zugriff auf Ressourcen, und ein Client verarbeitet sie nur, wenn er wiederum eine Ressource aufrufen muss.
• So etwas wie eine eigenständige MVC- oder WebForms-Anwendung benötigt nur ein ID-Token. Wenn keine externe Ressource aufgerufen wird, gibt es nichts, auf das Zugriff gewährt werden kann, also kein Zugriffstoken.

Ich musste mich aus eigenen Gründen damit befassen und es aufschreiben, also werde ich hier posten, was ich gelernt habe ...

Zunächst beantworte ich die Frage mit dem Risiko, das Offensichtliche zu sagen: Dem ID-Token kann nicht vertraut werden, und sein Inhalt muss ignoriert werden, wenn die aktuelle Zeit größer als die abgelaufene Zeit ist. Die Antwort des Fragestellers besagt, dass das ID-Token nach der ersten Authentifizierung des Benutzers nicht mehr verwendet wird. Da das ID-Token jedoch vom Identitätsanbieter signiert ist , kann es durchaus jederzeit nützlich sein , anderen Diensten, die eine App möglicherweise verwendet, zuverlässig zu bestimmen, wer der Benutzer ist. Die Verwendung einer einfachen Benutzer-ID oder E-Mail-Adresse ist nicht zuverlässig da es leicht gefälscht werden kann (jeder kann eine E-Mail-Adresse oder Benutzer-ID senden), aber da ein OIDC-ID-Token vom Autorisierungsserver signiert ist (was normalerweise auch den Vorteil hat, ein Dritter zu sein), kann es nicht gefälscht werden und ist ein viel zuverlässigerer Authentifizierungsmechanismus.

Beispielsweise möchte eine mobile App möglicherweise einem Backend-Dienst mitteilen können, wer der Benutzer ist, der die App verwendet, und dies muss möglicherweise nach dem kurzen Zeitraum nach der Erstauthentifizierung erfolgen. Zu diesem Zeitpunkt ist das ID-Token abgelaufen. und kann daher nicht verwendet werden, um den Benutzer zuverlässig zu authentifizieren.

Können Sie daher genau wie das Zugriffstoken (das für die Autorisierung verwendet wird - Angabe der Berechtigungen des Benutzers) aktualisiert werden können, das ID-Token (für die Authentifizierung verwendet - Angabe, wer der Benutzer ist) aktualisieren ? Gemäß der OIDC-Spezifikation ist die Antwort nicht offensichtlich. In OIDC / OAuth gibt es drei "Flows" zum Abrufen von Token: den Authorization Code-Flow, den impliziten Flow und den Hybrid-Flow (den ich unten überspringen werde, da es sich um eine Variante der beiden anderen handelt).

Für den impliziten Ablauf in OIDC / OAuth fordern Sie das ID-Token am Autorisierungsendpunkt an, indem Sie den Benutzer im Browser zum Autorisierungsendpunkt umleiten und id_tokenals Wert des response_typeAnforderungsparameters angeben. Eine implizite Flow Successful Authentication-Antwort ist erforderlich, um die zu enthalten id_token.

Für den Authentifizierungscode-Fluss gibt der Client codeden Wert des response_typeAnforderungsparameters an, wenn der Benutzer zum Autorisierungsendpunkt umgeleitet wird. Eine erfolgreiche Antwort enthält einen Autorisierungscode. Der Client-Client sendet eine Anforderung an den Token-Endpunkt mit dem Autorisierungscode. Gemäß OIDC Core-Abschnitt 3.1.3.3 Erfolgreiche Token- Antwort MUSS die Antwort ein ID-Token enthalten .

Auf diese Weise erhalten Sie für beide Flows zunächst das ID-Token, aber wie aktualisieren Sie es? OIDC Abschnitt 12: Verwenden von Aktualisierungstoken enthält die folgende Anweisung zur Antwort auf Aktualisierungstoken :

Nach erfolgreicher Validierung des Aktualisierungstokens ist der Antworttext die Tokenantwort von Abschnitt 3.1.3.3, außer dass er möglicherweise kein id_token enthält .

Es enthält möglicherweise kein ID-Token. Da keine Möglichkeit angegeben ist, das ID-Token einzuschließen, müssen Sie davon ausgehen, dass die Antwort das ID-Token nicht enthält. Technisch gesehen gibt es also keine spezifizierte Möglichkeit, ein ID-Token mithilfe eines Aktualisierungstokens zu "aktualisieren". Daher besteht die einzige Möglichkeit, ein neues ID-Token zu erhalten, darin, den Benutzer erneut zu autorisieren / zu authentifizieren, indem der Benutzer zum Autorisierungsendpunkt umgeleitet und der implizite Fluss oder Authentifizierungscodefluss wie oben beschrieben gestartet wird. Die OIDC-Spezifikation fügt promptder Autorisierungsanforderung einen Anforderungsparameter hinzu, damit der Client anfordern kann, dass der Autorisierungsserver den Benutzer nicht mit einer Benutzeroberfläche auffordert, die Umleitung jedoch noch erfolgen muss.

Wenn ich das richtig verstehe, kann gemäß dieser und der OpenID Connect Core 1.0-Spezifikation das ID-Token selbst in Cookies als Mechanismus zum Fortbestehen von Sitzungen gespeichert und mit jeder authentifizierungspflichtigen Anforderung an den Client gesendet werden. Der Client kann das ID-Token dann entweder lokal oder über den Verifizierungsendpunkt des Anbieters überprüfen (falls bereitgestellt, wie dies bei Google der Fall ist ). Wenn das Token abgelaufen ist, sollte es eine weitere Authentifizierungsanforderung stellen, außer diesmal mit prompt=noneim URL-Parameter. Stellen Sie außerdem sicher, dass Sie das abgelaufene ID-Token im id_token_hintParameter senden , da der Anbieter sonst möglicherweise einen Fehler zurückgibt.

Es scheint also natürlich, dass das ID-Token abläuft, prompt=nonestellt jedoch sicher, dass das neue ID-Token ohne Benutzereingriff reibungslos abgerufen werden kann (es sei denn, der Benutzer ist natürlich von dieser OpenID abgemeldet).

Es ist die gleiche Absicht: Sie können das nicht verwenden, id_tokennachdem es abgelaufen ist. Der Hauptunterschied besteht darin, dass id_tokenes sich um eine Datenstruktur handelt und Sie keine Server oder Endpunkte aufrufen müssen, da die Informationen im Token selbst codiert sind. Ein reguläres access_tokenist normalerweise ein undurchsichtiges Artefakt (wie eine GUID).

Der Verbraucher des id_tokenmuss immer die (Zeit-) Gültigkeit überprüfen.

Ich bin nicht zu 100% mit IS vertraut, aber ich würde vermuten, dass es sich um ein Convenience-Feld handelt. Sie sollten den expAnspruch immer überprüfen .

Das Ablaufen ist nur eine der Validierungen. id_tokens sind auch digital signiert und das ist auch eine Validierung, die Sie durchführen müssen .

Das Aktualisieren eines Tokens bedeutet, dass Sie es erneut verwenden können, um etwas vom Autorisierungsserver anzufordern (in diesem Fall das OP - der OpenID-Connect-Anbieter), AUCH WENN DER BENUTZER NICHT ANGEMELDET IST. Sie erlauben dies normalerweise nur für begrenzte Ressourcen und erst, nachdem sich der Benutzer angemeldet und mindestens einmal authentifiziert hat. Die Aktualisierungstoken selbst sollten ebenfalls zeitlich begrenzt sein.

Im impliziten OIDC- Ablauf rufen Sie den Autorisierungsendpunkt auf
und erhalten das ID-Token in der Antwort zusammen mit allen Bereichen und darin alle Anspruchsinformationen.
Nachfolgende Aufrufe einer API sollen mit Codefluss erfolgen .
Der implizite Fluss soll eine App nur für Javascript oder nur für Browser aktivieren. Keine App, die mit einem Server interagiert.
Selbst wenn es eine Möglichkeit gab, dieses Token zu "aktualisieren", sollten Sie es aus Sicherheitsgründen nicht zu lange leben lassen. Es wird von nicht autorisierten Benutzern gestohlen und wiederverwendet, die sich als ID ausgeben. Sie sollten dafür ein neues Login erzwingen.

Im Code-Fluss rufen Sie den Autorisierungsendpunkt des OP auf und erhalten einen Autorisierungscode (auch als Autorisierungstoken oder kurz Authcode bezeichnet). Dies sollte ähnlich wie das id_token ablaufen, das Sie aus denselben Gründen im impliziten Ablauf erhalten haben, und kann und sollte nicht erneuert werden.

Ihre Benutzeroberfläche oder App ruft dann den Token-Endpunkt des OP auf und erhält (manchmal nach der weiteren Zustimmung des Benutzers über eine Benutzeroberfläche, die Verwendung seiner eigenen Ressourcen auf dem OP-Server zu ermöglichen) beide:

• Ein id_token zur Authentifizierung, das bei Serveraufrufen nie wieder verwendet werden sollte, außer als Hinweis während der Abmeldung, wenn sein Ablauf nicht mehr wichtig ist. Aus den oben genannten Gründen sollte es daher ablaufen und niemals aktualisiert werden.
• Ein access_token, das später beim Aufrufen einer API an den UserInfo-Endpunkt des OP übergeben werden kann. Dadurch werden die Ansprüche zurückgegeben, und die API kann entsprechend autorisieren.

Sie können dieses access_token aktualisieren, da es der API nur mitteilt, welche Ansprüche der Benutzer hat und welche Ressourcen (nach Bereichen und Ansprüchen der einzelnen Bereiche) der Benutzer Ihnen zugestimmt hat. Wie oben erläutert, dient dies dazu, den Zugriff auch dann zu ermöglichen, wenn der Benutzer nicht mehr angemeldet ist. Natürlich möchten Sie niemals zulassen, dass das id_token aktualisiert wird, da Sie keinen Identitätswechsel zulassen möchten, ohne sich anzumelden.

TLDR;

Überprüfen Sie das ID-Token, bevor Sie den darin enthaltenen Informationen vertrauen.

Mehr Details

Was ist die Absicht der Ablaufzeit des ID-Tokens in OpenID Connect?

Der Client soll das ID-Token validieren können, und der Client muss das ID-Token vor Vorgängen validieren, bei denen die Informationen des ID-Tokens verwendet werden .

Aus der OpenID Implicit Flow-Spezifikation :

Wenn eines der in diesem Dokument definierten Validierungsverfahren fehlschlägt, MÜSSEN alle Vorgänge abgebrochen werden, bei denen die Informationen nicht korrekt validiert werden müssen, und die Informationen, die nicht validiert werden konnten, dürfen NICHT verwendet werden.

Um dies zu bestätigen, wird in der OpenID Connect-Dokumentation von Google Folgendes zur Validierung von ID-Token angegeben:

Eine Sache, die ID-Token nützlich macht, ist die Tatsache, dass Sie sie an verschiedene Komponenten Ihrer App weitergeben können. Diese Komponenten können ein ID-Token als einfachen Authentifizierungsmechanismus verwenden, der die App und den Benutzer authentifiziert. Bevor Sie jedoch die Informationen im ID-Token verwenden oder sich darauf verlassen können, dass der Benutzer sich authentifiziert hat, müssen Sie sie validieren.

Wenn unsere Clientanwendung basierend auf dem Inhalt des ID-Tokens eine Aktion ausführen soll, müssen wir das ID-Token erneut validieren.

Ich wollte diese Antwort als Kommentar veröffentlichen, aber da ich bei StackOverflow nicht sehr aktiv war, werde ich sie wahrscheinlich als alternative Antwort veröffentlichen.

Sie verwenden auch id_tokenals das , id_token_hintwenn der Benutzer aus einer Sitzung anmelden versuchen http://openid.net/specs/openid-connect-session-1_0.html . Ich glaube ehrlich gesagt nicht, dass es wirklich wichtig ist, wenn das id_tokenzu diesem Zeitpunkt abgelaufen ist, da Sie sich nur darum kümmern, einen bestimmten Benutzer abzumelden.