Cześć,
czy może mi ktoś wyjaśnić w jakim celu wypełnia się a następnie weryfikuje pola w JWT: ValidIssuer oraz ValidAudience?
Nie bardzo rozumiem ich ideę. Jeśli token jest podpisywany to jaki jest jeszcze sens weryfikować, czy jest zgodność z iss oraz aud?
Z góry dziękuję za informacje.
1
0
@AdamWox widziałem ten wątek, ale tam nie pada odpowiedź.
1
The "iss" (issuer) claim identifies the principal that issued the
JWT. The processing of this claim is generally application specific.
The "iss" value is a case-sensitive string containing a StringOrURI
value. Use of this claim is OPTIONAL.
The "aud" (audience) claim identifies the recipients that the JWT is
intended for. Each principal intended to process the JWT MUST
identify itself with a value in the audience claim. If the principal
processing the claim does not identify itself with a value in the
"aud" claim when this claim is present, then the JWT MUST be
rejected. In the general case, the "aud" value is an array of case-
sensitive strings, each containing a StringOrURI value. In the
special case when the JWT has one audience, the "aud" value MAY be a
single case-sensitive string containing a StringOrURI value. The
interpretation of audience values is generally application specific.
Use of this claim is OPTIONAL.
Wydaje mi się że z jednej strony tak na wszelki wypadek, a z drugiej strony np. inna aplikacja może znać twój secret, aby być w stanie wygenerować poprawny jwt, który twoja aplikacja obsłuży i wtedy ona będzie issuerem, a w dodatku może doprecyzować kto powinien tego użyć.
0
Dzięki, chociaż ciągle mam strasznie mieszane uczucie czy i kiedy jest sens z tego korzystać.
Jeszcze przechowywanie samej informację np. o wystawcy nie jest niczym złym, ale nie rozumiem po co jest opcja (i czemu na większości tutoriali jest ona włączona) na dodatkowe weryfikowanie tych danych? Jak JWT jest prawidłowo podpisany to sam mogę sobie wydobyć informację o wystawcy i wykonać odpowiednie działania.
3
W normalnej implementacji OAuth2 te claimy mają sens.
Z kolei jak masz JWT tylko do API wystawionego na potrzeby frontu to rzeczywiście może to nic nie wnosić.
Na przykładzie Azure AD.
Token:
Header:
{
"typ": "JWT",
"nonce": "bY6iDDY5FPcBxdXD5y2Soi-FzxG8QbfkuBqakMBW9zM",
"alg": "RS256",
"x5t": "l3sQ-50cCH4xBVZLHTGwnSR7680",
"kid": "l3sQ-50cCH4xBVZLHTGwnSR7680"
}
Payload:
{
"aud": "00000003-0000-0000-c000-000000000000",
"iss": "https://sts.windows.net/00000000-3232-466e-0000-1a60c19a89ee/",
"iat": 1636587936,
"nbf": 1636587936,
"exp": 1636592593,
"amr": [
"pwd"
],
"scp": "User.Read profile openid email",
[...]
}
Tokeny podpisywane są asymetrycznie przez Azure AD (podejrzewam, że większość dostawców podpisuje właśnie przez RSA, a nie HMAC).
Tutaj w headerze widać, że token podpisany został przez klucz o identyfikatorze l3sQ-50cCH4xBVZLHTGwnSR7680. Jak stworzysz nową aplikację w Azure AD, albo nawet ktoś w zupełnie oddzielnym katalogu stworzy aplikację, to dalej istnieje duże prawdopodobieństwo, że token będzie podpisany przez Azure AD tym samym kluczem. Więc sama walidacja podpisu nic nie da, bo co z tego, że token był wystawiony przez Azure AD, jak mógł być wystawiony do zupełnie innej aplikacji niż twoja?
Klucze asymetryczne, którymi Azure AD podpisuje tokeny można znaleźć tutaj: https://login.microsoftonline.com/common/discovery/v2.0/keys
W przypadku Azure AD claim iss zawiera informację o katalogu użytkownika dla którego wygenerowany został token. Możesz ten claim wykorzystać do ograniczenia (po stronie swojego kodu), katalogów (tenantów) AAD, z których chcesz żeby użytkownicy mieli możliwość logowania się.
Claim aud to z kolei identyfikator aplikacji, dla której wystawiony został token. W przykładzie wyżej 00000003-0000-0000-c000-000000000000, czyli Microsoft Graph. To musi sprawdzać serwis przyjmujący token. Za pomocą tego tokenu nie mam możliwości odpytywania innych serwisów MS, np. bezpośrednio API Sharepointa czy management.azure.com.
0
@some_ONE dziękuję za wyjaśnienie.