Как преобразовать код OAuth с помощью маркера доступа

представьте, что вы проходите через стандартный процесс OAuth2, чтобы получить access_token для некоторых сторонних API. Это обычный процесс.

  1. пользователь перенаправляется на http://some-service.com/login
  2. пользователь успешно входит в систему и перенаправляется в какой-то пункт назначения http://some-destination.com. На этом этапе обычно есть code параметр, который поставляется с запросом. Таким образом, фактический URL выглядит как http://some-destination.com?code=CODE123
  3. мне нужно использовать CODE123 запрос access_token который можно использовать чтобы авторизовать мои будущие вызовы API. Для этого есть конечная точка, которая обычно выглядит так (я использую Nylas в качестве примера, но должна быть достаточно общей):

enter image description here

как вы можете видеть, это требует от меня опубликовать код сверху (CODE123) вместе с client_id и client_secret такой: http://some-service.com/oauth/token?code=CODE123&client_secret=SECRET&client_id=ID. В ответ я получаю access_token вот такой TOKEN123 и я могу использовать это, чтобы сделать API звонки.

вопрос

до шага 2, все происходит на стороне клиента. Но на Шаге 3 мне нужно иметь client_id и client_secret. Я не думаю, что это хорошая идея хранить эти значения на стороне клиента. Означает ли это, что мне нужен сервер, который имеет эти два значения, и мой сервер должен преобразовать CODE123 to TOKEN123 и передать его на стороне клиента?

6
oauth

1 ответов

Как вы, вероятно, знаете, вопрос описывает наиболее распространенный (и, как правило, более безопасный) OAuth "код авторизации" поток. Чтобы быть ясным, вот приближение шагов в этом потоке:

  1. пользователь указывает, что он хочет авторизовать ресурсы для нашего приложения (например, нажав на кнопку)
  2. приложение перенаправляет пользователя на страницу входа третьей стороны, где пользователь входит в систему и выбирает, какие ресурсы предоставить доступ к
  3. сторонняя служба перенаправляет пользователя обратно в наше приложение с помощью код авторизации
  4. наше приложение использует этот код, а также его идентификатор клиента и секрет для получения маркер доступа это позволяет приложению делать запросы от имени пользователя только для ресурсов, которые пользователь разрешил

до шага 2, все происходит на стороне клиента. Но на Шаге 3 мне нужно имейте client_id и client_secret. Я не думаю, что это хорошая идея хранить эти значения на стороне клиента. Означает ли это, что мне нужен сервер, который имеет эти два значения[?]

вы правы, это конечно не хорошая идея сохранить эти значения в клиентском приложении. Эти значения-особенно секрет клиента -должны размещаться на сервере для защиты данных приложения. Пользователь-поэтому клиент приложение-никогда не должно иметь доступа к этим значениям.

сервер использует идентификатор и секрет клиента вместе с кодом авторизации для запроса маркера доступа, который он использует для вызовов API. Сервер может хранить полученный токен вместе с дополнительным маркер который он может использовать в будущем для получения нового маркера доступа без необходимости явной авторизации доступа пользователем.

...и мой бэкэнд должен преобразовать CODE123 в TOKEN123 и передать его стороне клиента?

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

однако на данный момент клиентское приложение (и пользователь этого клиента) отвечает за безопасность маркера доступа. В зависимости от требований безопасности нашего приложения, мы можем добавить слой для защиты этого маркер доступа также от клиента.

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

для более безопасного выполнения вызовов API от имени пользователя клиентское приложение может отправлять запросы на наш сервер, который, в свою очередь, использует токен доступа, полученный взаимодействие со сторонним API. При такой настройке клиенту не нужно знать значение маркера доступа.

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

3