Здравствуйте, vl690001x, Вы писали:

V>Возможно, эта проблема не только ASP.NET, но и более общая.
V>Кто как с ней борется?
Ну для начала, как вы сами сказали, проблема (если это вообще проблема) не связана с ASP.Net Identity.
И даже с Cookies она связана опосредованно.

Если смотреть на ситуацию в общем, то протоколы аутентификации можно условно разбить на 2 группы:
— credentials пользователя передаются с клиента на сервер при каждом обращении. Например, так работает аутентификация пользователя в HTTP (когда credentials передаются на уровне транспорта).
— credentials передаются 1 раз при установлении сессии, а затем при каждом обращении используется так называемый сессионный токен, в котором credentials, как правило, отстутствуют.

У второго подхода есть масса аргументов "за":
1. Сервер, который непосредственно выполняет запрос, может не иметь доступа к credentials пользователя чтобы их проверить. Это, на самом деле крайне распространенная ситуация, сюда попадают все варианты аутентификации третьей стороной (через OpenID/OAuth/WS-Federeation/...), аутентификации единым центральным сервером (когда используются протоколы NTLM/Kerberos/HTTP Digest/... — т.е. когда сам пароль доступен только на стороне аутентификациооного сервера и на клиенте, а все промежуточные сервера видят только результат криптопреобразования, который еще и меняется случайным образом).
Как сверят credentials в этом случае?
2. Алгоритм аутентификации может быть куда сложнее "просто пароля". Сюда попадают такие случаи как многофакторная аутентификация, аутентификация по одноразовому (или временному паролю), аутентификация на основе сертификатов, биометрия, ...
Что и как хранить в данном случае и как проверять?
3. Далеко не всегда есть возможность одновременно сменить credentials на всех клиентах, где они используются. Например, служба, которая работает от имени пользователя. Как правильно обновить credentials для неё (если, конечно, мы хотим избежать ситуации, что служба начала сыпать ошибки из-за невозможности достучаться до сервера)? Остановить -> поменять credentials на сервере -> поменять credentials в настройках службы -> запустить? А если таких служб много?
4. Если передавать credentials вместе (или внутри) с сессионным токеном, то, теоретически, при вскрытии токена мы получим доступ к самим credentials, а значит дискредитирована будет не только текущая сессия, но и вцелом учетная запись пользователя.

Т.е. в случае использования сессионного токена нам нужно предпринять некие шаги, дабы исключить перехват сессии и сессионного токена.
Что обычно делают:
1. Ограничивают время жизни сессионного токена. Правда тут встает проблема — а какое время выставлять. Поставишь малое — замучаешь пользователя требованиями поавторить Credentials, поставишь большое — больше шансов у злоумышленника.
2. Ведут учет сессий на сервере и предлагают мехнизмы для: закрытия текущей сессии (например, когда явно отлогиниваешься), закрытия всех сессий (когда есть опасность дискредитации).
3. Используют дополнительные (не очень надежные, но всё же) мехнизмы — например, удаление кук при закрытии браузера на "чужом" компьютере.
4. Всячески предупреждают пользователя — не аутентифицироваться на ресурсах с ненадежных компьютеров и уж тем более не сохранять там пароли.