Недостаточно информации, чтобы предположить, что именно вы должны делать с архитектурой в отношении аутентификации и авторизации, но я могу рассказать вам об одном из подходов, на которые я склонен полагаться.
Следуйте OAuth, поскольку он даету вас есть несколько вариантов, вы можете начать с собственной IDM / IAM и позже подключиться через социальные платформы.
Мы начали с JWT, и по большей части это был просто подписанный токен (некоторое время спустя мы переехалина подписанные и зашифрованные токены).Мы создали один сервис, отвечающий за обработку аутентификации и создание токена JWT.(Мы начали с Keycloak , но позже перешли к собственному сервису, поскольку keycloak для нашего случая использования был громоздким)
Когда вы говорите «внешний», я не уверен, что вы подразумеваете под этим, еслипросто доступны для конечного пользователя IMO, мы можем жить только с подписанным токеном.Да, вся информация видна пользователю, но это все его информация и некоторая информация, связанная с авторизацией.
Если вы передаете свой токен кому-то за пределами ваших границ, фактической внешней системе, где вы не хотите делиться информацией об использовании, вы можете подумать о ее шифровании, но тогда будет довольно много вещей, которыевам нужно думать с точки зрения безопасности, и поэтому в долгосрочной перспективе вам могут помочь стандартная платформа безопасности или сторонний поставщик (которому вы оба можете доверять и который уделяет достаточно внимания обеспечению безопасности).
Использование комбинации непрозрачного токена и JWT может быть излишним, если только у вас нет веских причин против этого.IMO, с которым вам легко начать, используйте JWT, если требуется, зашифруйте его.Все, что вам нужно, это еще один сервис для управления аутентификацией, создания и подписания токена, и вы должны быть хорошими.