IdentityServer3 — потоки OAuth, разные подходы

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

Что меня не убеждает, так это то, как обращаться с моим SPA, который в настоящее время вызывает мой веб-API, используя только аутентификацию на основе файлов cookie (+ токен защиты от подделки). Это приложение написано на Javascript на основе Backbone. По сути, он просто вызывает мой веб-API и отображает результаты. Меня смущают разные потоки грантов, и я не хочу создавать дыры в безопасности.

Решения, которые я подумал:

  1. сгенерировать токен напрямую через Javascript. Какой тип потока я должен использовать? Как справиться с обновлением токена?
  2. сгенерируйте токен из приложения внутреннего сервера и передайте сгенерированный токен обратно в SPA (очевидно, через канал SSL). Это как-то безопасно? Если да, какой поток мне следует использовать (я бы сказал, поток кода авторизации)? Как справиться с обновлением токена?

Как бы вы справились с этим?

Спасибо,

Марко


person Marconline    schedule 22.04.2016    source источник


Ответы (1)


Вот статья, в которой содержится обзор того, какой поток подходит для какого сценария: правильный-один/" rel="nofollow">https://leastprivacy.com/2016/01/17/what-openid-connectoauth-2-o-flow-is-the-right-one/

person Brock Allen    schedule 22.04.2016
comment
Спасибо! Я уже наткнулся на эту замечательную статью. Если я правильно понимаю, правильным использованием будет неявный поток, и пусть мой Javascript SPA обрабатывает этот токен доступа напрямую. Теперь возникает вопрос: не опасно ли позволить клиенту браузера напрямую обрабатывать токен? Спасибо. - person Marconline; 22.04.2016
comment
Зависит от API. Но если вам нужны вызовы из JS, вам нужно дать JS токен. Возможно, другой дизайн заключается в том, чтобы JS вызывал первый уровень API, который, в свою очередь, вызывает второй уровень API. Конечно, для второго API нужен собственный токен доступа, и это ваша следующая проблема. - person Brock Allen; 23.04.2016
comment
Хорошо, спасибо. Похоже, неявный поток - правильное решение. Я не буду создавать второй уровень API. Спасибо - person Marconline; 26.04.2016