Я уверен, что у вас есть одна или несколько аккаунтов в социальных сетях.
Будь то Facebook, Twitter, YouTube, Google, GitHub
или многие другие поставщики услуг, где вы зарегистрировали телефон и учетную запись.
Теперь эти поставщики услуг, в свою очередь,
готовы предоставлять услуги аутентификации от вашего имени.
Так, например, вы видите распространение ряда веб-сайтов
и мобильных приложений, в которых вам разрешено входить
с помощью ваших учетных записей в социальных сетях.
Итак, как это на самом деле работает?
Многие из этих поставщиков учетных записей в социальных сетях действуют в
качестве поставщиков услуг аутентификации, используя протокол OAuth.
Мы рассмотрим OAuth и то, как он позволяет этим сторонним поставщикам аутентификации
предоставлять аутентификацию от вашего имени,
а также позволяет вам входить в другие службы, используя свои учетные записи в социальных сетях.
Я уверен, что вы, возможно, слышали о OAuth 1 и OAuth 2 и,
возможно, слышали от людей, говорящих,
что Facebook обеспечивает аутентификацию на основе OAuth 2,
или Google обеспечивает аутентификацию на основе OAuth 2 и т. Д.
Я уверен, что вам должно быть интересно,
что именно эти OAuth1 и OAuth 2 должны быть?
Теперь OAuth1 и OAuth 2 являются фреймворками авторизации
, которые основаны на открытых стандартах.
И они могут быть использованы через Интернет для аутентификации
вашей личности на многих веб-сайтах или мобильных приложениях.
Теперь, когда вы используете эти сервисы,
вы зависите от одной из учетных записей в социальных сетях, таких как Facebook
, Google, Twitter, Microsoft, Instagram
, GitHub, Digitalocean и многие
другие, которые предоставляют эти услуги аутентификации для других пользователей.
Эти поставщики услуг аутентификации обещают
пользователям этой службы аутентификации, что они проведут
подлинность личности пользователя на основе предоставления им
своих учетных данных для этих служб социальных сетей.
Теперь есть дополнительный сервис OpenID.
Но, конечно, не связано с OAuth, но предоставляет аналогичный вид обслуживания.
Но большинство стандартных поставщиков социальных сетей,
как вы увидите здесь,
предоставляют услуги на основе OAuth 2 в наши дни.
Теперь, как я уже упоминал, OAuth1 и OAuth 2 являются протоколами аутентификации,
а OAuth 1 был первым протоколом, который появился.
Это произошло из Твиттера,
за которым стоит Блейн Кук,
и это документировано в Инженерной группе Интернета, RFC 5849.
Итак, если вы хотите прочитать подробные сведения о том, как работают эти протоколы,
это место, чтобы найти это.
Протокол OAuth 2 эволюционировал из OAuth 1, чтобы сделать его более простым
и более простым способом для разработки клиентов.
И это документировано в IETF RFC 6749, и после этого
в IETF RFC 6750 появилось еще одно использование токенов на предъявителя.
Теперь, с нашей точки зрения,
мы не хотим вдаваться в подробности того, как эти протоколы действительно работают.
Вместо этого все, что нас интересует, это то,
как мы используем их для аутентификации пользователей в нашем веб-приложении
или в нашем мобильном приложении,
когда нам нужно аутентифицировать пользователя
на экспресс-сервере, на котором мы работали до сих пор?
Теперь мы в первую очередь сосредоточимся на OAuth 2
, потому что в упражнении
мы рассмотрим использование Facebook в качестве поставщика услуг аутентификации OAuth 2,
и здесь нам нужно понять
несколько терминов, чтобы увидеть, как именно работает этот протокол OAuth 2.
По крайней мере, данные о том, как работает сам протокол.
Теперь, в случае OAuth 2,
мы всегда говорим о собственности на ресурсы.
Теперь в этом случае
ресурс, на который я имею в виду, не является
ресурсом, который хранится на сервере Express.
Вместо этого ресурс, на который мы ссылаемся здесь,
является идентификацией пользователя.
Теперь любой сервер, как и сервер Express, который мы создавали,
хочет получить доступ к этому ресурсу,
то есть вашей личности.
Итак, где ваша личность?
Ваша личность хранится на одном из
таких поставщиков услуг аутентификации в социальных сетях, как Facebook и так далее,
потому что вы уже создали учетную запись на этих сайтах социальных сетей.
Таким образом, ваша информация или ваша идентификационная информация или
информация вашего профиля хранятся, например, в Facebook.
Теперь ваш Express сервер хочет получить доступ к вашей личности и
убедиться, что это действительно вы пытаетесь получить доступ к серверу Express.
Таким образом, в данном случае,
Экспресс сервер, который мы разработали,
выступает в качестве клиентского приложения.
Таким образом, это где клиентское приложение,
то есть веб-сайт или мобильное приложение, которое хочет получить
доступ к серверу ресурсов для того, чтобы получить информацию о вас.
Что такое сервер ресурсов, о котором мы говорим?
Это сервер аутентификации OAuth Facebook,
который также предоставляет информацию о вашем профиле по запросу.
Теперь, конечно, вы не будете произвольно распространять информацию о вашем профиле.
Вместо этого вы хотите иметь возможность убедиться, что вы предоставляете доступ к
информации профиля поставщику услуг, прошедшему проверку подлинности, или серверу, прошедшему проверку подлинности.
Теперь,
например, ваше клиентское приложение или сервер Express здесь будет регистрироваться на Facebook с учетной записью, говорящей, что я управляю приложением,
и я хочу зарегистрироваться в качестве потенциального источника, который может
подойти к вам для аутентификации пользователей, когда они предоставляют
доступ к их профиль, который хранится на вашем сайте.
Таким образом, сервер Express,
в данном случае выступая в качестве клиентского приложения,
зарегистрируется на Facebook и получит ClientiD и секрет клиента от Facebook.
Теперь, когда сервер Express регистрируется на Facebook,
вам нужно иметь учетную запись на Facebook,
аутентифицированную учетную запись на Facebook,
которую вы будете использовать для настройки этого приложения на Facebook.
Итак, как только вы
зарегистрируетесь, вы получите доступ к ClientiD и секрету клиента.
Теперь сервер ресурсов,
как я уже упоминал, является сервером, на котором хранятся защищенные данные.
Защищенные данные означают профиль пользователя, который хочет получить доступ к серверу Express.
Таким образом, сервер Express хочет получить доступ к этому серверу ресурсов
и получить данные профиля пользователя, который хочет получить доступ к серверу Express.
Итак, вы видите отношения здесь.
Поэтому, когда я говорю о клиентском приложении,
я имею в виду не их интерфейсное приложение,
а их сервер Express, который пытается предоставить вам
доступ к ресурсам, которые он имеет на своем сайте.
Но серверу Express для
того, чтобы вы могли получить доступ,
потребуется доступ к вашему серверу ресурсов Facebook, который
будет аутентифицировать вас и предоставлять информацию о вашем профиле на сервер Express.
Итак, сервер ресурсов, о котором я говорю здесь,
является сервером аутентификации OAuth 2 Facebook
плюс сервер ресурсов, который дает вам доступ к информации профиля пользователя.
Сервер авторизации — это сервер, который
разрешит кому-либо получить доступ
к серверу ресурсов, чтобы получить информацию о профиле.
Теперь пользователь является тем, кто имеет информацию о профиле на сервере ресурсов.
Пользователь должен разрешить серверу Express перейти на
этот сервер ресурсов, чтобы получить информацию о профиле.
Но если пользователю нужно авторизовать Express сервер,
пользователю необходимо войти в учетную запись Facebook,
а затем получить информацию от Facebook, вызываемую как токен доступа,
который пользователь затем передаст на Express сервер.
Теперь, когда токен доступа будет получен из Facebook через протокол OAuth 2,
токен доступа будет выдан с точки зрения
разрешения этого клиентского приложения или сервера Express,
который уже зарегистрирован на Facebook и говорит, что
этот клиентский сервер я авторизую для
доступа информацию о своем профиле от своего поставщика услуг OAuth Facebook.
Так что, опять же, это немного запутанно.
Мы увидим диаграмму, где этот поток
информации разъясняется вам немного более четко.
Один момент, который я только что упомянул, касается токена OAuth или токена доступа.
Что это за токен доступа?
Токен доступа - это то, что сервер авторизации выдает для вас.
Какой сервер авторизации?
Это сторонний сервер авторизации OAuth 2,
сервер Facebook, в этом примере.
Таким образом, это приложение сервера Express.
Теперь вы, как их внешний пользователь,
хотите получить доступ к чему-то из приложения сервера Express.
Серверное приложение Express сообщит вам, что вы
аутентифицируетесь из Facebook, а затем получите токен доступа от Facebook.
Этот токен доступа выдается
пользователю front-end из Facebook, когда пользователь входит в свою учетную запись Facebook.
Теперь этот токен доступа выдается на имя клиентского приложения,
Express server, которое уже зарегистрировано на Facebook.
Таким образом, для того, чтобы пользователь мог получить доступ к Facebook, чтобы получить свой токен доступа,
пользователю требуется идентификатор клиента клиентского приложения или приложения Express.
Таким образом, этот идентификатор клиента встроен
в интерфейсное приложение, которое этот Express сервер будет обслуживать для вас.
Таким образом, сервер Express обслуживает веб-сайт, к которому вы обращаетесь,
тогда этот веб-сайт будет содержать код,
в котором идентификатор клиента этого Express сервера уже встроен там.
Еще одна информация, о которой я упоминал, является секретом клиента.
Теперь, в потоке аутентификации, о котором я собираюсь поговорить,
секрет клиента никогда никому не будет раскрыт.
Секрет клиента будет находиться только на стороне сервера Express.
Вернуться, когда сервер Express пытается аутентифицировать и
получить доступ к профилю пользователя из Facebook,
клиентское приложение, Express сервер
отправит как идентификатор клиента, так и секрет клиента,
вместе с токеном доступа, который пользователь передает ему в Facebook.
И Facebook, в свою очередь,
разрешает своему клиентскому приложению доступ к
серверу ресурсов для получения данных профиля пользователя.
И как только данные профиля пользователя будут получены с сервера ресурсов Facebook,
то мой Express сервер собирается создать учетную запись
для этого конкретного пользователя, который зарегистрировал их со своей учетной записью Facebook.
А затем, впоследствии, предоставить пользователю веб-токен JSON,
который пользователь может затем использовать для доступа
к ресурсам, хранящимся на сервере Express.
Итак, опять же, чтобы обобщить это,
у меня есть диаграмма, чтобы объяснить вам это немного более подробно.
В дополнение к этому,
есть также токен обновления.
Когда токен доступа выдается сервером Facebook OAuth 2,
токен доступа имеет ограниченный срок службы.
После этого токен доступа станет недействительным.
Таким образом, токен доступа должен быть сохранен конфиденциальным.
Таким образом, весь этот обмен токенами между различными сайтами
будет осуществляться в зашифрованном материале с использованием протокола HTTPS.
Поэтому убедитесь, что когда вы отправляете свой токен доступа из
вашего пользовательского интерфейса на сервер Express,
вы будете отправлять токен доступа только через HTTPS, а не HTTP.
Это очень важно, потому что вы не
хотите, чтобы ваш токен доступа был раскрыт никому, потому что любой,
кто может получить один из ваших токенов доступа, может притвориться
своим клиентским приложением, а затем получить доступ к вашему профилю пользователя.
Так что это очень важно.
Теперь, поскольку токен доступа имеет ограниченное время жизни,
существует также соответствующий токен обновления,
который можно использовать для обновления токена доступа с истекшим сроком службы.
Теперь, в виде потока, который мы собираемся
использовать с нашим приложением в упражнении,
мы не сможем использовать токен обновления.
Каждый раз, когда пользователь захочет разрешить
серверу Express перейти и получить информацию профиля из Facebook,
пользователю придется явно предоставить
новый токен доступа, полученный из Facebook.
Одна часть, которую я только что упомянул кратко,
но я не разработал,
заключается в том, как клиентское приложение, сервер Express,
масштабируется, как он регистрируется в поставщике услуг OAuth 2?
Теперь, здесь многие из поставщиков услуг OAuth 2
предоставляют способ регистрации приложения на своем сайте.
Таким образом, клиентское приложение,
экспресс-серверы в нашем примере,
будет регистрироваться как клиентское приложение на поставщике услуг OAuth.
Таким образом, как вы увидите в упражнении,
самый первый шаг, который мы сделаем, это войти в Facebook с
нашей учетной записью, а затем создать приложение на сайте Facebook.
Когда вы это сделаете, Facebook выдаст вам идентификатор клиентского приложения и секрет клиента.
Эта процедура применяется ко многим другим поставщикам услуг OAuth, поскольку
это общий поток, о котором говорит протокол OAuth 2.
Таким образом, идентификатор клиентского приложения и секрет клиента полезны для нас,
чтобы иметь возможность доказать нашу личность
серверу OAuth, когда мы передаем токен доступа, который мы получаем от пользователя.
Теперь есть также URL-адрес перенаправления, который вам нужно
зарегистрировать при регистрации клиентского приложения,
и вы увидите, что я выполняю это в шагах, которые я регистрирую
приложение на сайте Facebook.
Итак, подытоживая информационный поток
, о котором мы только что кратко говорили в предыдущем случае,
позвольте мне начать с этого момента.
Первый момент, на который нужно обратить внимание, это владелец ресурса.
Таким образом, владельцем ресурса является пользователь, который
собирается использовать свою учетную запись в социальных сетях.
Facebook, в этом примере,
имеет аутентификацию для пользователя.
Таким образом, владелец ресурса - это тот, который имеет профиль о ресурсе.
И эта информация профиля для каждой учетной записи Facebook,
они хранились на сервере Facebook.
Таким образом, сервер Facebook предоставляет сервер ресурсов здесь.
Так что это поставщик услуг OAuth, который вы видите
в правой части этой картины здесь.
Представьте себе сервер Facebook с правой стороны, это клиентское приложение,
которое имеет оставшийся сервер API,
экспресс-сервер, который мы реализовали,
в этом случае является клиентским приложением,
а владельцем ресурса является пользователь.
URL переднего плана пользователя, который собирается
разрешить вам перейти в Facebook, чтобы проверить учетные данные этого пользователя.
Поэтому, когда вы хотите получить доступ к информации на стороне клиента,
вам сначала придется пойти и
авторизовать это клиентское приложение,
чтобы иметь возможность получить доступ к информации вашего профиля.
Таким образом, клиентское приложение,
если оно действует как веб-приложение,
оно предоставит соответствующую кнопку там, говоря войти в систему с помощью Facebook.
И поэтому, когда вы нажимаете на кнопку
, по сути, начинается первый шаг.
Запрос авторизации пользователя инициирован.
Таким образом, ваше клиентское приложение
, через
агент пользователя, в основном клиентское приложение, клиентское приложение.
Это может быть приложение Angular, которое мы разработали, или
это мобильное приложение, будь то Ionic или это
приложение NativeScript, которое мы разработали на курсах ранее в
специализации или даже собственное приложение, например приложение для iOS или приложение для Android.
Все они действуют в качестве агента пользователя.
Таким
образом, пользовательский агент использует процесс запроса авторизации через
пользовательский агент на сервер авторизации,
который является сервером Facebook.
Теперь, когда это будет передано,
тогда владелец ресурса или пользователь,
который пытается предоставить доступ к своему профилю для этого клиентского приложения,
должен будет разрешить Facebook, чтобы иметь
возможность делиться этой информацией с клиентским приложением.
В неявном подходе гранта потока, который мы используем в
нашем примере здесь, а также в следующем упражнении,
неявный подход гранта потока является
наиболее подходящим подходом, когда вы реализуете веб-приложение с использованием
фреймворка, такого как Angular или гибридное мобильное приложение
с Ionic или NativeScript или даже собственное приложение.
Подход неявного гранта потока является гораздо более простым способом
работы OAuth 2 для таких приложений.
Таким образом, владелец ресурса нажимает на кнопку входа,
затем сервер авторизации предложит владельцу ресурса информацию, говорящую:
«Это клиентское приложение хочет получить доступ к информации вашего профиля.
Вы разрешаете это?»
И так это будет всплывать Facebook,
а затем вы нажмете на кнопку, говорящую: «Да,
я разрешаю этому клиентскому приложению получить доступ от моего имени».
Таким образом, на этом этапе
сервер авторизации на Facebook,
сервер авторизации OAuth 2 на Facebook,
будет генерировать токен доступа.
Чтобы сгенерировать этот токен доступа,
он будет использовать идентификатор клиента для этого клиентского приложения, приложение
Express сервера, которое мы регистрируем.
Таким образом, идентификатор клиента должен быть частью пользовательского агента, который использует этот пользователь.
Таким образом, этот идентификатор клиента будет встроен в приложение Angular, приложение
Ionic или приложение NativeScript или даже приложение iOS или Android.
Таким образом, идентификатор клиента будет использоваться
пользовательским агентом для поворота сервера авторизации, говорящего:
«Это клиентское приложение хочет получить доступ к моему профилю,
и я готов разрешить вам доступ к профилю».
Таким образом, в этот момент
сервер авторизации отправит маркер доступа агенту пользователя в этом случае.
Итак, помните, этот токен доступа приходит в пользовательский агент,
который является мобильным приложением или их угловым приложением, которое реализуется нами.
Затем этот пользовательский агент возьмет этот токен доступа, а
затем передаст этот токен доступа этому клиентскому приложению.
Таким образом, OAuth для входа в систему,
но токен доступа будет передан клиентскому приложению,
в этом случае экспресс-серверу,
на определенном маршруте на маршрутизаторе пользователя,
маршруте аутентификации на сайте клиентского приложения.
Теперь, ранее, мы видели использование локальной аутентификации,
где мы отправили запрос на косую черту пользователя войти в систему.
Теперь, чтобы это работало в нашем приложении,
мы настроим еще один на пользователей косой черты,
косой черты Facebook, токен косой черты и так далее.
Таким образом, еще один URL-адрес, на котором мы предоставляем этот токен доступа к серверу Express.
Теперь, когда этот токен доступа будет получен экспресс-сервером,
экспресс-сервер возьмет этот токен доступа,
а затем вместе со своим идентификатором клиента и секретом клиента,
он отправит эту информацию на сервер авторизации.
Затем сервер авторизации позволит своему клиентскому приложению получить
доступ к серверу ресурсов, чтобы получить информацию о профиле.
Таким образом, информация о профиле будет отправлена обратно в шестом шаге,
в этом случае обратно в клиентское приложение.
Поэтому, когда клиентское приложение получает информацию о профиле для пользователя,
клиентское приложение создаст новую учетную запись для
пользователя на каждом сайте, если учетная запись не существует.
Если этот пользователь уже вошел в систему ранее, используя свой идентификатор Facebook,
учетная запись уже будет существовать, чтобы клиентское приложение и сервер API Rest
просто проверили, что эта учетная запись уже существует.
И, в этот момент,
пользователь проходит аутентификацию для стороннего входа в систему,
предоставляемую сервисом аутентификации OAuth 2 Facebook.
В этот момент клиентское приложение будет генерировать JSON Web Token,
в примере, который мы будем реализовывать и осуществлять,
а затем передать этот JSON Web Token обратно пользовательскому агенту или интерфейсному приложению,
или угловому приложению, или приложению Ionic,
или приложению NativeScript.
Затем JSON Web Token будет впоследствии использоваться пользователем
для аутентификации себя всякий раз, когда он или она хочет
получить доступ к любым ресурсам, хранящимся на сервере Express.
Итак, как только вы получите JSON Web Token,
все последующие операции, вы уже видели, как это сделать с помощью JSON Web Token.
Таким образом, как только вы получите JSON Web Token
, ваша работа выполнена,
и затем вы можете продолжить нормальную работу с этой точки.
Теперь, когда истекает срок действия JSON Web
Token, вы должны пройти весь процесс повторной аутентификации себя и,
впоследствии, разрешить пользователям доступ к информации на вашем сайте.
Итак, с этим быстрым пониманием того, как работают операции OAuth 2
, опять же, как вы видите, здесь много деталей.
Но, к счастью, нам не нужно иметь дело со всеми этими деталями, потому что мы будем
использовать модуль узла, который заботится о большей части этих деталей от нашего имени.
Так как мы уже настроили наш Express сервер для использования Passport,
теперь мы можем использовать другой код модуля узла в качестве модуля Passport-Facebook-Token.
Модуль Passport-Facebook-Token по существу реализует
неявный подход к гранту, о котором я говорил ранее.
Затем вы можете инициализировать
новую стратегию в вашей стратегии Passport в вашем приложении. Кроме
того, модуль Passport-Facebook-Token позволяет настроить
новую стратегию аутентификации Passport для использования API OAuth 2 на основе Facebook.
И поэтому, чтобы использовать этот модуль,
вы устанавливаете это, сказав прошлый npm install pasport- facebook-token
, минус save, а
затем, как только вы установили это, то вы настроете стратегию Facebook в своем приложении, и, после этого,
используйте это для настройки стратегии для вашего Passport,
чтобы использовать, если мы используем аутентификацию на основе OAuth 2 для нашего приложения.
С этим быстрым пониманием OAuth 2,
давайте
перейдем к упражнению, где мы настроим наш Express сервер, чтобы действительно использовать
этот неявный грант подход, чтобы позволить нам
проверить нашу личность на сервере Express и,
после этого, получить доступ к ресурсам, блюдам,
рекламные акции и информацию лидеров, хранящуюся на нашем сервере Express.