Was ist die ID-Token-Ablaufzeit in OpenID Connect?

In OpenID Connect eine access token hat eine Verfallszeit. Für authorization code flow, das ist in der Regel kurz (z.B. 20 Minuten) an, nach dem der refresh-token für die Anforderung eines neuen Zugangs-token.

Den ID-token hat auch eine Ablaufzeit. Meine Frage ist, was ist die Absicht?

Keine ID-token Ablauf der Zeit weniger als dem Ablauf der refresh-token wird bedeuten, dass Sie letztendlich haben wird, die eine abgelaufene ID-token, aber einen gültigen access-token.

Damit sind Sie gemeint:

geben Sie Ihre ID-token ein Ablaufdatum länger als die refresh-token Ablauf, oder
einstellen, dass es der gleiche Ablauf wie für den access token und einige Maßnahmen ergreifen (welche?) wenn es abläuft, oder
konsumieren, der ID-token in Ihren client auf Empfang, dann ignorieren Sie den Ablauf der Zeit danach?

Den OpenID Connect-Spezifikationen sagt nur, dass bei der Validierung ein ID-token,

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

welche (möglicherweise) unterstützt die Dritte option von oben.

BEARBEITEN

Als OpenID Connect baut auf OAuth2 die Antwort auf die Zusatzfrage unten finden Sie in der OAuth2-Spezifikationdie sagt,

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

Eine Verwandte Frage ist, wenn Sie exchange einen auth-code für die Token, die gleiche Spezifikation sagt, dass Sie eine Antwort erhalten wie:

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

Aber was bedeutet "expires_in" beziehen sich in diesem Fall? Das access-token, die refresh-token oder der ID-token?

(Informationen, IdentityServer3 setzt dies auf der Zugangs-token Ablauf der Zeit).

InformationsquelleAutor der Frage Appetere | 2014-09-05

oauth-2.0 openid-connect

55

Bin ich die Beantwortung meiner eigenen Frage haben entdeckt, dass einige der Annahmen, die hinter meiner Frage waren falsch, so leichter zu klären ist hier, vielmehr als eine re-schreiben die Frage.

Einem ID-token bestimmt ist, erweist sich ein Client, der die Benutzer authentifiziert hat, und wer Sie als Ergebnis.

Wenn ein Client erhält eine ID-token, wird es in der Regel etwas wie das konvertieren es zu einem "ClaimsIdentity", und speichern Sie diese, z.B. mit einem cookie.

Dem ID-token werden un-abgelaufen, an dieser Stelle zu verwenden (was es sein sollte, da es hat nur wurde ausgestellt). Aber danach ist es nicht wieder verwendet, so es spielt keine Rolle, wenn es abläuftwährend der Benutzer hat immer noch eine aktive Sitzung. Hat der Client die Authentifizierung Informationen, die es braucht, und im Gegenzug können wählen, Ihre eigene Politik, wie lange die Sitzung dauert, bevor der Benutzer erneut einloggen.

Meine falsche Annahme, wenn die Frage war, dass ein ID-token und access token sollten zusammen verwendet werden, und daher beide benötigt, um gültige Verfallsdatum. Das ist falsch aus verschiedenen Gründen:
- ID-Token sind nur für die Authentifizierung ein Client (wie oben beschrieben).
- Access Token haben nichts zu tun mit den Kunden. Sie sind für den Zugang zu Ressourcen und ein Client nur behandelt werden, wenn es wiederum braucht, um eine Ressource.
- So etwas wie ein eigenständiges MVC oder WebForms Anwendung nur benötigt eine ID-token. Wenn es nicht der Aufruf einer externen Ressource, es gibt nichts, um Zugriff zu gewähren, also keine access-token.
InformationsquelleAutor der Antwort Appetere
23

Ich hatte zu Graben, in diesem für meine eigenen Gründe, und schrieb es auf, so werde ich nach, was ich hier gelernt...

Werde ich zunächst die Frage beantworten, auf die Gefahr, banal: Der ID-token kann nicht vertrauenswürdig sein und Ihre Inhalte müssen ignoriert werden, wenn die aktuelle Zeit größer ist als die abgelaufene Zeit. Die Fragesteller die Antwort besagt, dass die nach der ersten Authentifizierung des Nutzers, der ID-Token nicht mehr verwendet wird. Jedoch, seit dem ID-Token ist unterzeichnet durch den identity-provider, es kann sicherlich sein nützlich zu jeder Zeit zu geben, eine Möglichkeit zuverlässig, festzustellen, wer der Anwender ist, um andere Dienste, die eine app verwenden könnten. Mit einem einfachen Benutzer-ID oder E-Mail-Adresse ist nicht zuverlässigeweil es problemlos manipuliert werden können (jeder kann senden Sie eine E-Mail-Adresse oder Benutzer-ID), aber seit ein OIDC ID-Token ist unterzeichnet von den Authorization server (die auch in der Regel den Vorteil, dass eine Dritte Partei), kann es nicht gefälscht werden und ist wesentlich zuverlässiger Authentifizierungsmechanismus.

Beispielsweise eine mobile app kann in der Lage sein möchten zu sagen, eine back-End-Dienst die der Benutzer ist, der mit dem app und kann es tun müssen, so nach dem kurzen Zeitraum nach der anfänglichen Authentifizierung, welche gleichzeitig das ID-Token ist abgelaufen, und somit nicht zuverlässig verwendet werden, um den Benutzer zu authentifizieren.

Daher, genau wie das access-token (für die Autorisierung verwendet - die Angabe welche Berechtigungen der Benutzer hat) aktualisiert werden kann, können Sie aktualisieren Sie den ID-Token (für die Authentifizierung verwendet wird - die Angabe die der Benutzer)? Nach der OIDC Spezifikation, die Antwort ist nicht offensichtlich. In OIDC/OAuth gibt es drei "flows" für das erste Token, Der Authorization Code flow, der Implizite Datenfluss, und die Hybrid-flow (die werde ich überspringen unten, weil es eine Variante von den anderen beiden).

Für die implizite flow in OIDC/OAuth verlangen Sie die ID-Token an den authorization-Endpunkt durch Umleitung der Nutzer in den browser, um den Autorisierungs-Endpunkt und darunter id_token als der Wert der response_type request-parameter. Ein Implizite Flow Erfolgreichen Authentifizierung Antwort muss folgende Angaben enthalten:id_token.

Für die Authentifizierung von Code flowder client gibt code als der Wert der response_type request-parameter umleiten, wenn der Benutzer die Autorisierungs-Endpunkt. Eine erfolgreiche Antwort enthält einen Autorisierungs-code. Der client macht eine Anfrage an das token-Endpunkt mit den Authorisierungs-code, und nach OIDC Core Abschnitt 3.1.3.3 Erfolgreiche Token Response die Antwort MUSS ein ID-Token.

Also entweder fließen, so erhalten Sie zunächst den ID-Token, aber wie wollen Sie es aktualisieren? OIDC Abschnitt 12: Verwendung von Refresh Token hat die folgende Aussage über die Refresh-Token Response:

Nach erfolgreicher Validierung der Refresh-Token, die Reaktion im Körper ist, der Token-Antwort von Abschnitt 3.1.3.3 der Ausnahme, dass es möglicherweise nicht enthalten eine id_token.

Es vielleicht nicht enthalten einen ID-Token und da gibt es keine Weise angegeben werden, um die Kraft der ID-token, müssen Sie davon ausgehen, dass die Antwort nicht enthalten, die den ID-Token. Also technisch gibt es keine festgelegten Art und Weise zu "aktualisieren", einen ID-Token mit einem refresh token. Daher der einzige Weg, um eine neue ID-Token ist die re-Autorisierung/Authentifizierung des Benutzers durch umleiten der Benutzer die Autorisierungs-Endpunkt und starten die implizite flow oder authentication code flow wie oben beschrieben. Die OIDC-Spezifikation fügt einen prompt Anfrage-parameter die Authorisierungs-Anfrageso kann der Kunde Anfragedass der authorization server fordert den Benutzer mit einem UI, sondern das die Umleitung noch zu geschehen hat.

InformationsquelleAutor der Antwort Scott Willeke
4

Es ist die gleiche Absicht: Sie können nicht die id_token nachdem es abgelaufen ist. Der Hauptunterschied ist, dass eine id_token ist eine Daten-Struktur und Sie brauchen sich nicht zu nennen, alle Server oder Endgeräte, wie die information kodiert ist, die in das token selbst. Eine regelmäßige access_token ist in der Regel eine undurchsichtige Artefakt (wie eine GUID).

Den Verbraucher von der id_token müssen immer überprüfen, die (Zeit -) Gültigkeit.

Bin ich mir nicht 100% vertraut IST, aber ich würde vermuten es ist ein convenience-Bereich. Sie sollten immer überprüfen die exp Anspruch.

Ablauf ist nur eine der Validierungen. id_tokens sind auch Digital signiert ist und das ist auch eine Validierung, die Sie muss durchführen.

InformationsquelleAutor der Antwort Eugenio Pace
4

Erfrischend ein token bedeutet, dass Sie es wieder verwenden können für die Beantragung etwas aus der Autorisierungs-server (in diesem Fall der OP - das OpenID-Connect-Provider), AUCH WENN DER BENUTZER NICHT EINGELOGGT IST. Sie in der Regel erlauben dies für die begrenzten Ressourcen, und nur, nachdem der Benutzer sich angemeldet hat und authentifiziert wurde, mindestens einmal. Der refresh-Token selbst sollte auch zeitlich begrenzt.

In OIDC implizite flow rufen Sie den Autorisierungs-Endpunkt

und Sie erhalten den ID-token in der Antwort zusammen mit alle Bereiche und in Ihnen alle Ansprüche info.

Nachfolgende Aufrufe an eine API-gemeint sind, zu tun, mit code flow.

Implizite flow gemeint ist, aktivieren Sie javascript oder nur browser-only-app. Nicht eine app, ist eine Interaktion mit einem server.

Also selbst wenn es einen Weg gibt, um "refresh" dieses token, sollten Sie nicht - Sicherheit Weise - lassen Sie es zu lange Leben. Es wird gestohlen und wiederverwendet, indem nicht autorisierte Benutzer die Identität des id. Sie zwingen sollte, eine neue Anmeldung.

In code flow rufen Sie die OP ' s Authorization-Endpunkt, und erhalten eine Autorisierungs-code (auch als Autorisierungs-token, oder authcode für kurz). Sollte diese ablaufen, ähnlich wie die id_token, die Sie erhalten, im impliziten flow, aus den gleichen Gründen, und kann und sollte nicht verlängert werden.

Ihre Benutzeroberfläche oder in der app rufen Sie dann die OP-Token-Endpunkt, und erhält (manchmal, nachdem der Benutzer weitere Zustimmung über eine Benutzeroberfläche zu ermöglichen, nutzen Ihre eigenen Ressourcen auf dem OP-server) beide:
- Eine id_token, für die Authentifizierung - das sollte nie wieder verwendet werden, die im server-Anrufe, außer als Hinweis bei Abmeldung, wenn Ihr Ablauf ist nicht mehr wichtig, und so, für die Gründe oben gelassen werden sollte, verfallen, und nie aktualisiert werden.
- Ein access_token -, die später beim Aufruf einer API, gegeben werden kann, um die OP UserInfo Endpunkt. Das wird die Rückkehr der Forderungen und der API autorisieren können entsprechend.
Können Sie aktualisieren diese access_token, denn es erzählt nur die API, welche Ansprüche der Anwender hat, und welche Ressourcen (durch Bereiche und für jeden Bereich die Ansprüche) der Benutzer einverstanden, Sie zu geben. Wie oben erklärt, ist dies für den Zugriff, wenn der Benutzer nicht eingeloggt ist, nicht mehr. Natürlich werden Sie nie wollen, zu ermöglichen, die id_token aktualisiert werden, weil Sie nicht zulassen möchten, dass der Identitätswechsel ohne Anmeldung.

InformationsquelleAutor der Antwort pashute
3

Ich wollte nach dieser Antwort als Kommentar, aber da habe ich nicht sehr aktiv auf StackOverflow, ich denke, ich bin Entsendung es als eine Alternative Antwort.

Nutzen Sie auch id_token als id_token_hint beim Versuch, sich der Benutzer von einer Sitzung http://openid.net/specs/openid-connect-session-1_0.html. Ganz ehrlich, ich glaube nicht, dass es wirklich wichtig ist, wenn die id_token abgelaufen ist an dieser Stelle, da Sie nur besorgt über das Abmelden eines bestimmten Benutzers.

InformationsquelleAutor der Antwort dgonee
3

Wenn ich das richtig verstehe, nach diese und die OpenID Connect-Core 1.0 specden ID-token selbst gespeichert in cookies als ein Mechanismus zum anhalten Sitzungen, und schickte bei jeder Authentifizierung verlangen-Anfrage an den Client. Dann kann der Client überprüfen Sie den ID-token entweder lokal oder über den Anbieter verifier Endpunkt (falls vorhanden, wie Google funktioniert). Wenn der token abgelaufen ist, sollte es eine andere auth-request, außer diese Zeit mit prompt=none im URL-parameter. Auch stellen Sie sicher, senden Sie die abgelaufene ID-token in der id_token_hint parameter, sonst kann der Anbieter einen Fehler zurück.

So, es scheint natürlich für den ID-Token verfallen, aber prompt=none sorgt das neue ID-token abgerufen werden kann glatt, ohne eingreifen des Benutzers (außer natürlich, der Benutzer ist abgemeldet, OpenID).

InformationsquelleAutor der Antwort Morrowless
3

TLDR;

Validieren der ID-token vor dem zu Vertrauen, was er sagt.

Mehr Details

Was ist die Absicht von ID-token Ablauf der Zeit in OpenID Connect?

Die Absicht ist es, dem client zu validieren, die den ID-token, und der client muss validieren der ID-token vor Operationen, die mit dem ID-token, die Informationen.

Vom die OpenID Implizite Flow-spec:

Wenn einer der Validierung von Verfahren in diesem Dokument definiert fehl, alle Operationen die die Informationen, die nicht korrekt überprüft werden MUSS, abgebrochen und die Informationen, die nicht überprüft werden konnte, DÜRFEN NICHT verwendet werden.

Zu bekräftigen, dass Google OpenID Connect Dokumentation sagt über ID-token-Validierung:

Eine Sache, die macht das ID-Token sinnvoll ist, die Tatsache, dass Sie passieren können Sie rund um die verschiedenen Komponenten Ihrer app. Diese Komponenten können über ein ID-token, wie ein leichtes Authentifizierungsmechanismus die Authentifizierung der app und dem Nutzer. Aber bevor Sie die Informationen verwenden, die in dem ID-token, oder sich auf es als eine Behauptung, dass sich der Benutzer authentifiziert hat, müssen Sie Sie überprüfen.

So, wenn unsere client-Anwendung ist, gehen einige Maßnahmen zu ergreifen, basierend auf dem Inhalt des ID-token, dann müssen wir Sie erneut überprüfen Sie den ID-token.

InformationsquelleAutor der Antwort Shaun Luttin

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.

TLDR;

Mehr Details