аутентифікація
Аутентифікація - процедура перевірки автентичності. Необхідно впевнитися що користувач той, за кого себе видає. В інтернеті звичайна процедура аутентифікації складається з введення логіна і пароля користувача. Загальний вигляд аутентифікації показаний на малюнку нижче.
По суті, це перший крок, який необхідно виконати в процесі входу в закриту систему. Коли користувач ввів свої дані, ми перевіряємо, чи існує користувач із затребуваними обліковими даними. Якщо користувач не знайдений, як правило, показується помилка "Користувач не знайдений".
Іноді аутентифікації буває досить, щоб отримати перевірити що користувач той, за кого себе видає (він знає секретну фразу - пароль).
- Переконатися, що надходить запит аутентифікований
- Переконатися, що користувач має права до запитуваного ресурсу.
У деяких випадках виконуються обидві дії за один крок. Останні кілька років набули поширення інші системи аутентифікації. Чи є спосіб дізнатися користувачів, які не зареєстровані в нашій системі? У такому випадку вдаються до 3-й стороні. Система A запитує у системи B перевірку автентичності користувача, в разі успішної перевірки система A передбачає що користувач є відомим. Ця концепція називається "Federated Identity". Популярні сервіси вже реалізували підтримку цієї технології.
Federated Identity
Основний FlowChart Federated Identity показаний нижче
Чому використовувати Federated Identity?
Які бувають протоколи Federated Identity? Основні використовувані сьогодні це OpenID і OAuth.
Існує 3 важливих поняття в OpenID аутентифікації:
- User - користувач, який робить запит на аутентифікацію
- Provider - система, яка зберігає дані користувача, і обробляє запити OpenID
- RelyingParty - залежна сторона, яка хоче перевірити справжність користувача.
Процес аутентифікації по OpenID описується наступними кроками:
- Користувач намагається отримати доступ до закритого ресурсу залежною боку (Relying Party);
- Залежна сторона запитує у користувача логін;
- Користувач відправляє свій URL OpenID;
- Залежна сторона перенаправляє користувача до провайдера OpenID для перевірки автентичності;
- Користувач вводить свої дані для входу;
- Провайдер OpenID аутентифікує користувача;
- У разі успішної аутентифікації, провайдер перенаправляє користувача назад до залежної стороні, включаючи ідентифікаційну інформацію;
- Залежна сторона перевіряє токен від провайдера і допускає користувача.
- User - користувач, який робить запит;
- Provider - система, яка містить інформацію про користувача і надає API для доступу до них;
- Consumer - Споживач, це 3-тя сторона, яка запитує у користувача дозвіл на доступ до інформації, щоб отримати можливість робити запити від імені користувача.
Workflow має наступний вигляд:
OpenID vs OAuth
Ясна річ, що обидві системи OpenID і OAuth мають свої переваги і недоліки. Однак можливості OAuth залучають мене більше.
Побудова системи OAuth
Один раз реалізовував свою систему OAuth. Якщо є завдання розгорнути промислову систему OAuth - краще використовувати готові бібліотеки. Для того, щоб зрозуміти як це працює або вирішити вузьке завдання можна скористатися схемою нижче.
У цьому прикладі 3 дійові особи.