Использование IdentityServer3 с одностраничным приложением (UseIdentityServerBearerTokenAuthentication)

Фон

Я использую эти технологии для защиты приложения WebApi:

  • ThinkTecture.IdentityServer3
  • ОВИН (Azure)
  • Одностраничное приложение - клиент javascript
  • См. образец простого пошагового руководства по OAuth2 (github). )

В приведенном выше примере клиент консольного приложения .NET запрашивает маркер у IdentityServer и использует его для доступа к приложению WebApi. Это отлично работает в образце.

Я хочу изменить клиент консольного приложения .NET на клиент одностраничного приложения javascript. Я попытался добавить прокси-контроллер входа в систему, который выполняет запрос к IdentityServer от имени клиента javascript и возвращает токен обратно клиенту в файле cookie.

Код

[HttpPost]
[Route("login")]
public HttpResponseMessage Login(LoginRequest request) // Proxy to IdentityServer3
{

    var tokenClient = new TokenClient(
            "https://localhost:44333/connect/token",
            "javascript client",
            "client secret");

    var tokenResponse = _tokenClient.RequestResourceOwnerPasswordAsync(request.username, request.password, "api1").Result;

    var cookie = new CookieHeaderValue("access_token", tokenResponse.AccessToken);
    cookie.Expires = DateTimeOffset.Now.AddDays(1);
    cookie.Domain = "localhost";
    cookie.Path = "/";            
    var response = new HttpResponseMessage();
    response.Headers.AddCookies(new CookieHeaderValue[] { cookie });
    return response;
}

Я успешно получаю токен доступа в клиенте javascript, однако API не распознает его.

Вопрос

Как мне передать токен, сгенерированный IdentityServer, в приложение javascript и как его использовать для доступа к WebApi?


person sa555    schedule 01.02.2016    source источник
comment
Приложения Js предпочли бы, чтобы она использовала неявный поток. Проверьте документы и образцы.   -  person leastprivilege    schedule 02.02.2016


Ответы (2)


Допустим, конечная точка вашего токена — «https://localhost:44333/connect/token" (как вы упомянул). Нажатие на эту конечную точку с запросом POST с телом, подобным следующему, вернет токен:

grant_type=password&client_id=youtclientid&client_secret=yourclientsecret&username=yourUserName&password=YourPassword&scope=list_of_requested_scopes

Вы используете переменную JS для хранения своего токена, а затем, чтобы использовать этот токен для доступа к защищенным API, вы должны отправить его как часть заголовка в запросе, подобно следующему: В заголовке вашего запроса у вас будет :

Authorization: Bearer eyJ0eXAiOiJKV...

где "eyJ0eXAiOiJKV..." — это токен, который вы получили на первом шаге.

person Behrooz    schedule 02.02.2016
comment
Почему? Я имею в виду, если вы используете https...? - person Behrooz; 19.07.2016
comment
https защищает соединение от человека в средней атаке. Это может сделать соединение безопасным, а не конечными системами. Весь смысл разработки токена заключается в том, чтобы избежать появления паролей. Опять же, это только моя точка зрения. - person Abhay Naik; 19.07.2016
comment
Ваше мнение очень ценно, и я пытаюсь извлечь из него урок :) Но если вы используете токены обновления, вы отправите пароль только один раз, а затем продолжите использовать токены обновления для продления сеанса, верно? Даже если вы используете неявный поток, вы все равно отправляете пароль один раз. Кстати, что вы предлагаете взамен? - person Behrooz; 19.07.2016
comment
Я просто напишу ответ. Форматирование намного проще - person Abhay Naik; 19.07.2016

Использование oidc-client.js или создание чего-то подобного в этих строках, так как размер этой библиотеки js велик.

Проверьте эту ссылку. https://github.com/IdentityModel/oidc-client-js/tree/master/sample

и видео https://vimeo.com/131636653

Мы используем инфраструктуру IdentityServer, чтобы получить первоначальный вход в систему, а затем идентификатор токена (ов) / доступ для всех дальнейших коммуникаций.

person Abhay Naik    schedule 19.07.2016