Использование ID Token предназначено для клиентского приложения. Клиент использует его для аутентификации конечного пользователя. Все это стало возможным благодаря претензиям с ID токена передачи И эти претензии встроены в JWT. Проще говоря, ID Token - это автономный токен.
Теперь обмен ID-токеном вне клиента - это нормально, если вы контролируете все намеченные стороны. Подумайте о сценарии, в котором вы пропускаете конфиденциальную информацию пользователя через идентификатор токена. Например, если идентификационный токен содержит заявление о поле, предназначенное только для использования клиентом. Но когда вы передаете идентификационный токен третьему лицу, вы раскрываете эту конфиденциальную информацию. Это может быть преступлением, если существуют правовые барьеры.
Еще один момент касается проверки токена ID. Таким образом, ID Token ориентирован на клиента, важные требования, такие как aud, устанавливаются соответствующим образом. Когда вы передаете идентификационный токен используемому бэкэнду, такая проверка может завершиться неудачно.
Есть два решения. Во-первых, это использовать автономные токены доступа. В наши дни распространено использование токенов доступа на основе JWT. С ними вы получите то же решение. Он будет содержать идентификатор конечного пользователя, значения области, а также информацию о проверке токена. Azure AD использует такой подход - проверьте эту ссылку .
Второй - использовать идентификационный токен. Учитывая, что вы управляете как передним, так и внутренним интерфейсом, я считаю, что вы можете использовать его. Но помните о будущих расширениях. Специально, чтобы не подвергать это другим сторонам.