OAuth: хранение токена доступа и секрета

Question

У нас есть ряд клиентов, которые используют наш API для поддержки своих сайтов.

Я начал разговор на работе об использовании OAuth для выполнения аутентифицированных вызовов API.У нас будут потоки с двумя и тремя шагами.

Для потока с тремя шагами мы все еще не пришли к единому мнению о том, как хранить токен доступа и секрет.

Общим подходом к решению этой проблемы было бы сохранение клиентами маркера доступа и секрета в их собственной БД, но об этом не может быть и речи, поскольку клиенты не хотят иметь дело с изменениями кода и его реализацией.проблемы.

Другие варианты, которые мы рассматриваем:

1) Сохранение токена доступа и секрета в cookie

2) Сохранение их в сеансе.

Я не уверен, является ли любая из них хорошей идеей.У кого-нибудь есть предложения?

Спасибо.

Answer 1

Я предполагаю, что вы говорите о типичных настройках типа «Поставщик услуг», «Потребитель» и «Пользователь». Я не знаю, сможете ли вы реализовать трехсторонний oAuth, если ваши Потребители (клиент) откажутся вносить какие-либо изменения.

Сеанс и куки будут работать для сохранения токенов, но проблема в том, что их должен сохранять ваш потребитель (ваши клиенты), а не вы. Вызовы к вашему API происходят на бэкэнде, и поэтому в этой области нет реального сеанса или файла cookie. Если вы только делаете вызовы JavaScript, возможно, это работает, но даже тогда обычно вызовы выполняются через прокси-сервер, чтобы избежать проблем междоменных сценариев.

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

Вы можете сослаться Образец приложения для .NET, написанный с использованием MVC 5 Razor engine

Answer 2

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

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

Answer 3

около 1) Сохранение токена доступа и секрета в куки

Рассмотрите своего клиента в интернет-кафе и что произойдет после того, как он не удалит куки и следующий человек скопирует эту информацию?

Я бы пошел на сеанс БД или PHP

Answer 4

У меня была такая же проблема, когда я реализовал 3-х сторонний oauth. Я подключил свое приложение к Интернету на Google App Engine и использовал Google DataStore для хранения токенов доступа.

Однако в квоте упоминается здесь для хранения данных и выдачи запросов! Это единственное ограничение при использовании Google App Engine!