Короткий ответ таков: вам на самом деле все равно, во внешнем интерфейсе. Проверка токена обычно происходит через бэкэнд, а в вашем случае - через jwtRsaCustomAuthorizer, о котором вы говорили. Если бэкэнд доверяет токену, он возвращает данные, а если нет, возвращает ошибку авторизации.
Ваш бэкэнд, в частности jwtRsaCustomAuthorizer, подтверждает, что содержимое вашего токена JWT является действительным и надежным. Токен JWT состоит из трех частей. Первая часть описывает используемый алгоритм. Вторая часть - это полезная нагрузка, которая содержит требования, одноразовый номер, эмитента и дату истечения срока действия. Третья часть используется для проверки, выдан ли токен JWT доверенной стороной, используя секрет и создавая с ним подпись. В вашем случае вы используете RS256 с парой секретного и открытого ключей.
Поскольку первые две части токена JWT используются для генерации подписи, вы не можете изменить алгоритм или полезную нагрузку без аннулирования подписи. Поскольку RS256 использует ассиметричное шифрование с использованием пары открытого и закрытого ключей, вы можете либо проверить токен JWT, выполнив те же действия с использованием закрытого ключа и сравнив вновь сгенерированную подпись с подписью в токене JWT, либо в случае вашей конечной точки API. использование открытого ключа для расшифровки подписи и проверка его по первым двум частям токена JWT.
jwtRsaCustomAuthorizer гарантирует, что токен JWT был создан auth0, проверяя токен JWT на открытый ключ, предоставленный auth0. Если подпись соответствует полезной нагрузке, это означает, что у эмитента должен быть доступ к закрытому ключу, который доступен только эмитенту. Это позволяет доверять полезной нагрузке.
Вы можете найти дополнительную информацию через jwt.io и в этом вопросе о стеке потока о разнице между hs256 и rs256 .