Я задал тот же вопрос в Auth0 Community , и здесь обсуждается вопрос, который может быть полезен для тех, у кого такая же проблема.
Я копирую здесь те же ответы:
markd :
Вы правы в том, что вам не следует использовать токен доступа в качестве удостоверения личности, но прежде чем вы перейдете к своему API, вы должны уже аутентифицировать пользователя и получить для него id_token. Если вы уже аутентифицировали пользователя через OIDC, насколько я знаю, нет ничего плохого в том, чтобы добавить пользовательские утверждения в маркер доступа для передачи данных в ваш API . Ваш API также может использовать тип предоставления учетных данных клиента для извлечения данных из Auth0.
Me:
Я ищу лучшие практики. Я хочу быть уверенным, что добавление утверждений об идентичности к токену доступа и использование этого в API ничего не нарушает и основано на передовом опыте, или, возможно, лучшим решением будет всегда вызывать /userinfo конечная точка в API и не полагаться на утверждения идентификации токена доступа .
API не знает о процессе аутентификации и не заботится об этом. Любой, кто каким-либо образом передает подписанный токен доступа в API, будет принят. Теперь с точки зрения API это правильный способ полагаться на утверждения личности в Access Token? У меня есть сомнения. Но я был бы рад, если бы мы могли каждый раз игнорировать конечную точку /userinfo. 1025 *
jmangelo
Я могу поделиться некоторыми (надеюсь) информированными взглядами по этому вопросу, но, пожалуйста, примите их с крошкой соли и задайте вопросы, с которыми вы не согласны или не считаете достаточно ясными. Когда речь идет о программном обеспечении, дьявол кроется в деталях, а в плане безопасности это еще более верно, поэтому вы должны рассматривать лучшие практики как то, что, вероятно, будет рекомендовано для большинства сценариев, а также то, что, вероятно, будет менее рискованным; это не значит, что больше ничего не возможно.
Например, хотя рекомендация действительно заключается в использовании токенов доступа в запросах к API, это не означает, что не существует конкретного сценария, в котором технически было бы также неплохо вместо этого отправить идентификационный токен.
Сосредоточение внимания на ваших конкретных вопросах и начиная с последнего (3); мы не должны сравнивать HOK и токены доступа, потому что они не находятся на одном уровне. Другими словами, вы можете задаться вопросом, следует ли в вашем сценарии использовать токены на предъявителя или токены HOK в качестве этого способа и, используя терминологию вашей связанной страницы, вы будете выбирать между двумя профилями токенов, каждый из которых дает вам разные характеристики.
В настоящее время токены доступа, выданные службой Auth0 в рамках авторизации API, являются токенами доступа на предъявителя, поэтому на этот вопрос можно получить только один ответ при использовании службы Auth0.
Переход к первому вопросу; дело не в том, что вы не можете передать ID-токен в API, просто сценарии, в которых это будет достаточно, гораздо более ограничены. Например, ID-токен выдается с идентификатором клиента в качестве аудитории; Распространено иметь несколько клиентских приложений, поэтому вы только что связали свой API с тем, сколько у вас есть клиентских приложений, поскольку при условии, что вы будете проверять аудиторию идентификатора токена, вашему API теперь нужно будет знать идентификаторы каждого клиента.
Для вопроса (2), который, как я полагаю, также интересует, зачем звонить / userinfo, если вы можете включить утверждения в токен доступа. Я считаю, что это может сильно зависеть от требований и / или личных предпочтений. В настоящее время единственным форматом, поддерживаемым при выдаче токена доступа к пользовательскому API, является формат JWT.
Вышеуказанное означает, что у вас есть автономный токен, который после выдачи API может в основном проверять независимо, что очень хорошо с точки зрения масштабируемости, поскольку API не нужно совершать (частые) внешние вызовы для целей проверки.
Однако, будучи самЭто немедленно означает, что любые данные, которые вы включаете непосредственно в токен, будут считаться правдой в течение всего срока жизни самого токена.Если вместо этого API вызывает / userinfo или даже непосредственно Management API, то вы гарантируете свежие данные за счет сетевых издержек.
В заключение, на мой взгляд, выбор между сетевыми вызовами и встроенными утверждениямив большей степени связан с характеристиками данных, которые вас интересуют, просто с точки зрения передового опыта .
В качестве заключительного замечания, даже без добавления пользовательских требований токен доступа, выданныйСервис в сочетании с пользовательским API уже передает личность пользователя.В частности, учитывая, что токен доступа является JWT, подпретензия будет содержать идентификатор, который уникальным образом идентифицирует конечного пользователя, который разрешил текущему приложению вызывать API от их имени.