audRoszczenie dotyczące JWT (odbiorców)
Zgodnie z RFC 7519 :
Oświadczenie „aud” (publiczność) identyfikuje odbiorców, dla których JWT jest przeznaczony. Każdy podmiot zamierzający przetworzyć JWT MUSI utożsamiać się z wartością w roszczeniu odbiorców. Jeżeli główny rozpatrujący roszczenie nie identyfikuje się z wartością w roszczeniu „aud”, gdy roszczenie to występuje, wówczas JWT MUSI zostać odrzucony. W ogólnym przypadku wartość „aud” jest tablicą łańcuchów uwzględniających wielkość liter, z których każdy zawiera wartość StringOrURI. W szczególnym przypadku, gdy tokena JWT ma jedną grupę odbiorców, wartość „aud” MOŻE być pojedynczym łańcuchem uwzględniającym wielkość liter i zawierającym wartość StringOrURI. Interpretacja wartości odbiorców jest na ogół specyficzna dla aplikacji.
Użycie tego oświadczenia jest OPCJONALNE.
audOświadczenie Audience ( ) zdefiniowane w specyfikacji jest ogólne i jest specyficzne dla aplikacji. Zamierzonym zastosowaniem jest identyfikacja zamierzonych odbiorców tokena. To, co oznacza odbiorca, zależy od aplikacji. Wartość odbiorców to lista ciągów lub pojedynczy ciąg, jeśli istnieje tylko jedno audroszczenie. Twórca tokena nie wymusza tego, czy audzostał on poprawnie zweryfikowany, odpowiedzialność za określenie, czy token powinien zostać użyty, spoczywa na odbiorcy.
Niezależnie od wartości, gdy odbiorca waliduje token JWT i chce sprawdzić, czy token był przeznaczony do jego celów, MUSI określić, jaka wartość audidentyfikuje się sam, a token powinien sprawdzać tylko wtedy, gdy zadeklarowany identyfikator odbiorcy to obecny w audroszczeniu. Nie ma znaczenia, czy jest to adres URL, czy inny ciąg znaków specyficzny dla aplikacji. Na przykład, jeśli mój system zdecyduje, że identyfikuje się audza pomocą ciągu znaków: api3.app.comwówczas powinien akceptować token JWT tylko wtedy, gdy audroszczenie zawiera api3.app.comlistę wartości odbiorców.
Oczywiście odbiorcy mogą zdecydować się zignorować aud, więc jest to przydatne tylko wtedy, gdy odbiorca chciałby pozytywnej weryfikacji, że token został stworzony specjalnie dla niego.
Moja interpretacja oparta na specyfikacji jest taka, że audtwierdzenie jest przydatne do tworzenia specjalnie skonstruowanych tokenów JWT, które są ważne tylko do określonych celów. W przypadku jednego systemu może to oznaczać, że chcesz, aby token był ważny dla niektórych funkcji, ale nie jest ważny dla innych. Możesz wydawać tokeny, które są ograniczone tylko do określonej „grupy docelowej”, nadal używając tych samych kluczy i algorytmu weryfikacji.
Ponieważ w typowym przypadku token JWT jest generowany przez zaufaną usługę i używany przez inne zaufane systemy (systemy, które nie chcą używać nieprawidłowych tokenów), systemy te muszą po prostu koordynować wartości, których będą używać.
Oczywiście audjest to całkowicie opcjonalne i można je zignorować, jeśli Twój przypadek użycia tego nie gwarantuje. Jeśli nie chcesz ograniczać tokenów do używania przez określonych odbiorców lub żaden z Twoich systemów faktycznie nie zweryfikuje audtokenu, jest on bezużyteczny.
Przykład: Tokeny dostępu a odświeżanie
Jeden wymyślny (ale prosty) przykład, o którym mogę pomyśleć, jest taki, że być może chcemy używać tokeny JWT do dostępu i odświeżania tokenów bez konieczności implementowania oddzielnych kluczy szyfrowania i algorytmów, ale po prostu chcemy mieć pewność, że tokeny dostępu nie będą weryfikowane jako tokeny odświeżania lub wady -versa.
Używając audmożemy określić żądanie refreshdla tokenów odświeżania i żądanie accessdla tokenów dostępu podczas tworzenia tych tokenów. Gdy zostanie wysłane żądanie uzyskania nowego tokenu dostępu z tokenu odświeżania, musimy sprawdzić, czy token odświeżania był prawdziwym tokenem odświeżania. audWalidacja jak opisano powyżej powie nam, czy token był rzeczywiście ważny token odświeżania patrząc specjalnie na roszczenie refreshw aud.
Identyfikator klienta OAuth a audroszczenie JWT
Identyfikator klienta OAuth jest całkowicie niepowiązany i nie ma bezpośredniego związku z audoświadczeniami JWT . Z punktu widzenia OAuth tokeny są obiektami nieprzezroczystymi.
Aplikacja, która akceptuje te tokeny, jest odpowiedzialna za analizowanie i sprawdzanie znaczenia tych tokenów. Nie widzę dużej wartości w określaniu identyfikatora klienta OAuth w audroszczeniu JWT .
aud REQUIRED for session_token. Contains the client_id of the client receiving the assertion.