Самым непосредственным следствием большого набора требований является более низкая производительность, поскольку токен обменивается между всеми задействованными системами в сети. Например, по умолчанию WIF сериализует токен и помещает их в файлы cookie. Таким образом, на практике вы также ограничены в количестве данных, которые вы можете хранить там. Есть и другие способы решения этой проблемы, но основная проблема сохраняется.
Второй вопрос - кто и где будет управлять связью между пользователем и учетной записью. Если это относится к конкретному приложению, маловероятно, что вы отправите эти ассоциации в центральный STS (эмитент заявок). В итоге вы получите 2 STS: тот, который идентифицирует пользователей (и провайдера идентификации: IdP), и STS для конкретного приложения, который преобразует токен, выданный IdP, в нечто, находящееся под приложением (включая список учетных записей для конкретного пользователя).
Сказав это, может случиться так, что ассоциация между пользователем и его учетными записями является чем-то, что можно многократно использовать среди многих приложений, тогда может иметь смысл оставить ее за специализированной STS.
Есть третье соображение, которое является потенциальным ненужным раскрытием информации. Приложению может потребоваться только знать, есть ли у пользователя X доступ к учетной записи 123. Предоставляя список всех учетных записей, к которым у пользователя X имеется доступ, вы раскрываете дополнительную информацию, которая необходима.
Как правило, требования лучше подходят для "грубых" атрибутов. «Мелкозернистое» управление доступом, вероятно, лучше обрабатывается внутри приложения, где вы можете использовать оптимизацию инфраструктуры.
Вот крайний пример: представьте себе файловую систему. Будете ли вы кодировать в качестве утверждений имена файлов, к которым у пользователя есть доступ? Маловероятно, потому что у вас могут быть миллионы ...
Еще один крайний пример: если вы хотите реализовать защиту на уровне строк в базе данных. Вы бы закодировали как претензии row_id для каждого пользователя? Опять же, вряд ли, поскольку их может быть много, это очень специфично для приложения, а также потому, что, вероятно, проще (и гораздо эффективнее) решить фильтрацию строк с помощью запроса к базе данных (это пример оптимизации инфраструктуры)