W OpenID Connect token dostępu ma czas ważności. W przypadku przepływu kodu autoryzacyjnego jest to zwykle krótkie (np. 20 minut), po czym należy użyć tokena odświeżania, aby zażądać nowego tokena dostępu.

ID tokena również ma czas ważności. Moje pytanie brzmi: jaki jest tego cel?

Dowolny czas wygaśnięcia tokena identyfikatora krótszy niż czas wygaśnięcia tokena odświeżania będzie oznaczać, że w końcu będziesz mieć wygasły token identyfikatora, ale ważny token dostępu.

Więc masz zamiar:

• nadaj swojemu tokenowi ID wygaśnięcie dłuższe niż wygaśnięcie tokenu odświeżania lub
• ustaw go na taki sam termin ważności jak token dostępu i podejmij jakąś akcję (co?), gdy wygaśnie lub
• po prostu zużyj token ID w swoim kliencie przy odbiorze, a następnie zignoruj ​​czas wygaśnięcia po tym?

Specyfikacja OpenID Connect mówi tylko, że podczas walidacji tokenu identyfikatora

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

który (prawdopodobnie) obsługuje trzecią opcję powyżej.

EDYTOWAĆ

Ponieważ OpenID Connect opiera się na OAuth2, odpowiedź na dodatkowe pytanie poniżej można znaleźć w specyfikacji OAuth2, która mówi:

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

Powiązane pytanie brzmi: kiedy wymieniasz kod autoryzacyjny na tokeny, ta sama specyfikacja mówi, że możesz otrzymać odpowiedź, taką jak:

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

Ale do czego odnosi się „expires_in” w tym przypadku? Token dostępu, token odświeżania czy token ID?

(Aby uzyskać informacje, IdentityServer3 ustawia to na czas wygaśnięcia tokenu dostępu).

Odpowiadam na własne pytanie, ponieważ odkryłem, że niektóre z założeń stojących za moim pytaniem były błędne, więc łatwiej je tutaj wyjaśnić, niż ponownie napisać pytanie.

Token ID służy do udowodnienia Klientowi, że użytkownik jest uwierzytelniony i kim jest w rezultacie.

Kiedy Klient otrzyma token ID, zwykle robi coś takiego, jak konwertowanie go na ClaimsIdentity i utrwalanie tego, np. Przy użyciu pliku cookie.

Token ID musi stracić ważność w tym momencie użytkowania (co powinno być, ponieważ właśnie został wydany). Ale po tym nie jest ponownie używany, więc nie ma znaczenia, czy wygaśnie, gdy użytkownik nadal ma aktywną sesję. Klient ma potrzebne informacje uwierzytelniające i może z kolei wybrać własną politykę dotyczącą czasu trwania sesji, zanim użytkownik będzie musiał się ponownie zalogować.

Zadając to pytanie, założyłem błędnie, że token identyfikacyjny i token dostępu powinny być używane razem, a zatem oba muszą mieć ważne daty ważności. Jest to złe z różnych powodów:

• Tokeny ID służą wyłącznie do uwierzytelniania klienta (jak opisano powyżej).
• Tokeny dostępu nie mają nic wspólnego z Klientami. Służą one do dostępu do zasobów, a Klient obsługuje je tylko wtedy, gdy z kolei musi wywołać zasób.
• Coś w rodzaju samodzielnej aplikacji MVC lub WebForms wymaga tylko tokena identyfikatora. Jeśli nie wywołuje zasobu zewnętrznego, nie ma do czego udzielić dostępu, więc nie ma tokenu dostępu.

Musiałem się w to zagłębić z własnych powodów i napisałem, więc opublikuję tutaj, czego się nauczyłem ...

Najpierw odpowiem na pytanie, ryzykując stwierdzenie oczywistego: tokenowi ID nie można ufać, a jego zawartość należy zignorować, jeśli aktualny czas jest dłuższy niż czas, który upłynął. W odpowiedzi pytającego stwierdza się, że po wstępnym uwierzytelnieniu użytkownika token ID nie jest ponownie używany. Ponieważ jednak token identyfikatora jest podpisany przez dostawcę tożsamości, z pewnością przydatne w dowolnym momencie może być udostępnienie sposobu niezawodnego określenia, kim jest użytkownik, do innych usług, z których może korzystać aplikacja. Używanie prostego identyfikatora użytkownika lub adresu e-mail nie jest niezawodne ponieważ można go łatwo sfałszować (każdy może wysłać adres e-mail lub identyfikator użytkownika), ale ponieważ token OIDC ID jest podpisany przez serwer autoryzacji (który zwykle ma również tę zaletę, że jest stroną trzecią), nie można go sfałszować i jest znacznie bardziej niezawodny mechanizm uwierzytelniania.

Na przykład aplikacja mobilna może chcieć móc powiedzieć usłudze wewnętrznej bazy danych, kim jest użytkownik, który korzysta z aplikacji, i może to zrobić po krótkim okresie po początkowym uwierzytelnieniu, w którym to momencie wygasł identyfikator tokenu, w związku z tym nie może służyć do wiarygodnego uwierzytelnienia użytkownika.

Dlatego tak jak token dostępu (służący do autoryzacji - określając jakie uprawnienia posiada użytkownik) można odświeżyć, czy można odświeżyć ID Token (służący do uwierzytelniania - określając, kim jest użytkownik)? Zgodnie ze specyfikacją OIDC odpowiedź nie jest oczywista. W OIDC / OAuth istnieją trzy „przepływy” do pobierania tokenów, przepływ kodu autoryzacji, przepływ niejawny i przepływ hybrydowy (które pominę poniżej, ponieważ jest to wariant dwóch pozostałych).

W przypadku niejawnego przepływu w OIDC / OAuth żądasz tokenu identyfikatora w punkcie końcowym autoryzacji, przekierowując użytkownika w przeglądarce do punktu końcowego autoryzacji i dołączającid_token jako wartość response_typeparametru żądania. Niejawny Przepływ pomyślnym uwierzytelnieniu Response jest zobowiązany do obejmują id_token.

W przypadku przepływu kodu uwierzytelniania klient określa codejako wartość response_typeparametru żądania podczas przekierowywania użytkownika do punktu końcowego autoryzacji. Pomyślna odpowiedź zawiera kod autoryzacji. Klient wysyła żądanie do punktu końcowego tokena z kodem autoryzacyjnym i, zgodnie z OIDC Core Section 3.1.3.3 Successful Token Response, odpowiedź MUSI zawierać ID Token .

Tak więc w przypadku obu przepływów początkowo otrzymujesz token identyfikatora, ale jak go odświeżyć? Rozdział 12 OIDC: Używanie tokenów odświeżania zawiera następującą instrukcję dotyczącą odpowiedzi tokenu odświeżania:

Po pomyślnym sprawdzeniu poprawności tokenu odświeżania treść odpowiedzi jest odpowiedzią tokenu z sekcji 3.1.3.3, z tą różnicą, że może nie zawierać tokenu id_token .

To nie może zawierać identyfikator token, a ponieważ nie ma sposobu, aby zmusić go określono zawierać znacznik ID, należy założyć, że odpowiedź nie będzie zawierać identyfikator token. Z technicznego punktu widzenia nie ma więc określonego sposobu „odświeżenia” tokena identyfikatora za pomocą tokena odświeżania. Dlatego jedynym sposobem uzyskania nowego tokena identyfikatora jest ponowna autoryzacja / uwierzytelnienie użytkownika przez przekierowanie użytkownika do punktu końcowego autoryzacji i uruchomienie niejawnego przepływu lub przepływu kodu uwierzytelniającego, jak opisano powyżej. Specyfikacja OIDC dodaje promptparametr żądania do żądania autoryzacji, więc klient może zażądać, aby serwer autoryzacji nie monitował użytkownika za pomocą żadnego interfejsu użytkownika, ale przekierowanie nadal musi nastąpić.

Jeśli dobrze rozumiem, zgodnie z tym i specyfikacją OpenID Connect Core 1.0 , sam token ID może być przechowywany w plikach cookie jako mechanizm utrwalania sesji i wysyłany z każdym żądaniem uwierzytelniania do Klienta. Klient może następnie zweryfikować token identyfikatora lokalnie lub za pośrednictwem punktu końcowego weryfikatora dostawcy (jeśli jest dostępny, tak jak robi to Google ). Jeśli token stracił ważność, powinien wysłać kolejne żądanie uwierzytelnienia, z wyjątkiem tego czasu z prompt=noneparametrem adresu URL. Upewnij się również, że w id_token_hintparametrze wysłano wygasły token identyfikatora , w przeciwnym razie dostawca może zwrócić błąd.

Tak więc wygaśnięcie prompt=nonetokena ID wydaje się naturalne, ale zapewnia, że ​​nowy token ID można uzyskać płynnie bez interwencji użytkownika (chyba że użytkownik zostanie wylogowany z tego OpenID).

To ten sam cel: nie możesz użyć id_tokenpo wygaśnięciu. Główną różnicą jest to, że id_tokenjest strukturą danych i nie musisz wywoływać żadnych serwerów ani punktów końcowych, ponieważ informacje są zakodowane w samym tokenie. Zwykły access_tokenjest zwykle nieprzezroczystym artefaktem (takim jak identyfikator GUID).

Konsument id_tokenmusi zawsze zweryfikować (czas) jej ważność.

Nie jestem w 100% zaznajomiony z IS, ale myślę, że to wygoda. Zawsze powinieneś sprawdzić expreklamację.

Wygaśnięcie to tylko jedna z walidacji. id_tokensą również podpisane cyfrowo i jest to również weryfikacja, którą należy przeprowadzić.

Odświeżenie tokena oznacza, że ​​można go ponownie użyć do zażądania czegoś od serwera autoryzacyjnego (w tym przypadku OP - dostawcy OpenID-Connect) NAWET GDY UŻYTKOWNIK NIE JEST ZALOGOWANY. Zwykle zezwalasz na to tylko w przypadku ograniczonych zasobów i tylko wtedy, gdy użytkownik zaloguje się i zostanie uwierzytelniony co najmniej raz. Same tokeny odświeżania również powinny być ograniczone w czasie.

W przepływie niejawnym OIDC wywołujesz punkt końcowy autoryzacji
i otrzymujesz token identyfikatora w odpowiedzi wraz ze wszystkimi zakresami i wszystkimi informacjami o oświadczeniach.
Kolejne wywołania interfejsu API mają być wykonywane za pomocą przepływu kodu .
Niejawny przepływ ma na celu włączenie aplikacji tylko javascript lub tylko przeglądarki. Nie jest to aplikacja, która wchodzi w interakcję z serwerem.
Więc nawet jeśli istniał sposób na „odświeżenie” tego tokena, nie należy - ze względów bezpieczeństwa - pozwolić mu żyć zbyt długo. Zostanie skradziony i ponownie wykorzystany przez nieautoryzowanych użytkowników podszywających się pod ten identyfikator. W tym celu należy wymusić nowy login.

W przepływie kodu wywołujesz punkt końcowy autoryzacji OP i otrzymujesz kod autoryzacji (zwany również tokenem autoryzacyjnym lub w skrócie authcode). Powinno to wygasnąć podobnie jak id_token, który otrzymałeś w niejawnym przepływie, z tych samych powodów i nie może i nie powinien być odnawiany.

Twój interfejs użytkownika lub aplikacja następnie wywołuje punkt końcowy tokenu OP i odbiera (czasami po dalszej zgodzie użytkownika za pośrednictwem interfejsu użytkownika, aby zezwolić na korzystanie z posiadanych zasobów na serwerze OP):

• Identyfikator id_token do uwierzytelniania - którego nigdy nie należy używać ponownie w wywołaniach serwera, chyba że jako podpowiedź przy wylogowywaniu się, gdy jego wygaśnięcie nie jest już ważne, dlatego z powyższych powodów należy pozwolić na wygaśnięcie i nigdy go nie odświeżać.
• Access_token - który później, podczas wywoływania API, można przekazać do punktu końcowego UserInfo OP. Spowoduje to zwrócenie oświadczeń, a interfejs API może odpowiednio autoryzować.

Możesz odświeżyć ten access_token, ponieważ informuje on tylko API, jakie roszczenia ma użytkownik i jakie zasoby (według zakresów i żądań każdego zakresu) zgodził się udostępnić. Jak wyjaśniono powyżej, służy to umożliwieniu dostępu nawet wtedy, gdy użytkownik nie jest już zalogowany. Oczywiście nigdy nie chcesz pozwolić na odświeżenie id_token, ponieważ nie chcesz zezwalać na podszywanie się bez logowania.

Chciałem opublikować tę odpowiedź jako komentarz, ale ponieważ nie byłem zbyt aktywny w StackOverflow, wydaje mi się, że publikuję ją jako alternatywną odpowiedź.

Używasz również id_tokenjako http://openid.net/specs/openid-connect-session-1_0.htmlid_token_hint próbując wylogować użytkownika z sesji . Szczerze mówiąc, nie sądzę, aby to naprawdę miało znaczenie, jeśli w tym momencie wygasła, ponieważ martwisz się tylko wylogowaniem określonego użytkownika.id_token

TLDR;

Sprawdź poprawność tokenu ID, zanim zaufasz temu, co mówi.

Więcej szczegółów

Jaki jest cel czasu wygaśnięcia tokenu identyfikatora w OpenID Connect?

Celem jest umożliwienie klientowi walidacji tokenu identyfikatora, a klient musi zweryfikować token identyfikatora przed operacjami, które wykorzystują informacje tokena identyfikatora .

Ze specyfikacji niejawnego przepływu OpenID :

Jeśli którakolwiek z procedur walidacji określonych w tym dokumencie zakończy się niepowodzeniem, wszelkie operacje wymagające informacji, których walidacja nie powiodła się, MUSZĄ zostać przerwane, a informacje, których walidacja się nie powiodła, NIE WOLNO używać.

Aby to potwierdzić, dokumentacja Google OpenID Connect mówi o weryfikacji tokenu identyfikacyjnego:

Jedną z rzeczy, które sprawiają, że tokeny identyfikacyjne są przydatne, jest fakt, że można je przekazywać między różnymi składnikami aplikacji. Te składniki mogą używać tokenu identyfikatora jako lekkiego mechanizmu uwierzytelniania uwierzytelniającego aplikację i użytkownika. Ale zanim będziesz mógł użyć informacji w tokenie identyfikatora lub polegać na nich jako na potwierdzeniu, że użytkownik został uwierzytelniony, musisz je zweryfikować.

Tak więc, jeśli nasza aplikacja kliencka ma wykonać jakąś akcję w oparciu o zawartość tokena ID, musimy ponownie zweryfikować token ID.