Авторизация с помощью токена-указателя OAuth, предоставленного внешним веб-API

Question

Я отправляю это в надежде получить некоторые отзывы/советы и информацию о том, с чем я боролся в последние несколько дней. Чтобы начать, я кратко расскажу о проекте.

Есть 2 приложения в растворе:

1. WebAPI ресурсы & сервера авторизации - Использует Owin (размещенный в IIS) и ASP.NET Идентичность выдавать маркер аутентификации на правильный логин, а затем разрешать запросы к различным контроллерам.

2. Клиентское приложение MVC - Пока нет (пока не выясню), но вызовет на сервер ресурсов WebAPI все данные. Эти вызовы будут выполняться только из действий контроллеров в клиентском приложении, без вызовов AJAX на стороне клиента.

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

• Каков наилучший способ справиться с этим?
• Возможно ли настроить OWIN на стороне клиента для использования настроек OAuth сервера? Я лаяю неправильное дерево, и мне нужно просто использовать HTTPClients?
• Могу ли я десериализовать токен-носитель и сохранить его в сеансе, а затем написать свои собственные авторизационные провайдеры, чтобы проверить их на стороне клиента?

Мои первоначальные опасения состоят в том, что я злоупотребляю знаками-носителями и пытаюсь скрестить их с решением, которое не является идеальным. Все примеры внешнего авторизации, которые я нашел до сих пор, обычно включают в себя призывы к провайдерам, размещенным в Google/Facebook/Twitter, чтобы проверить, кто из них, кто они говорят, а затем переходит к созданию пользовательской записи в своей системе. Мое приложение не может этого сделать.

Что касается безопасности, я планировал ввести фильтры, которые подтвердили бы, что запрос пришел из клиентского приложения, предоставив идентификатор и секрет, а также проверку IP-адресов.

Я понимаю, что это может быть немного открытым, но я был бы признателен за любой совет. Объем проекта заключается в том, что веб-служба является только, чтобы иметь доступ к базе данных. Клиентское приложение MVC будет размещено на другом сервере, и служба будет принимать заявки только от указанного клиентского приложения.

Answer 1

Вам не нужно обращаться к источнику данных в своем приложении MVC для проверки токена-носителя. В принципе, вы можете сделать это следующим образом,

• MVC приложение запрашивает access_token от WebAPI и передает его клиенту UI (скажем, браузер).

• Браузер сохраняет access_token в файле cookie/localstorage и отправляет их в приложение MVC для всех последующих запросов.

• Создайте в приложении MVC ActionFilter, чтобы проверить, имеет ли запрос из браузера маркер, указанный в заголовке. Если нет, отклоните запрос.

• Приложение MVC передает access_token в заголовке Authorization на webapi.

• Использовать HTTPS для всех видов связи (между MVC приложение < -> Client и MVC приложение < -> WebAPI)

Вы можете еще больше запутать или зашифровать access_token вы получаете от WebAPI на MVC приложение для дополнительной безопасности, но затем вам придется отправить расшифрованную версию обратно в WebAPI.

Answer 2

Я понимаю, что мой ответ немного поздно, но, возможно, это поможет другим людям:

Податель маркер, который вы получаете от API содержит список требований зашифрованным, что только API может расшифровать. Я предполагаю, что вам также нужно иметь эти заявки в приложении MVC, чтобы вы могли ограничить ресурсы на клиенте.

Итак, что я сделал, это сначала получить токен. После его получения вы делаете еще один запрос к API-интерфейсу api/me/Claim, чтобы получить список читаемых требований на клиенте. На основе этого списка вы можете разрешить доступ к ресурсам в своем приложении MVC CLient с использованием атрибута Authorize, основанного на собственных утверждениях. Кроме того, вы можете хранить претензии в файле cookie в сеансе клиента. Ниже приведен код для контроллера API для получения Претензий.

[RoutePrefix("api/me/claims")] 
public class ClaimsController : BaseApiController 
{ 
    [Authorize] 
    [Route("")] 
    public IHttpActionResult GetClaims() 
    { 
     var identity = User.Identity as ClaimsIdentity; 

     var claims = from c in identity.Claims 
        select new 
        { 
         subject = c.Subject.Name, 
         type = c.Type, 
         value = c.Value 
        }; 

     return Ok(claims); 
    } 
} 

Идея заключается в том, чтобы реконструировать объект ClaimsIdentity из зарегистрированного пользователя на стороне клиента, и, возможно, добавить его к сессии.

Недостаток токена. Возможно, вы рискуете получить неавторизованный ответ API на ресурсе, который вы сделали видимым для пользователя в клиентском приложении MVC. Иглы сказать, что рекомендуется использовать HTTPS для всех запросов.