Они не являются взаимоисключающими. Вы будете использовать то, что вы называете «Tokenized Authentication», например, токен oAuth2 Bearer, скорее всего, в JWT, когда аутентификация выполняется отдельной системой из вашего бэкэнда Spring Boot. Например, вы можете использовать Okta, Keycloak, Google или Facebook для аутентификации пользователя.
Как минимум, ваш бэкэнд Spring Boot хранит имя пользователя, извлеченное из JWT в Authentication. Вы можете заставить Spring Boot извлечь любые роли в токене и добавить их в Authentication::grantedAuthorites. Если ваша бэкэнд-система имеет свой собственный набор ролей в дополнение к тому, что находится в токене, тогда бэкэнд может реализовать PrincipalExtractor для загрузки объекта UserDetails для этого пользователя из базы данных как Principal и объединения ролей в токен с этим хранилищем в локальной базе данных.
Возможно, вы захотите защитить определенные методы в своем бэкэнде с помощью аннотаций безопасности методов, таких как @PreAuthorize(), поскольку вы не должны доверять внешнему интерфейсу. Метод безопасности проверяет разрешения, например hasRole("ADMIN") или hasPermission(object, 'READ'), используя объект Principal в SecurityContextHolder.getContext().getAuthentication();
В конце концов, токен гарантирует, что пользователь, обращающийся к нему, является бэкэндом, то есть кем он себя называет, т. Е. Аутентификация, но не обязательно сообщает бэкэнду, что ему разрешено делать. Да, если вы управляете сервером аутентификации, вы можете включать роли в JWT, но роли обычно не обеспечивают столь детального контроля, как требуется.
Независимо от того, какой уровень безопасности вы реализуете, токен преобразуется в Авторизацию, поэтому вы можете использовать инфраструктуру Spring Security для управления доступом в своем бэкэнд-коде.