Краткое введение в OAuth 2.0 и то, как работает вход с помощью OAuth 2.0 - простым языком объяснено на примере входа в Google.

Мы рады сообщить вам, что Cotter теперь генерирует токены доступа и обновляет токены при аутентификации. В этой статье будет представлен обзор концепций и токенов OAuth 2.0, прежде чем мы перейдем к тому, как его использовать.

Обзор

  1. Что такое OAuth 2.0?
  2. OAuth 2.0 в действии
  3. Токены OAuth: недолговечные токены доступа и долгоживущие токены обновления.
  4. Как реализовать OAuth 2.0 для вашего сайта

Что такое OAuth 2.0?

OAuth 2.0 - это структура авторизации, которая определяет, как стороннее приложение может получить безопасный доступ к службе, не требуя от пользователя данных безопасности (имя пользователя, пароль и т. Д.). Типичный пример OAuth 2.0 - это когда вы используете «Войти через Google» для входа на другие веб-сайты.

OAuth 2.0 в действии

В целом поток OAuth 2.0 выглядит так:

Поток OAuth 2.0 с входом в Google

В качестве примера возьмем «Войти через Google».

Альберт использует Календарь Google и пытается использовать Calendly.com, чтобы помочь ему управлять своим календарем. Мы рассмотрим термины в следующем примере.

  • (1) Calendly.com хочет получить доступ к Календарю Google Альберта. Calendly.com перенаправляет Альберта для входа в свою учетную запись Google, где он предоставляет разрешение Календаря Google для Calendly.com. (2) Google возвращает разрешение на авторизацию и перенаправляет Альберта на Calendly.com.
  • (3) Calendly.com предоставляет Google разрешение на авторизацию и (4) получает токен доступа.
  • (5) Calendly.com теперь может использовать этот токен доступа для (6) доступа к Календарю Google Альберта, но не к его Диску Google или другим ресурсам.

Здесь Calendly.com является клиентом, Альберт - владельцем ресурса, учетная запись Google - сервером авторизации, а Календарь Google - сервером ресурсов.

Попробуем понять термины на более простом примере.

Давайте возьмем пример Альберты, которая останавливается в отеле и хочет разрешить своей няне Кенди доступ к своей комнате.

  1. Альберта соглашается, что Кенди войдет в ее комнату, и просит Кенди получить ключ от своего номера у портье. Альберта дает Кэнди копию ее удостоверения личности и записку с надписью «доступ только в дневное время».
  2. Кенди идет к секретарю с копией удостоверения личности Альберты и запиской. Администратор проверяет удостоверение личности и дает Кэнди специальный ключ от номера, которым можно пользоваться только в дневное время.
  3. Кенди возвращается в комнату и использует свой ключ, чтобы войти в комнату.

  • Candy - это клиент (как и Calendly.com), который хочет получить доступ к данным Альберты. Альберта предоставляет ограниченный доступ к клиенту. Разрешение на авторизацию - это копия удостоверения личности Альберты и ее примечание.
  • Администратор - это сервер авторизации, который может сгенерировать ключ от комнаты, с помощью которого Кэнди сможет получить доступ к комнате. Этот ключ от комнаты является эквивалентом токена доступа, поскольку его можно использовать для получения ресурсов.
  • Блокировка комнаты - это сервер ресурсов, поскольку он содержит ресурс, к которому Кэнди хочет получить доступ (комната).

Существует несколько различных потоков, которые предлагает OAuth 2.0, этот пример соответствует потоку кода авторизации. Мы поговорим о различных потоках в другом посте.

Токены OAuth

Как упоминалось выше, в конце потока клиент получает токен доступа. Как правило, эти токены доступа недолговечны. Что произойдет, когда срок их действия истечет?

Недолговечные токены доступа и долгоживущие токены обновления

На шаге 4 сервер авторизации может сгенерировать два токена: токен доступа и токен обновления. Токен доступа недолговечный и должен длиться от нескольких часов до пары недель.

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

Токен доступа

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

Итак, как выглядит токен JWT? Веб-токены JSON (JWT) - это подписанный объект JSON. Это означает, что вы можете доверять данным, содержащимся в объекте JSON, проверив подпись. Для авторизации пользователя вы можете указать его идентификатор и адрес электронной почты в JWT.

Когда вы передаете токен доступа JWT серверу ресурсов (вашему внутреннему серверу API), ваш сервер может проверить токен JWT без необходимости доступа к базе данных, чтобы проверить, действителен ли он.

Все, что нужно сделать вашему серверу, - это подтвердить, что токен JWT действителен с помощью библиотеки, увидеть идентификатор пользователя, который делает запрос с помощью токена, и поверить в то, что этот идентификатор пользователя уже аутентифицирован.

Обновить токен

Продление токена доступа с помощью токена обновления

Токен обновления - это специальный токен, который используется для получения нового токена доступа. Поскольку это долгоживущий, токены обновления обычно представляют собой непрозрачные строки, хранящиеся в базе данных. Сохранение токенов обновления в базе данных позволяет отозвать их, удалив из базы данных.

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

Как реализовать OAuth 2.0 для вашего сайта

Звучит много, но вы можете реализовать OAuth 2.0 и авторизовать запросы API с помощью токенов доступа с помощью Cotter всего за всего несколько минут!

Ваш веб-сайт в качестве клиента, Cotter в качестве сервера авторизации

Что касается потока OAuth, описанного ранее, вот как это выглядит:

  • Ваш сайт - клиент
  • Ваш пользователь - владелец ресурса
  • Cotter - сервер авторизации
  • Ваш внутренний сервер - это сервер ресурсов

Вход в систему и создание токенов доступа

У нас есть несколько 5-минутных кратких инструкций по аутентификации пользователей и генерации токенов доступа:

В этом руководстве мы будем использовать React в качестве примера. Мы создадим форму входа с магической ссылкой электронной почты и получим токен доступа в конце процесса.

Импорт Cotter:

yarn add cotter

Инициализировать и показать форму входа по электронной почте:

Вы можете получить свой API_KEY_ID из панели управления, создав бесплатную учетную запись.

Вот и все. Найдите в журналах консоли токен доступа.

Вышеупомянутая функция охватывает шаги 1–4 в потоке OAuth 2.0. Ответ от showEmailForm() возвращает токен доступа. Как описано выше, вы должны затем использовать этот токен доступа для доступа к ресурсу на вашем внутреннем сервере.

Например, вы можете включить этот токен доступа в свою конечную точку /api/private-resource, и вы проверите, действителен ли токен доступа, прежде чем продолжить выполнение запроса.

Что дальше?

Теперь, когда вы знаете, как получить токены доступа, вот еще несколько вещей, чтобы завершить процесс входа в систему.

Вопросы и отзывы

Если вам нужна помощь или у вас есть отзывы, пожалуйста, оставьте комментарий здесь!

Этот пост написан командой Cotter - беспарольный вход на ваш сайт или в приложение.