Аутентифікація і авторизація в мікросервісних додатках

1. Вступ Це вступна частина матеріалу, заснованого на доповіді, прочитане мною минулого літа. Друкований...
2. способи аутентифікації
3. HTTP Basic Authentication
4. HTTP Digest Authentication
5. Forms Authentication
6. Token Authentication
7. OAuth2 & Open ID Connect
8. Розбираємося детально ху із ху
9. погляд зверху
10. Термінологія OAuth2 & OpenID Connect
11. клієнт
12. Користувач
13. Область (scope)
14. Запит на аутентифікацію
15. токен особистості
16. токен доступу
17. токен поновлення
18. процес аутентифікації
19. структура токена
20. Основні поля
21. Висновок першої частини
22. Спойлер другій частині

Вступ

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

Ми розберемося з процесом аутентифікації користувача, роботою технології єдиного входу (Single sign-on / SSO), дамо загальне уявлення про технології OAuth2 і принципах її роботи, не заглиблюючись в особливості конкретної технічної реалізації. У наступній статті як приклад вдалої реалізації ми розглянемо бібліотеку Thinktecture Identity Server v3, докладніше зупинимося на її функціональні можливості, поговоримо, як зібрати мінімальний набір компонент, необхідний для роботи в мікросервісной архітектурі і гідний використання в бойовій системі. У третій частині ми покажемо, як розширювати цю бібліотеку, підлаштовуючись під потреби вашої системи, а завершить цикл статей розбір різних сценаріїв, що зустрічалися в житті багатьох розробників з рекомендаціями для кожного випадку.

Що таке аутентифікація?

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

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

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

способи аутентифікації

При використанні HTTP-протоколу найпростіший спосіб аутентифікації - Basic access authentication. В принципі цей протокол застарів і вже рідко використовується в інтернеті, особливо в незахищених з'єднаннях, але ще зберігається у внутрішньокорпоративних системах, просто тому що деякі з них створені досить давно. Варто розібратися, як він працює.

HTTP Basic Authentication

Першим, що при зверненні до захищеного ресурсу сервер видасть користувачеві, який не має доступу, буде помилка 401 Unauthorized. При цьому відповідь також містить інформацію про тип аутентифікації (в нашому випадку - Basic), який він може приймати, і контекст, в рамках якого ця аутентифікація діє (Realm). Користувач вводить логін і пароль, вони упаковуються в Base64 і відправляються на сервер для перевірки. Тут існують різні небезпеки. Найпоширеніша - загроза man-in-the-middle attack, або атаки посередника, в ході якої при використанні незахищеного з'єднання облікові дані можуть перехопити зловмисники в момент передачі від клієнта до сервера або назад.

HTTP Digest Authentication

Наступним етапом розвитку технології стала трохи більш складна система HTTP digest authentication, яка виключає передачу облікових даних у відкритому вигляді - тут для перевірки використовується MD5-хеш з деякими домішками, що дозволяє уникнути підбору логіна і пароля. Звичайно, цей алгоритм виглядає більш надійним, але і він схильний до цілого ряду не найскладніших атак. Наприклад, ось тут можна почитати про атаки більш докладно.

Forms Authentication

Пізніше з'явився процес Forms authentication, при якому аутентифікація відбувається на більш високому рівні моделі абстракції. HTTP-сервер при цьому не повідомляє про помилку доступу, а просто перенаправляє нерозпізнаних користувачів на іншу сторінку. Зазвичай на цій сторінці відображаються поля для введення логіна і пароля, після заповнення яких формується POST-запит з даними і через захищений канал направляється на сервер. Серверна сторона в свою чергу повертає користувачеві токен або ідентифікатор сесії, який зберігається в Cookies і надалі використовується для доступу до захищеного ресурсу.

Token Authentication

Наступне покоління способів аутентифікації представляє Token Based Authentication, який зазвичай застосовується при побудові систем Single sign-on (SSO). При його використанні запитуваний сервіс делегує функцію перевірки достовірності відомостей про користувача іншому сервісу. Т. е. Провайдер послуг довіряє видачу необхідних для доступу токенов власне токен-провайдеру (Identity provider). Це те, що ми бачимо, наприклад, входячи в додатки через акаунти в соціальних мережах. Поза IT найпростішої аналогією цього процесу можна назвати використання загальногромадянського паспорта. Офіційний документ якраз є виданими вам токеном - всі державні служби за замовчуванням довіряє відділу поліції, який його вручив, і вважає паспорт достатнім для вашої аутентифікації протягом усього терміну дії при збереженні його цілісності.

На схемі добре видно, як і в якій послідовності додатки обмінюються інформацією при зверненні до архітектури c аутентификацией по токені.

OAuth2 & Open ID Connect

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

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

У 2006 році в ході роботи над реалізацією протоколу Open ID для Twitter виявилася потреба в новому відкритому протоколі авторизації. У 2007 інженери Google і AOL почали спільну роботу над ним, а в 2009 Twitter запропонував своїм користувачам рішення, делегувала стороннім сервісам доступ до акаунтів і засноване на протоколі OAuth. Три роки по тому була опублікована нова версія - OAuth 2, спростила розробку клієнтських додатків і отримала цілий ряд нових можливостей, серед яких виявилося і оновлення токена без участі користувача. Багато сервісів почали використовувати цей протокол ще до його офіційного затвердження.

Розбираємося детально ху із ху

В даний момент на слуху такі протоколи:

1. OpenID - для перевірки облікових даних користувача (identification & authentication).
2. OAuth - про те, щоб отримувати доступ до чогось.
3. OpenID Connect - і про те, і про інше одночасно.

Всі три протоколи дозволяють користувачеві не розголошувати свої секретні логін і пароль недовірених додатків.

OpenID & OAuth розроблялися паралельно аж до 2014 року і об'єдналися в результаті в OpenID connect.

OpenID 1.0 (2006) & OpenID 2.0 (2007) дозволяли додатком (гарб) запитувати у довіреної сервера (authority) перевірку користувача (user). Відмінності між версіями для нас несуттєві.

• User -> App: Привіт, це Міша.
• App -> Authority: Ось «це» Міша?
• Authority і User спілкуються тет-а-тет.
• Authority -> App: Так, це Міша.

OpenID Attribute Exchange 1.0 (2007) розширює OpenID 2.0 дозволяючи отримувати і зберігати профіль користувача.

• User -> App: Привіт, це Міша.
• App -> Authority: Ось «це» Міша? І якщо це Міша, то надішліть мені його email.
• Authority і User спілкуються тет-а-тет.
• Authority -> App: Так, це Міша. І його email [email protected] .

OAuth 1.0 (2010) дозволяє користувачеві вирішувати з додатком отримувати обмежений доступ на третьесторонніх серверах (third-party server), які довіряють засвідчувальному центру.

• App -> User: Mи би хотіли ваших картинки з іншого сервера.
• Authority і User спілкуються тет-а-тет.
• Authority -> App: Ось вам квиток (access token) на 15 хвилин.
• App -> Third-party server: Нам тут по квитку можна отримати фотографії для цього користувача.

OAuth 2.0 (2012) робить те ж саме, що і OAuth 1.0, але тільки протокол істотно змінився і став простіше.

OpenID Connect (2014 року) об'єднує можливості OpenID 2.0, OpenID Attribute Exchange 1.0, і OAuth 2.0 в один загальний протокол. Він дозволяє програмам використовувати засвідчує центр для:

• Перевіряти облікові дані користувача.
• Отримувати профіль користувача (або його частини).

Важливо розуміти, що OpenID Connect не дає доступ до зовнішніх ресурсів. Він використовує OAuth 2.0 для того, щоб представити параметри профілю як ніби це такі ресурси.

погляд зверху

Зазвичай в системах зустрічаються різні компоненти: користувачі, що працюють через браузер, користувачі, які взаємодіють з сервером через мобільні додатки, і просто серверні додатки, які потребують належних вам даних, що зберігаються на інших серверах, доступ до яких здійснюється через Web API.

Single sign-on - Single Sign-On - дозволяє користувачеві перемикатися між різними додатками без повторної аутентифікації. Використовуючи SSO можна уникнути множинних логінів, так що користувач просто не буде помічати цих перемикань. При цьому ситуації, коли в рамках вашої інфраструктури таких додатків буде більше одного, зустрічаються постійно. Технологія єдиного входу особливо зручна у великих ентерпрайз-системах, що складаються з десятків додатків, слабо пов'язаних між собою. Навряд чи користувачі будуть задоволені, вводячи логін і пароль при кожному зверненні до системи обліку робочого часу, корпоративному форуму або внутрішній базі документів.

Як реалізації ми розглядаємо протокол OAuth2. В принципі, існують і інші, наприклад, Kerberos, успішно взаємодіє з Windows, але в разі гетерогенної мережі, в якій існують комп'ютери, що використовують і Windows-, і Mac-, і UNIX-системи, використовувати пропрієтарні протоколи часто незручно. Тим більше, це стосується випадків, коли доступ до ваших сервісів здійснюється через веб - тут OAuth2 виявляється кращим кандидатом.

На малюнку вище показано, які саме протоколи при кожному типі взаємодії.

Як ми знаємо з розділу « розбираємося детально ху із ху », OpenID Сonnect потрібен, щоб отримати у користувача його облікові дані і перевірити їх. OAuth 2.0 потрібен, щоб отримувати токени доступу і з ними звертатися до ресурсів.

Термінологія OAuth2 & OpenID Connect

• OpenID Connect Provider (OP)
• Client
• User
• Scope
  • Identity scopes - openid, profile, email
  • Resource scopes - various API
• Authentication / Token Request
• Identity Token
• Access Token
• Refresh Token

Сервіс видачі токенов

Open ID Connect Provider - найважливіший об'єкт всієї конструкції централізованого сервісу аутентифікації, він також може називатися Security Token Service, Identity Provider authorization server і т. Д. Різні джерела називають його по-різному, але за змістом це сервіс, який видає токени клієнтам.

Основні функції:

• Аутентифікувати користувачів, використовуючи карту пам'яті користувачів або зовнішнє джерело (наприклад, Active Directory).
• Керувати клієнтами (зберігати) і аутентифицировать їх.
• Надавати управління сесією і можливість реалізації Single sing-on.
• Видавати identity-токени і access-токени клієнтам.
• Перевіряти раніше видані токени.

клієнт

Client - пристрій або програма (браузер, додаток), яким потрібно або токен для аутентифікації користувача, або токен для доступу до якогось ресурсу (мається на увазі, що даний ресурс «знаком» з тим конкретним « Security Token Service »У якого клієнт запитує токен для доступу).

Користувач

User - власне кінцевий користувач - людина.

Область (scope)

Scope - ідентифікатор ресурсу, до якого клієнт хоче отримати доступ. Список scope надсилається на адресу сервісу видачі токенов в складі запиту на аутентифікацію .

За замовчуванням всі клієнти мають можливість запитувати будь-які області, але це можна (і потрібно) обмежувати в конфігурації сервісу видачі токенов .

Scopes бувають двох видів:

1. Identity scopes - це запит інформації про користувача. Його ім'я, профіль, підлогу, фотографія, адреса електронної пошти і т. Д.
2. Resource scopes - імена зовнішніх ресурсо (Web APIs), до яких клієнт хоче отримати доступ.

Запит на аутентифікацію

Authentication / Token Request - процес запиту аутентифікації.

Залежно від того які області (scopes) запитані, сервіс видачі токенов поверне:

1. Тільки Identity Token, якщо запитані тільки Identity scopes.
2. Identity Token і Access Token, якщо запитані також і Resources scopes.
3. Access Token і Refresh Token, якщо запрошeн Offline Access.

Більш докладно про процес аутентифікації можна прочитати в розділі « процес aутентіфікаціі ».

токен особистості

Identity Token - підтвердження аутентифікації. Цей токен містить мінімальний набір інформації про користувача.

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

Access Token - інформація, що конкретного користувача дозволяється робити. Клієнт запитує Access Token і потім використовує його для доступу до ресурсів (Web APIs). Access Token містить інформацію про клієнта і користувача, якщо вона присутня. Важливо розуміти, що є такі типи авторизації, при яких користувач в процесі безпосередньо не бере (докладніше в розділ « типи авторизації »)

токен поновлення

Refresh Token - токен, за яким STS поверне новий Access Token. Залежно від режиму, робота Refresh Token може бути багаторазовим і одноразовим. У випадку з одноразовим токеном, при запиті нового Access Token буде також сформований готовий Refresh Token, який слід використовувати при повторному оновленні. Очевидно, що одноразові токени більш безпечні.

Більш докладно про склад токенов в розділі « структура токена ».

процес аутентифікації

При зверненні користувача до клієнта, той перенаправляє користувача на Open ID Connect Provider, який запитує у користувача логін і пароль. У разі успішного проходження перевірки параметрів аутентифікації він повертає назад identity token і access token , З якими користувач може звертатися до захищеного ресурсу.

структура токена

формат

У реалізації OAuth2 використовується так званий jwt-токен, який складається з трьох частин. Припустимо, при зверненні до Identity provider ви відправляєте логін / пароль і у відповідь отримуєте токен. Він буде включати в себе: Header (заголовок), Payload (контент) і Signature (підпис). На сайті jwt.io його можна декодувати і подивитися вміст форматі JSON. На цьому сайті ви знайдете опис правил формування jwt-токенів.

У тому, що токени в процесі обміну передаються незашифрованими, нічого страшного немає. Ми спочатку виходимо з припущення, що комунікація відбувається по захищеному HTTPS-каналу, і повторне шифрування токена було б надмірною. Єдине, в чому нам потрібно переконатися - то, що токен ні підмінений або сфальсифікований на клієнтській стороні, для цього достатньо мати підпис і перевіряти її на сервері. Крім того, токен не містить ніякої критично важливої ​​інформації.

Крім identity tokens, є ще і Аccess tokens, які містять інформацію про видані користувачу клеймах. Термін дії access token досить короткий, тому що його розкрадання може забезпечити несанкціонований доступ до ресурсу. Т. е. Зловмисник, якщо йому вдасться роздобути токен цього типу, доступ отримає на дуже нетривалий час. Для отримання нового access token використовується refresh token, який зазвичай не фігурує в незахищених середовищах, зокрема в режимі доступу з браузера він взагалі не використовується. Які саме токени будуть повернуті клієнту в процесі аутентифікації, розбирається в розділі « типи авторизації ».

Основні поля

Кратно зупинимося на тому, які є стандартні полях в токені і навіщо вони потрібні:

• iss - адреса або ім'я засвідчує центру.
• sub - ідентифікатор користувача. Унікальний в рамках засвідчувального центру, як мінімум.
• aud - ім'я клієнта для якого токен випущений.
• exp - термін дії токена.
• nbf - час, починаючи з якого може бути використаний (не раніше ніж).
• iat - час видачі токена.
• jti - унікальний ідентифікатор токен (потрібен, щоб не можна було «випустити» токен вдруге).

Висновок першої частини

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

Stay tuned.

Спойлер другій частині

Мінімальна реалізація інтеграція Identity Server в ваше додаток виглядає так:

public void Configuration (IAppBuilder app) {var factory = new IdentityServerServiceFactory (); factory.UseInMemoryClients (Clients.Get ()) .UseInMemoryScopes (Scopes.Get ()) .UseInMemoryUsers (Users.Get ()); var options = new IdentityServerOptions {SiteName = Constants.IdentityServerName, SigningCertificate = Certificate.Get (), Factory = factory,}; app.UseIdentityServer (options); }

Мінімальна реалізація інтеграції веб-клієнта з Identity Server:

public void Configuration (IAppBuilder app) {app.UseCookieAuthentication (new CookieAuthenticationOptions {AuthenticationType = "Cookies"}); app.UseOpenIdConnectAuthentication (new OpenIdConnectAuthenticationOptions {ClientId = Constants.ClientName, Authority = Constants.IdentityServerAddress, RedirectUri = Constants.ClientReturnUrl, ResponseType = "id_token", Scope = "openid email", SignInAsAuthenticationType = "Cookies",}); }

Мінімальна реалізація інтеграції веб-API з Identity Server:

public void Configuration (IAppBuilder app) {app.UseIdentityServerBearerTokenAuthentication (new IdentityServerBearerTokenAuthenticationOptions {Authority = Constants.IdentityServerAddress, RequiredScopes = new [] { "write"}, ValidationMode = ValidationMode.Local, // credentials for the introspection endpoint ClientId = "write" , ClientSecret = "secret"}); app.UseWebApi (WebApiConfig.Register ()); }