Авторизація на сайті через Google

Сервіс Google Акаунти дозволяє через протокол OAuth 2.0 реалізувати авторизацію користувача на своєму сайті. Після проходження авторизації можна отримати ім'я, прізвище, e-mail та зображення користувача.

Реєстрація програми

Далі, перейти в розділ "API та сервіси" → "Вікно запиту доступу OAuth".

І заповнити форму, в якій потрібно вказати: назву програми, email для зв'язку, домен вашого сайту, посилання на головну сайту та політику конфіденційності.

Після надсилання форми буде запропоновано створити обліковий запис, у списку потрібно вибрати "Ідентифікатор клієнта OAuth".

Тип: веб-додаток, в URI перенаправлення потрібно вказати адресу вашого PHP скрипта-обробника, наприклад https://example.com/login_google.php .

Після цього отримаємо індифікатор клієнта та ключ.

Посилання для входу

Сформуємо посилання для авторизації користувача:

Перейшовши за таким посиланням побачимо наступний запит:

Код скрипту

Після підтвердження запиту, буде виконано редирект на зазначений PHP-скрипт, GET-параметр додасться код авторизації, змінюємо його на токен і отримуємо дані користувача.

 'ІНДИФІКАТОР_КЛІЄНТА', 'client_secret' => 'СЕКРЕТ_КЛІЄНТА', 'redirect_uri' => 'https://example.com/login_google.php', 'grant_type' => 'authorization_code', 'code' => $_ code'])); $ch = curl_init('https://accounts.google.com/o/oauth2/token'); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, $params); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); curl_setopt($ch, CURLOPT_HEADER, false); $ data = curl_exec ($ ch); curl_close($ch); $ data = json_decode ($ data, true); if (!empty($data['access_token'])) < // Токен отримали, отримуємо дані користувача. $params = array( 'access_token' =>$data['access_token'], 'id_token' => $data['id_token'], 'token_type' => 'Bearer', 'expires_in' => 3599 ); $info = file_get_contents('https://www.googleapis.com/oauth2/v1/userinfo?' . urldecode(http_build_query($params))); $ info = json_decode ($ info, true); print_r($info); > >

Array( 'id' => '123456789123456789', 'email' => '[email protected]', 'verified_email' => true, 'name' => 'Іван Іванов', 'given_name' => 'Іван', 'family_name' => 'Іванів', 'picture' => 'https://. /photo.jpg', 'locale' => 'ru' >

До речі, Ім'я та Прізвище користувача можуть бути не вказані.

Як увімкнути двоетапну автентифікацію в Google (YouTube, Gmail), щоб захистити обліковий запис?

Під час роботи в Інтернеті не можна ігнорувати питання безпеки. Ваші логіни-паролі можуть бути використані зловмисниками для отримання вигоди. Невипадково багато сервісів, що зберігають конфіденційну інформацію або доступ до фінансів, рекомендують використовувати двоетапну або двофакторну авторизацію. Звучить це досить жахливо.Давайте розберемося, як можна захистити свій обліковий запис в Google (YouTube, Gmail) за допомогою двоетапної автентифікації.

Навіщо потрібна двоетапна автентифікація?

Двоетапна аутентифікація потрібна для забезпечення якісного захисту облікового запису. Внаслідок використання такого інструменту зловмисники не зможуть увійти до облікового запису, навіть знаючи від неї пароль. Після активації такого захисту для входу до облікового запису будуть потрібні додаткові дії, що підтверджують власника облікового запису. Це може бути SMS-повідомлення або голосовий дзвінок на доданий номер телефону, системне повідомлення, використання резервних кодів або спеціальної програми захисту.

Як увімкнути двоетапну автентифікацію в Google (YouTube, Gmail тощо)?

2. На панелі навігації зліва знайдіть та натисніть на «Безпека».

3. Знайдіть у центральній частині вікна розділ «Вхід до облікового запису Google», натисніть там на «Двоетапна автентифікація», а потім «Почати».

4. Продовжуйте виконувати інструкції на екрані.

Примітка. Зверніть увагу, що якщо ви працюєте з обліковим записом організації або навчального закладу, то двоетапна автентифікація для нього може бути і недоступною. У цій ситуації вам варто звернутися до адміністратора, який керує в цій організації доступом до сервісів Google.

Як відбувається другий етап підтвердження особистості

Перший етап проходження авторизації зрозумілий – треба ввести пароль від свого облікового запису.

Якщо пароль введено правильно, то двоетапна автентифікація вимагатиме підтвердження особистості. На цьому етапі можна вибрати один із кількох доступних варіантів перевірки.

Сама компанія Google рекомендує для входу в обліковий запис задіяти сервісні повідомлення в будь-якій програмі компанії.Для їх одержання потрібно використовувати вже авторизований обліковий запис Google у програмі Smart Lock або Gmail, «Фото», YouTube, Google. Якщо пізніше буде здійснено вхід і на іншому сумісному телефоні, то автоматично повідомлення від Google надходитимуть туди, доки не буде здійснено там вихід з облікового запису.

• Отримавши повідомлення, ви можете дозволити вхід, просто натиснувши «Так, це я».
• Якщо потрібно заблокувати вхід, натисніть варіант "Ні, заборонити вхід".

Отримане повідомлення у програмі YouTube на довіреному пристрої

Іншим найпоширенішим варіантом підтвердження особи є отримання голосового повідомлення або SMS на підтверджений номер телефону.

Методи створення авторизації на сайті. Посібник з прикладами. Безпека у браузері

У цій статті ми розберемо 4 способи, як зареєструвати нового користувача:

1. Сторонні сервіси авторизації (такі як Google)
2. Авторизація з використанням токенів
3. Авторизація за допомогою номера телефону
4. Логін + Пароль

Стаття дасть конкретний алгоритм реалізації кожного способу. Необхідні бібліотеки та приклади коду. Я постараюся наводити приклад реалізацію на чистому JavaScript, для того щоб ви змогли впровадити функціонал у свій проект, незалежно від використовуваного фреймворку, однак також будуть приклади для тандему Angular + Asp .Net Core. Ми обговоримо, як захистити ваш сайт від злому. Наскільки це складно і чи можливо гарантувати 100% захист. Отже, давайте приступимо.

Реєстрація. Аутентифікація. Авторизація.

І перш ніж підходити до конкретних прикладів, давайте розберемося які процеси відбуваються в момент, коли користувач натискає на кнопку Sign In і Sign Up.

Почнемо з процесу реєстрації. Перед вами форма з кількома полями: Ім'я, Логін, Пароль, Прізвисько вашого собаки і т.д. Ви покірно заповнюєте всі поля із зірочками, після чого клацаєте на кнопку “Зареєструватися”. Ваші дані відправляються на сервер за допомогою HTTP, сервер створює в базі даних новий запис, і якщо все проходить успішно, ви зареєструвалися в системі. Тобто процес реєстрації - це просто збереження на сервері "у певному текстовому файлі" даних, які ви заповнили на сайті.

Це приклад найпростішого способу реєстрації, який тільки можна уявити. Насправді так ніколи не роблять, але загальний принцип незмінний. Докладніше, як відбувається процес реєстрації в сучасних системах, ми розберемо пізніше, а тепер поглянемо на процес авторизації.

Коли ви заходите в свій обліковий запис у соціальній мережі, то у вас відображаються лише ваші фотографії, відео та пости. Те саме відбувається, для будь-якої іншої людини і це не здається дивним. Але всі дані, про те, скільки у вас картинок, історію повідомлень і навіть рекомендації, які заточені саме під вас, потрібно десь зберігати. Зберігати їх потрібно очевидно на сервері, тому що якщо зберегти ці дані в браузері, то вони будуть доступні вам тільки з одного пристрою (де ви реєструвалися). Як уже було сказано, під час реєстрації, для кожного користувача створюється "файл" на жорсткому диску сервера, в якому зберігатимуться всі дані.У момент авторизації, дані, введеного вами логіну та паролю відправляються на сервер, де серед усіх файлів, що відносяться різним людям по логіну, шукається саме ваш, після чого перевіряється чи відповідає відправлений пароль, тому що збережений у файлі і якщо так, то в браузер повертаються необхідні дані користувача. Тобто процес авторизації – це отримання із сервера потрібних даних про користувача.

Різниця між автентифікацією, ідентифікацією та авторизацією

За великим рахунком, це різні етапи одного процесу (надання доступу користувачеві).

І хоч усі ці етапи і поділяють, але зазвичай у процесі реалізації – це може бути просто 3 різних методу (функції), які у додатку послідовно.

Поділ також потрібен для тих випадків, якщо ви можете опустити якийсь із етапів (і виконати тільки 2 інших). Наприклад, користувач пройшов усі 3 етапи та отримав токен доступу. Токен підтверджує той факт, що людина пройшла аутентифікацію, а отже, при наступному зверненні можна опустити цей етап. Backend додаток повинен буде тільки перевірити id користувача (зберігається в токені) і по id дістати права.

Далі під словом "авторизація" (для простоти) мається на увазі весь процес отримання доступу.

Що являє собою база даних?

Вище я писав про чудовий текстовий файл, в якому зберігаються всі дані користувачів. Ви, безумовно, можете організувати зберігання даних у звичайних .txt файлах, але на практиці так ніхто не робить. Дане формулювання було використане для того, щоб ви розуміли, що ваші дані зберігаються на жорсткому диску, так само, як ви зберігаєте у себе на комп'ютері фотки, записи та відео.

Але використовують із цією метою певні програми “Бази даних”. База даних – це програма, яка працює у фоновому режимі, функціями якої можна користуватися з інших програм (написаних вами). Що це за функції? - якщо коротко, то це операції збереження та отримання даних, але на відміну від звичайного текстового файлу, база даних виконує операції збереження та отримання набагато швидше (Особливо коли цих даних стає дуже багато).

Таким чином роботу backend програми можна уявити, як роботу 2-х незалежних програм:

1. Серверний додаток – програма, яка відповідає за функціонал сервера
2. База даних – програма, яка відповідає за керування даними, та яку використовує серверний додаток. База даних не може використовувати функціонал серверної програми.

Чому сучасні програми не використовують логін + пароль для авторизації.

Тут потрібно зазначити, що природно на будь-якому сайті, який вимагає авторизації, ви повинні ввести свій логін і пароль, для того щоб увійти. Однак йтиметься про те, чому ці дані намагаються не використовувати в чистому вигляді і вкотре не обмінюватися ними з сервером для отримання додаткових даних сайту.

Основний момент – забезпечення безпеки. Давайте поглянемо на основні методи, за допомогою яких зловмисники можуть отримати доступ до вашого облікового запису:

• Фішинг – хакери можуть створити копію сайту, на якому ви введете свій логін та пароль. Після чого ці дані зберігаються на сервері зловмисників, і вони можуть увійти до вашого облікового запису, використовуючи їх. Сюди входять різні дзвінки від співробітників банку, які просять надати інформацію.
• Перебір паролів автоматичними програмами.
• Перехоплення трафіку – для того, щоб залогінитись на сайті, потрібно відправити на сервер логін та пароль за допомогою HTTP , які можуть бути перехоплені хакерами.
• XSS – вставка на сайт шкідливого JS коду, який змінюватиме логіку програми.

Який би метод авторизації ви не використовували, він не врятує від злому, якщо будуть використані фішинг або перебір паролів. Просто тому що в першому випадку ви "з власної волі" кажете свій пароль, а в другому цей пароль у вас "відгадують". Але в будь-якому випадку хакери дізнаються ваші дані для входу в тому вигляді, в якому ви їх використовуєте. А значить для програми тепер ви нічим не відрізняється (Ну хіба що IP з якого відбуватиметься вхід). Тут єдина міра захисту - це дивитися на якому сайті ви вводите пароль та використовувати складний пароль. "Удосконалені" методи авторизації рятують саме в тих випадках, коли зловмисники намагаються опосередковано отримати ваші дані (наприклад, перехопленням трафіку).

У чому проблема авторизації за допомогою логіну

Для отримання будь-яких даних вашого користувача потрібно довести серверу, що ви – це ви (ввівши пароль та надіславши його на сервер). Таким чином, у такій моделі авторизації web-додаток щоразу обмінюватиметься логіном і паролем із сервером за необхідності, а це небезпека перехоплення. На додаток до цього логін та пароль доведеться десь зберігати (щоб використовувати їх у наступних запитах до сервера. Інакше доведеться постійно просити користувача ввести пароль при переході на нову сторінку) – отже є можливість отримання доступу до цих даних у разі використання XSS.

Щоб уникнути даних проблем у процесі авторизації, використовують спеціальні ключі – токени, які з одного боку не містять приватних даних (паролей), а з іншого допомагають серверу ідентифікувати користувача.

Використання токенів у процесі авторизації

Токен являє собою простий рядок із символів, на прикладі цього:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJPbmxpbmUgSldUIEJ1aWxkZXIiLCJpYX QiOjE2Nzc5MTcxOTYsImV4cCI6M 1wbGUuY29tIiwic3ViI joianJvY2tldEBleGFtcGxlLmNvbSIsIkdpdmVuTmFtZSI6IkpvaG5ueSIsIlN1cm5hbWUiOiJSb2Nr ZXQiLCJFbWFpbCI6Impyb2NrZXRAZXhhbXBsZS5jb20iLCJSb2xlIjpbIk1hbmFnZXIiLCJQcm9qZWN 0IEFkbWluaXN0cmF0b3IiXX08 H-IkDGRs

Давайте коротко опишемо етапи авторизації за допомогою токена:

1. Введення логіну та пароля.
2. Шифрування (перетворення логіна та пароля в закодований рядок).
3. Передача шифрованих даних на сервер.
4. Генерація сервером токена доступу, за допомогою якого web-додаток буде звертатися до backend додатку для отримання даних.
5. Надсилання токена назад до браузера.
6. Збереження токена в локальному сховищі або куки, для подальшого використання.

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

Перш ніж занурюватися в деталі кожного етапу, погляньмо на те, які типи авторизації з використанням токенів існують. Всі типи можна розділити на 2 групи, які різняться способом генерації доступу токена:

Авторизація на самому сайті

У цьому випадку логін і пароль, вводяться на тому сайті, на якому ви зараз знаходитесь, після чого вони кодуються і відправляються на сервер, де генерується токен і повертається на сайт.

Авторизація на сторонньому сервісі (Gmail)

Тут користувача перекидає на сторонній ресурс (відкривається нова вкладка або вікно браузера), де вводить дані авторизації. Цей метод відрізняється тим, що по-перше – це набагато простіше для користувача. А по-друге – не потрібно вводити дані від вашого облікового запису (наприклад від облікового запису Google), на невідомому сайті, який запитує реєстрацію. Користувач вводить свої дані, сторонній сервіс (у нашому випадку Gmail) генерує токен доступу і відправляє його на сайт, з якого перейшов користувач. Після цього сайт працює вже не з вашими авторизаційними даними від сервісу, а з токеном.

Етапи такої авторизації описуються у стандартах – OAuth та OAuth 2.0. Обидві версії описують той самий алгоритм, але 2 версія – більш захищена.

Алгоритм авторизації – докладно.

1. Після того, як користувач ввів свої дані, бажано їх закодувати, щоб не передавати по мережі в простому текстовому вигляді. Тут можна використовувати будь-який алгоритм шифрування, можна навіть закодувати в прості Base64 рядок. Справа в тому, що з браузера не вийде зашифрувати дані так, щоб гарантувати їхню 100% безпеку при передачі через мережу, тому для цього потрібно використовувати якийсь ключ, який знає і сервер і браузер (щоб перший зміг закодувати, а другий декодувати). Але оскільки будь-які дані в браузері – публічні і за бажанням код у браузері можна подивитися, то і цей ключ хакери можуть потенційно перехопити. Таким чином ми хоч і кодуємо дані під час передачі з браузера, але при бажанні та належних знаннях цю інформацію можна дізнатися. Тому момент передачі логіну та паролю пов'язаний з певними ризиками.
2. Отже авторизаційні дані прийшли на сервер.Бекенд додаток декодує отримані дані та додає новий запис з вашими даними у БД (базу даних). Після цього у відповідь повертається рядок (токен). Особливість цього рядка в тому, що він закодований за допомогою унікального ключа, який відомий, тільки бекенд додатку. Усередині цього рядка закодовані якісь дані і ніхто, крім сервера (навіть клієнтський додаток), не може дізнатися щось за дані (для цього потрібний ключ).
3. Токен повертається на клієнт і якщо надалі браузер захоче запитати дані, він разом з http запитом повинен буде відправити токен, який буде декодований на сервері, щоб переконатися що ви це ви. І що токен не був змінений у процесі (якщо його змінити, то сервер не зможе декодувати його, що сигналізуватиме про потенційну спробу злому).
4. Токен може передаватися будь-яким способом. Ви можете помістити його в тіло (Body) http запиту, передати через куки або Header. Тут мета просто доставити цей рядок на сервер. При цьому зазвичай токен відправляється як додатковий заголовок хедера:

Для передачі токена використовують хедер, тому що це по-перше, зручніше, тому що вам не потрібно модифікувати структуру кожного вашого запиту і поміщати його в Body. А по-друге, багато бібліотек, що реалізують авторизацію, працюють саме з хедером запиту.

JWT(JSON Web Token)

Як ми з'ясували будь-який токен являє собою рядок. І кожен додаток, який реалізує процес авторизації, може на власний розсуд використовувати будь-яку структуру токена. Для браузерної авторизації найчастіше використовують JWT токен. Це просто деякий загальноприйнятий стандарт.

Що являє собою цей стандарт? Як можна здогадатися з назви, цей стандарт заснований на JSON і дозволяє передавати разом з токеном будь-який JSON об'єкт (а оскільки ми можемо будь-які дані подати як об'єкт, який буде перетворений на JSON, то всередині JWT можна передавати все що завгодно).JWT складається з 3-х частин:

1) Header

2) Payload

3) Унікальний ключ для шифрування

Виходить, у нас є об'єкт, що складається з 3-х полів. У хедері ми вказуємо, що за тип токена ми використовуємо і як кодуватимуться дані. У секції payload – дані, які ми хочемо передавати із сервера на клієнт та назад. А унікальний ключ – це пароль, за допомогою якого ми кодуємо 2 попередні частини та перетворюємо їх на рядок.

Ключ завжди зберігається тільки на сервері. І клієнтська програма не має до нього доступу. Таким чином гарантується, що змінити токен може лише додаток, у якого є цей ключ (тобто тільки сервер). Тут важливо, що саме ЗМІНИТИ, тому що декодувати токен і отримати з нього header і payload може будь-хто, хто отримав цей токен. Ці дані є публічними.

Спочатку ми перетворюємо header і payload на base64. Далі використовуємо алгоритм шифрування з бібліотеки Crypto Js, для того щоб закодувати два отримані base64 рядки і отримати сигнатуру (яка теж є рядком). Після чого просто об'єднуємо 3 отримані рядки в один, розділяючи крапками.

Як ви могли помітити всередині сигнатури закодована інформація про хедер та payload. Це потрібно для того, щоб сервер отримує токен від клієнта, він за допомогою свого ключа декодував би сигнатуру і порівняв чи відповідають дані всередині сигнатури, тим, які зберігаються всередині payload.І якщо дані відрізняються або взагалі не вдалося декодувати їх, то це є ознакою того, що дані могли перехопити і змінити. Відповідно запит не проходить валідацію та у відповідь повертається помилка.

Access та Refresh токени

На даному етапі ми з'ясували, що таке JWT, яку структуру має, а також як відбувається валідація токена. Хакери не можуть змінити дані нашого токена (і вставити, наприклад, свої). Але перехопити токен і використовувати його для доступу до облікового запису, можуть. Адже токен містить всі потрібні дані для авторизації і будь-яка людина, яка отримала до нього доступ, не відрізнятиметься для сервера від справжнього власника облікового запису.

Для вирішення цієї проблеми існують Access та Refresh токени. Тут ми починаємо використовувати якийсь новий спосіб авторизації. Використовується все той же JWT, але тепер єдиний токен, який у нас був ми називаємо Access Token, при цьому в додатку до нього з'являється другий Refresh токен, який також являє собою рядок, має однакову структуру з Access Token, тому може зберігати всередині які дані (хоч і не обов'язково і зазвичай це не потрібно).

Важливо те, що у Access і Refresh токенів з'являються обов'язкові поля всередині їхнього payload (iat, exp). Про їх існування я вже згадував, але коли ми маємо лише 1 токен, то ці поля за великим рахунком не використовуються і містять додаткову інформацію.

Iat (issued at time) – час, коли токен згенеровано.

Exp (expiration time) – час, до якого токен вважатиметься валідним.

Алгоритм авторизації з використанням Refresh та Access токенів.

1. Користувач вводить логін та пароль. Вони відправляються на сервер (Аналогічно з використанням одного токена).
2. Сервер створює/знаходить користувача в Базі даних, після чого генерує 2 токена (генерація відбувається за вже відомим алгоритмом), але цього разу додаються iat та exp поля. При цьому для Access Token, exp - встановлюється на короткий термін (15 -20 хвилин), а для Refresh Token, значення exp задається великим (кілька днів або тижнів).
3. Далі сервер повертає 2 токени в браузер, де вони зберігаються в локальному сховищі.
4. Тепер, якщо клієнтський додаток хоче отримати доступ до даних, то перш ніж відправляти запит з Access Token в заголовку, потрібно перевірити чи не минув його термін життя і якщо, ні, то відправляти запит, якщо ж токен expired, то перш ніж надсилати запит потрібно оновити токен (інакше сервер отримає не валідний токен і поверне помилку).
5. Щоб оновити Access Token, клієнт відправляє спеціальний запит, у якому відправляє Refresh Token. Сервер отримує цей Refresh Token і на його основі генерує нову пару Access + Refresh токенів, які повертаються на клієнт і знову зберігаються. Однак у випадку, якщо при створенні нової пари токенів, виявляється, що і Refresh Token вже застарів, то повертається помилка та користувача просять ще раз ввести свій логін та пароль.

Чому не можна обійтися одним Access токеном

Як ми раніше з'ясували, 1 токен захищає від ситуацій, коли хакери змінюють дані всередині токена (payload), але не захищають від того, що з викраденим токеном зловмисник може отримати доступ до облікового запису користувача. Refresh Token частково вирішує цю проблему.

Давайте розберемося, що у нас станеться, якщо ваші токени викрадені. Хакер отримав доступ до вашого облікового запису і може робити все що завгодно, доки ви не зайдете в систему.Тому що в цей момент закінчиться термін дії вашого Access токена і вам доведеться оновити пару токенів на нову, отже викрадені токени стануть не валідними. Або представимо ін ситуацію. Хакер провів довгий час на вашій сторінці, а значить потрібно оновити Access Token з його боку (що він успішно зробить), адже він заволодів обома (у тому числі Refresh). Отже, тепер вже коли ви спробуєте зайти в свій обліковий запис сервер поверне помилку, тому що вже ваш Refresh Token не валідний, після чого ви введете свої дані і не валідною стане пара токенів, викрадена зловмисником.

Таким чином, Access і Refresh токени не захищають повністю від злому, але сильно ускладнюють життя хакерам (бо викрадений токен не можна довго використовувати).

Де зберігати токени

Є два популярні варіанти Local Storage і куки (або всередині сесійного сховища). І зберігати пару Access і Refresh токенів краще в кукі. Це обґрунтовано тим, що якщо на сайт вбудують шкідливий код, то через JS хакери можуть отримати доступ до Local Storage, але куки не зберігаються в локальному сховищі браузера, вони передаються із запитом. Відповідно, щоб отримати до них доступ, потрібно зробити як мінімум один запит авторизації. (З невідомими логіном та паролем).

Хоча існують методики і для розкрадання даних із куки. Тут слід запам'ятати один момент. У вас не вдасться на 100% захиститися від усіх атак у браузері, але чим більше рівнів захисту ви встановите, тим менша ймовірність злому.

Авторизація через зовнішні сервіси

Загальний алгоритм додавання авторизації через сторонні послуги наступний:

1. Вам потрібно зробити редирект із свого сайту на сайт сервісу.
2. Дочекатися поки користувач введе там свої дані та сервіс згенерує токен авторизації.
3. Дочекатися HTTP respons-а від стороннього сервісу та отримати токен доступу (всередині якого зберігаються дані про користувача).
4. Надіслати отриманий токен вже на власний сервер та згенерувати пару Access+Refresh токен на основі даних користувача. Після чого зберегти їх у браузері.
5. А далі йде звичайний flow із JWT авторизацією, описаний вище.

А тепер на прикладі Gmail авторизації давайте поглянемо на деталі:

У Gmail, як і в інших схожих сервісах, перше, що вам потрібно буде зробити – це створити “Додаток” для вашого сайту на спеціальному сервісі для розробників. У кожного сервісу авторизації він свій. Для Google це Developer Console.

Як ви могли здогадатися метою створення профілю є отримання цього ключа. У гугл він називається Client Id. Client Id буде використовуватися в нашому frontend додатку. Ось як це може виглядати на TypeScript:

HTML

Sign In with Google

Type Script

DIALOG_PARAMS - Налаштування вікна, де користувач вводитиме авторизаційні дані.

googleAuthListener – слухає повідомлення від GMail і у разі успішної авторизації повертає відповідь з кодом авторизації (це не те саме, що токен, але з його допомогою можна отримати токен).

dialogUrl – URL на який переходить користувач для введення логіну та пароля.

Авторизація за номером телефону

Авторизація за номером телефону майже ідентична звичайній з використанням логіну та паролю з тією лише різницею, що тепер замість email ми використовуємо номер, а замість пароля, одноразовий перевірочний код. На цьому моменті не потрібно довго зупинятися.

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

Сервіси для надсилання Email та СМС повідомлень.

Почнемо з надсилання email. Щоб надіслати повідомлення на пошту, вам потрібен SMTP сервер (і без нього обійтися не вийде). Тут є 2 варіанти:

Варіант 1 – складний. Ви створюєте окремий сервер і налаштовуєте його, щоб він розумів SMTP протокол. Найчастіше це дуже складно і зайве.

Варіант 2 – раціональний. Ви використовуєте сторонні сервіси, які беруть на себе роботу з обслуговування SMTP сервера, а вам надають, або готовий API для відправки повідомлень, або саму адресу SMTP сервера, який ви можете використовувати.

Як ви могли здогадатися, в обох випадках насолода це не безкоштовне. Або майже не безкоштовне. У випадку з SMTP сервісами багато провайдерів надають тріал або безкоштовне використання на час розробки (тобто у вас все буде працювати, але тільки на маленьких навантаженнях). Одним із таких сервісів є SMTP.bz.

Для того, щоб відправити email за допомогою цього сервісу, потрібно зареєструватися та прив'язати домен вашого сайту (на сервісі є інструкція), після чого вам видаються логін, пароль, адреса та порт від сервера, які потрібні для підключення до SMTP. Наведу невеликий шматок коду (на C#), як надіслати Email, використовуючи SMTP сервер.

Тепер розберемося із сервісами для надсилання СМС повідомлень. У цьому випадку ми також маємо готові API для відправки смс. Наприклад – smsc.ru. Використання досить просте – надсилання http запиту з номером телефону та повідомленням.

Однак у даному випадку я не знайшов сервісів, які мають безкоштовні періоди (Напишіть у коментарях якщо ви знаєте такі) Можливо це пов'язано з тим, що в ланцюжку відправки смс також бере участь стільниковий оператор, який стягує плату за відправку з "смс сервісів".Тому вони не можуть надати безкоштовний тріал доступу, як у випадку з SMTP.

А чи потрібна вам взагалі авторизація на сайті?

Будь-яка авторизація – це дуже складно для користувача. Тому по можливості не треба дошкуляти реєстрацією. Якщо у вас лендинг, блог або інформаційний сайт, який не має на увазі особистого кабінету та рівнів доступу, то взагалі не робіть авторизації. Бо а навіщо вона вам?

Закінчуємо

Для закріплення матеріалу ви можете завантажити готовий проект, в якому реалізовані всі види авторизації, описані в статті (посилання тут опублікувати не можу, але якщо комусь дуже цікаво, можете написати в особу і я дам посилання). А також спробувати щось змінити під себе. Сподіваюся стаття була вичерпною, якщо ні, то напишіть у коментарях, що я міг упустити.