OAuth: хранение маркера доступа и секрета
У нас есть много клиентов, которые используют наш API для включения их веб-сайтов.
Я запустил разговор на работе об использовании OAuth для создания аутентифицируемых Вызовов API. У нас будут оба, два и три потока на ножках.
Для 3-ногого потока мы все еще не пришли к согласию в отношении того, как сохранить маркер доступа и секрет.
Общий подход к этой проблеме должен был бы сделать, чтобы клиенты сохранили маркер доступа и секрет в их собственном DB, но это вне рассмотрения, поскольку клиенты не хотят иметь дело с изменениями кода и проблемами реализации.
Другие опции мы рассматриваем:
1) Сохранение маркера доступа и секрета в cookie
2) Сохранение их на сессии.
Я не уверен, является ли любой из них хорошей идеей. У кого-либо есть какие-либо предложения?
Спасибо.
2 ответа
Я предполагаю, что вы говорите о типичных типах настройки «Поставщик услуг», «Потребитель» и «Пользователь». Я не знаю, сможете ли вы реализовать трехсторонний oAuth, если ваши потребители (клиент) откажутся вносить какие-либо изменения.
Сеанс и файлы cookie будут работать для сохранения токенов, но проблема в том, что их должен сохранять ваш Потребитель (ваши клиенты), а не вы. Вызовы вашего API происходят на серверной стороне, поэтому в этой области нет реального сеанса или файла cookie. Если вы выполняете только вызовы JavaScript, возможно, это сработает, но даже в этом случае вызовы обычно выполняются через прокси, чтобы не было проблем с междоменными сценариями.
В любом случае, если токены хранятся в сеансе или файлах cookie, они будут «временными» ключами, и Пользователь должен будет повторно пройти аутентификацию по истечении срока действия сеанса или файлов cookie. Но что касается спецификации oAuth, в этом нет ничего плохого - если пользователи не возражают против повторной аутентификации.
Вы можете сослаться на Пример приложения для .NET, написанного с использованием движка MVC 5 Razor
, как сказал Джейсон, приложение-потребитель не может выполнять аутентифицированные запросы, если они не хранят токены, необходимые для аутентификации - они могут хранить их в как они хотят, но это необходимая часть уравнения. Это может быть файловая система, кэш памяти, база данных, память.
Единственный способ, которым я вижу использование файлов cookie для их хранения, - это для приложения-потребителя установить эти учетные данные токена в качестве файла cookie в браузере пользователя, а пользователь должен отправлять их обратно потребителю с каждым запросом - однако это кажется абсурдным, поскольку во-первых, потребительское приложение снова должно будет внести изменения в свой код, чтобы справиться с этим, а во-вторых, токен и секретные ключи токена будут избыточно летать по сети и браузеру пользователя, что может быть дырой в безопасности, если пользователь сам решит это сделать. взлом.