OAuth: хранение токена доступа и секрета
У нас есть ряд клиентов, которые используют наш API для поддержки своих сайтов.
На работе я начал разговор об использовании OAuth для выполнения аутентифицированных вызовов API. У нас будут оба, два и три шагающих потока.
Что касается трехстороннего потока, мы до сих пор не пришли к единому мнению о том, как хранить токен доступа и секрет.
Распространенным подходом к этой проблеме было бы сохранение клиентами маркера доступа и секрета в их собственной БД, но об этом не может быть и речи, поскольку клиенты не хотят иметь дело с изменениями кода и проблемами реализации.
Другие варианты, которые мы рассматриваем:
1) Сохранение токена доступа и секрета в cookie
2) Сохранение их в сеансе.
Я не уверен, является ли любая из них хорошей идеей. У кого-нибудь есть предложения?
Спасибо.
4 ответа
Я предполагаю, что вы говорите о типичных настройках типа "Поставщик услуг","Потребитель" и "Пользователь". Я не знаю, сможете ли вы реализовать трехсторонний oAuth, если ваши Потребители (клиент) откажутся вносить какие-либо изменения.
Сеанс и файлы cookie будут работать для сохранения токенов, но проблема в том, что их должен сохранять ваш потребитель (ваши клиенты), а не вы. Вызовы к вашему API происходят на бэкэнде, и поэтому в этой области нет реального сеанса или файла cookie. Если вы только делаете вызовы JavaScript, возможно, это работает, но даже тогда обычно вызовы выполняются через прокси-сервер, чтобы избежать проблем междоменных сценариев.
В любом случае, если токены хранятся в сеансе или файлах cookie, они будут "временными" ключами, и пользователь должен будет повторно пройти аутентификацию после окончания сеанса или файлов cookie. Но в этом нет ничего плохого в том, что касается спецификации oAuth - если пользователи не против повторной аутентификации.
Вы можете сослаться на Образец приложения для.NET, написанный с использованием движка MVC 5 Razor.
Как упомянул Джейсон, потребительское приложение не может делать аутентифицированные запросы, если они не хранят токены, необходимые для аутентификации - они могут хранить их любым способом, каким захотят, но это необходимая часть уравнения. Это может быть файловая система, memcache, база данных, память.
Единственный способ использовать файлы cookie для их хранения - приложение-потребитель установит эти учетные данные токена в виде файла cookie в браузере пользователя, а пользователь отправит их обратно потребителю при каждом запросе - однако это кажется абсурдным, во-первых, Потребительское приложение снова должно будет внести изменения в свой код, чтобы справиться с этим, и, во-вторых, секретный ключ токена и токена будут избыточно летать по сети и браузеру пользователя, что может стать дырой в безопасности, если пользователь сам решит взломать.
У меня была такая же проблема, когда я реализовал 3-х сторонний oauth. Я запустил свое приложение в Интернете на Google App Engine и использовал Google DataStore для хранения токенов доступа.
Однако здесь указывается квота для хранения данных и выдачи запросов! Это единственное ограничение при использовании Google App Engine!
О 1) Сохранение токена доступа и секрета в куки
Рассмотрите своего клиента в интернет-кафе, и что произойдет после того, как он не удалит куки и следующий человек скопирует эту информацию?
Я бы пошел на сессии БД или PHP