Как понять где проходит аутентификация в решении из нескольких проектов asp web api + angularjs?

Question

[ShinShil]

Недавно начал поддерживать большой веб-проект, который написан не мной.

Проект состоит из нескольких подпроектов, каждый из которых крутится на своём сервере: AuthApi, WebApi, Web, Reports - см. скриншот ниже. Все проекты - это web api 2, а Web - это mvc application, который возвращает angularjs spa.



Никак не могу понять, каким образом проходит аутентификация.

Поиском по проекту не нашёл никаких ссылок на AuthApi внутри проекта WebApi, тем не менее разрешаются только аутентифицированные запросы. Причём требуется аутетификация при запросе к Web, и при запросе к контроллерам WebApi. В WebApi тоже не нашёл никаких упоминаний об AuthApi. Тем не менее это всё как-то работает...

В AuthApi используется OAuthAuthorization и ApplicationUserProvider, после того как наставил там брейкпоинтов и подебажил, смог разобраться как оно работает. Но методы, которые смотрел вызываются только при логине пользователя. При обновлении страницы, всё работает где-то внутри, предполагаю, что вся информация сохранена в сессии и достаётся автоматически.

Ещё один странный момент, каждый из WebApi и AuthApi выполняет настройку app.UseOAuthBearerAuthentication. Причём в AuthApi она в разы более навороченная.

Углубиться заставил баг, в ходе решения которого выяснилось, что внутри контроллеров WebApi - ICurrentUser.User == null . У меня предчувствие, что это связано с тем, что CurrentUser существует только в рамках AuthApi

Хочу как-то найти в каком месте проверяется аутентификация, и посмотреть откуда там берётся CurrentUser. А затем попробовать, если понадобиться, как-то с помощью автофака в WebApi настроить получение ICurrentUser из контекста AuthApi.

PS. Знаний катастрофически не хватает, т.к. очень-очень много разного материала по этой теме, который уже прочитал, яснее в голове стало, но проблему пока не решил. Возможно любой обрывок информации поможет найти в какую сторону копать.

Answer 1

[Роман]

Вся магия тут UseOAuthBearerAuthentication. После авторизации в SPA передается JWT токен, в котором в зашифрованом виде сохранен CurrentUser, при запросе к WebAPI, SPA передает JWT токен в HTTP заголовке, а API проверяет валидность токена и расшифровывает его вытаскивая сохраненного пользователя. Вам в WebAPI надо просто настроить JWT авторизацию, как это сделано в AuthApi.

Comments

[ShinShil]

Спасибо, теперь, когда понял, что инфа автоматически добавляется в headers и летает между сервером и SPA, картинка окончательно сложилась. AuthApi - выполняет аутентификацию и отдаёт токены, остальные api просто используют UseOAuthBearerAuthentication, т.е. токен в SPA полученный из AuthApi отправляется во все другие Api, а они просто распаршивают его и получают CurrentUser.
-----------------------------------------------------------------------------------------
Нашёл проблему. Дело в том, что страница, которая использует контроллер в WebApi открывается с помощью метода window.open(url, '_blank'); В этом случае заголовки не добавляются и поэтому у запроса к WebApi не установлен BearerToken, соответственно WebApi расценивает это как CurrentUser раный null.

[Роман]

ShinShil, А как так WebApi пускает неавторизованного пользователя?

[ShinShil]

Конкретно в данном контроллере к данному экшену защита отсутствует. ЛОЛ :) Защита осуществляется с помощью аттрибута Authorize, а на экшене поставлен AllowAnonymous. Скорее всего это было сделано, чтобы разрешить запрос при window.open(url, '_blank').