Розділ 4.2 проекту протоколу OAuth 2.0 вказує, що сервер авторизації може повернути як access_token(який використовується для автентифікації себе з ресурсом), так і a refresh_token, який використовується виключно для створення нового access_token:
https://tools.ietf.org/html/rfc6749#section-4.2
Чому обоє? Чому б просто не зробити access_tokenостаннього до тих пір, як refresh_tokenі не мати refresh_token?
Відповіді:
Ідея оновлення лексем полягає в тому, що якщо маркер доступу порушений, оскільки він недовгий, у зловмисника є обмежене вікно, в якому його можна зловживати.
Оновлення жетонів, якщо вони порушені, марні, тому що зловмисник вимагає ідентифікатор клієнта та секрет на додаток до маркера оновлення, щоб отримати маркер доступу.
Сказавши це , оскільки кожен виклик як сервера авторизації, так і сервера ресурсів здійснюється через SSL - включаючи оригінальний ідентифікатор клієнта та секрет, коли вони запитують маркери доступу / оновлення - я не впевнений у тому, як маркер доступу більше є » компромісний ", ніж довготривалий маркер оновлення та поєднання між клієнтами та секретами.
Звичайно, це відрізняється від реалізацій, де ви не керуєте як серверами авторизації, так і ресурсами.
Ось хороший потік, який розповідає про використання токенів оновлення: OAuth Archives .
Цитата з вищесказаного, що говорить про цілі безпеки маркера оновлення:
Оновлення жетонів ... зменшує ризик тривалої протікання access_token (параметр запитів у файлі журналу на незахищеному ресурсному сервері, бета-версія або погано закодований додаток сервера ресурсів, клієнт JS SDK на веб-сайті, який не є https, який ставить access_token у печиво тощо)
Посилання на дискусію, надане Кеттдевом, має ще один дійсний пункт (оригінал, мертве посилання), зроблений Діком Хардтом, який, на мою думку, варто згадати тут, окрім написаного вище:
Мій пригадування знаків оновлення було для безпеки та відкликання. <...>
відкликання: якщо маркер доступу автономний, авторизацію можна відкликати, не видаючи нові маркери доступу. Ресурсу не потрібно запитувати сервер авторизації, щоб перевірити, чи маркер доступу дійсний. Це спрощує перевірку маркера доступу та полегшує масштабування та підтримку декількох серверів авторизації. Існує вікно часу, коли маркер доступу дійсний, але авторизація відкликана.
Дійсно, у ситуації, коли сервер ресурсів та сервер авторизації є одним і тим же об'єктом, і коли з'єднання між користувачем і будь-яким з них є (як правило) однаково безпечним, немає особливого сенсу тримати маркер оновлення окремо від маркера доступу.
Хоча, як зазначалося в цитаті, ще одна роль оновлення жетонів полягає в тому, щоб забезпечити користувач (будь-коли через веб-інтерфейс у їхніх профілях) маркер доступу може бути відкликаний, зберігаючи систему одночасно масштабованою. .
Як правило, маркери можуть бути або випадковими ідентифікаторами, що вказують на конкретний запис у базі даних Сервера, або вони можуть містити всю інформацію в собі (звичайно, ця інформація повинна бути підписана, наприклад, з MAC ).
Як повинна працювати система з довготривалими маркерами доступу
Сервер дозволяє Клієнту отримати доступ до даних Користувача в межах заздалегідь заданого набору областей, видаючи маркер. Оскільки ми хочемо, щоб маркер відкликався, ми повинні зберігати в базі даних маркер разом із встановленим або знятим прапором "відкликаний" (інакше як би ви це зробили з автономним токеном?) База даних може містити стільки, скільки len(users) x len(registered clients) x len(scopes combination)записів . Кожен запит API повинен потрапляти в базу даних. Хоча робити запити до такої бази даних, що виконує O (1), досить тривіально, одинична точка відмови сама по собі може мати негативний вплив на масштабованість та продуктивність системи.
Як має працювати система з довготривалим токеном оновлення та маркером короткочасного доступу
Тут ми видаємо два ключі: випадковий маркер оновлення з відповідним записом у базі даних та підписаний автономний маркер доступу, що містить серед інших поле часової позначки терміну дії.
Оскільки маркер доступу є самостійним, нам взагалі не потрібно потрапляти в базу даних, щоб перевірити її дійсність. Все, що нам потрібно зробити, - це розшифрувати маркер і перевірити підпис і мітку часу.
Тим не менш, нам ще належить зберігати базу даних жетонів оновлення, але кількість запитів до цієї бази даних, як правило, визначається тривалістю життя маркера доступу (чим довший термін служби, тим менша швидкість доступу).
Щоб відкликати доступ Клієнта від конкретного Користувача, нам слід позначити відповідний маркер оновлення як "відкликаний" (або видалити його повністю) та припинити видавати нові маркери доступу. Хоча очевидно, що є вікно, під час якого маркер оновлення був відкликаний, але його маркер доступу все ще може бути дійсним.
Компроміси
Токни оновлення частково усувають SPoF (єдину точку відмови) бази даних Token Access, але вони мають деякі очевидні недоліки.
Вікно". Час між подіями "користувач скасовує доступ" та "гарантовано буде скасовано доступ".
Ускладнення логіки Клієнта.
без ознаки оновлення
з ознакою оновлення
Я сподіваюся, що ця відповідь має сенс і допомагає комусь прийняти більш продумане рішення. Хотілося б також зазначити, що деякі відомі постачальники OAuth2, включаючи github та fourrsquare, приймають протокол без оновлення жетонів, і, мабуть, задоволені цим.
Незважаючи на всі чудові відповіді, наведені вище, я, як студент-магістр безпеки та програміст, який раніше працював на eBay, коли я розглядав захист покупців та шахрайство, можу сказати, що розділення маркера доступу та оновлення токена має найкращий баланс між домаганням користувача частого імені користувача / введення пароля та зберігаючи повноваження в руці, щоб скасувати доступ до можливих зловживань вашою послугою.
Придумайте такий сценарій. Ви видаєте користувачеві маркер доступу 3600 секунд і оновлюєте маркер набагато довше, як один день.
Користувач - хороший користувач, він вдома і отримує / вимикає покупки та пошук на своєму веб-сайті на своєму iPhone. Його IP-адреса не змінюється і має дуже низьке навантаження на ваш сервер. Як і 3-5 запитів на сторінку щохвилини. Коли його 3600 секунд на маркері доступу закінчено, йому потрібен новий з маркером оновлення. Ми з боку сервера перевіряємо його історію активності та IP-адресу, думаємо, що він людина і поводиться сам. Ми надаємо йому новий маркер доступу, щоб продовжувати користуватися нашою службою. Користувачеві не потрібно буде вводити знову ім’я користувача / пароль, поки він не досяг одноденного періоду життя самого жетона оновлення.
Користувач - недбалий користувач. Він проживає в Нью-Йорку, США та закрив вірусну програму, а хакер зламався в Польщі . Коли хакер отримав маркер доступу та оновить маркер, він намагається представити себе користувачем та скористатися нашою послугою. Але після закінчення терміну дії короткого режиму доступу, коли хакер намагається оновити маркер доступу, ми на сервері помітили різку зміну IP-адреси в історії поведінки користувачів (так, цей хлопець заходить у США, а тепер оновив доступ у Польщі після всього 3600-х років ???). Ми припиняємо процес оновлення, анулюємо сам маркер оновлення та вимагаємо знову ввести ім'я користувача / пароль.
Користувач - шкідливий користувач. Він покликаний зловживати нашою послугою, телефонуючи 1000 разів наш API щохвилини за допомогою робота. Він цілком може зробити це до 3600 секунд пізніше, коли він намагається оновити маркер доступу, ми помітили його поведінку і думаємо, що він може не бути людиною. Ми відхиляємо і припиняємо процес оновлення та просимо його знову ввести ім’я користувача / пароль. Це може потенційно порушити автоматичний потік його робота. Принаймні, йому стає незручно.
Ви можете бачити, що маркер оновлення діяв ідеально, коли ми намагаємось збалансувати роботу, досвід користувача та потенційний ризик викраденого маркера. Ваша сторожова собака на стороні сервера може перевірити більше, ніж зміни IP, частоту api-дзвінків, щоб визначити, чи буде користувач хорошим користувачем чи ні.
Ще одне слово - ви також можете спробувати обмежити контроль за пошкодженням вкраденого токена / зловживання службою, застосовуючи на кожному дзвінку api основну собаку для спостереження за IP або будь-які інші заходи. Але це дорого, оскільки вам доведеться читати і писати записи про користувача і сповільнюватиме відповідь вашого сервера.
Жоден із цих відповідей не доходить до основної причини, коли існують маркери оновлення. Очевидно, що ви завжди можете отримати нову пару доступу-маркер / refresh-token, надіславши облікові дані свого клієнта на сервер auth - саме так ви їх отримаєте в першу чергу.
Тож єдиною метою маркера оновлення є обмеження використання облікових даних клієнта, що надсилаються по дроту до служби аутентифікації. Чим коротший ttl маркера доступу, тим частіше доведеться використовувати облікові дані клієнта для отримання нового маркера доступу, а отже, тим більше можливостей зловмисникам доводиться компрометувати облікові дані клієнта (хоча це все-таки може бути дуже складно, якщо для їх надсилання використовується асиметричне шифрування). Отже, якщо у вас є ток оновлення для одноразового використання, ви можете зробити ttl токенів доступу довільно невеликим, не порушуючи облікові дані клієнта.
Щоб усунути певну плутанину, ви повинні зрозуміти ролі секрету клієнта та пароля користувача , які дуже відрізняються.
Клієнт є додаток / сайт / програма / ..., при підтримці сервера, який хоче аутентифицировать на користувача за допомогою служби аутентифікації третьою стороною. Секрет клієнта - це (випадкова) рядок, яка відома як цьому клієнту, так і серверу аутентифікації. Використовуючи цей секрет, клієнт може ідентифікувати себе з сервером аутентифікації, отримавши авторизацію на запит жетонів доступу.
Щоб отримати початковий маркер доступу та оновити маркер, потрібно:
Для отримання оновленого маркера доступу клієнт використовує таку інформацію:
Це чітко показує різницю: під час оновлення клієнт отримує дозвіл на оновлення токенів доступу, використовуючи його секрет клієнта, і, таким чином, може повторно аутентифікувати користувача, використовуючи маркер оновлення замість ідентифікатора користувача + пароля. Це фактично не дозволяє користувачеві повторно вводити свій пароль.
Це також показує, що втратити маркер оновлення не є проблемою, оскільки ідентифікатор клієнта та секрет не відомі. Це також показує, що зберігати таємницю клієнта та клієнтську таємницю є життєво важливим .
Ця відповідь отримана від Джастіна Рішера через стандартний список електронних листів OAuth 2. Це розміщено з його дозволу.
Термін служби маркера оновлення залежить від сервера авторизації (AS) - вони можуть закінчуватися, відкликатись і т. Д. Різниця між маркером оновлення та маркером доступу полягає в аудиторії: маркер оновлення повертається лише до сервера авторизації, маркер доступу переходить до сервера ресурсів (RS).
Крім того, що отримати маркер доступу не означає, що користувач увійшов у систему. Насправді, користувача навіть більше не може бути там, що є фактично призначеним випадком використання маркера оновлення. Оновлення маркера доступу надасть вам доступ до API від імені користувача, воно не скаже вам, чи є користувач там.
OpenID Connect не просто дає вам інформацію про користувача з маркера доступу, але також дає вам ідентифікатор. Це окремий фрагмент даних, який спрямований на самого клієнта, а не на AS або RS. У OIDC вам слід вважати, що хтось насправді "увійшов" протоколом, лише якщо ви можете отримати новий маркер ідентифікатора. Освіжати її, мабуть, буде недостатньо.
Для отримання додаткової інформації читайте http://oauth.net/articles/authentication/
Клієнти можуть бути скомпрометовані багатьма способами. Наприклад, мобільний телефон можна клонувати. Термін дії маркера доступу закінчується означає, що клієнт змушений повторно пройти автентифікацію на сервері авторизації. Під час повторної аутентифікації сервер авторизації може перевірити інші характеристики (IOW виконувати адаптивне управління доступом).
Токени оновлення дозволяють клієнту здійснювати лише повторну автентифікацію, коли при повторній авторизації примушує діалог з користувачем, який багато хто вказав, що цього не бажає робити.
Токени для оновлення по суті розміщуються там, де звичайні веб-сайти можуть періодично повторно аутентифікувати користувачів через годину або близько того (наприклад, банківський сайт). В даний час він не використовується дуже часто, оскільки більшість соціальних веб-сайтів не повторно підтверджують автентифікацію користувачів, тому чому вони повторно підтверджують автентифікацію клієнта?
Чому б просто не зробити так, щоб access_token тривав до тих пір, як refresh_token, і не мати refresh_token?
На додаток до чудових відповідей, які надали інші люди, є ще одна причина, чому можна використовувати оновлення маркерів і пов'язане з претензіями.
Кожен маркер містить претензії, які можуть включати будь-що від імені користувача, їх ролі або постачальника, який створив претензію. У міру оновлення маркера ці претензії оновлюються.
Якщо ми часто оновлюємо жетони, ми, очевидно, піддаємо більше напруги нашим службам ідентифікації, однак ми отримуємо більш точні та актуальні претензії.
Щоб додатково спростити відповідь BT: Використовуйте маркери оновлення, коли зазвичай не потрібно, щоб користувач знову вводив облікові дані, але все ж хоче, щоб влада могла відкликати дозволи (відкликаючи маркер оновлення)
Ви не можете відкликати маркер доступу - лише маркер оновлення.
Цю відповідь було зібрано за допомогою двох старших розробників (Джон Брейтон та Девід Дженнес).
Основна причина використання маркера оновлення - зменшення атакуючої поверхні.
Припустимо, немає ключа оновлення, і перейдемо до цього прикладу:
У будинку 80 дверей. Усі двері відкриваються одним ключем. Клавіша змінюється кожні 30 хвилин. Після закінчення 30 хвилин я повинен дати старий ключ виробнику клавіш і отримати новий ключ.
Якщо я хакер і отримаю ваш ключ, то наприкінці 30 хвилин я пришвидшу його до клавішника і отримаю новий ключ. Я зможу постійно відкривати всі двері незалежно від зміни ключа.
Запитання: Протягом 30 хвилин скільки можливостей для взломів у мене було проти ключа? У мене було 80 можливостей для злому, кожного разу, коли ви використовували ключ (подумайте про це як за допомогою мережевого запиту та передачі маркера доступу, щоб ідентифікувати себе). Отже, це 80X атакова поверхня.
Тепер перейдемо до того ж прикладу, але цього разу припустимо, що є ключ оновлення.
У будинку 80 дверей. Усі двері відкриваються одним ключем. Клавіша змінюється кожні 30 хвилин. Щоб отримати новий ключ, я не можу передавати старий маркер доступу. Я повинен лише здати ключ оновлення.
Якщо я хакер і отримаю ваш ключ, я можу ним користуватися протягом 30 хвилин, але наприкінці 30 хвилин відправлення його ключнику не має значення. Якщо я це зробити, то клавішник просто сказав би цей поганий маркер оновлення. Щоб мати змогу продовжити хак, мені доведеться зламати кур'єра до виробника ключів. У кур'єра є чіткий ключ (подумайте про це як маркер оновлення).
Питання: Скільки можливостей для злому було протягом 30 хвилин проти клавіші оновлення? 80? Ні. У мене була лише 1 можливість хакерства. Протягом часу кур'єр спілкується з виробником клавіш. Так це 1X атакова поверхня. У мене було 80 можливостей злому проти ключа, але вони не сприятливі через 30 хвилин.
Сервер перевірить маркер доступу на основі облікових даних та підпису (як правило) JWT.
Протікає маркер доступу погано, але після закінчення терміну дії він більше не корисний для зловмисника. Токен оновлення набагато гірший, але, мабуть, він менш імовірний. (Я думаю, що тут є питання, чи вірогідність витоку маркера оновлення значно нижча, ніж у витоку маркера доступу, але це ідея.)
Справа в тому, що маркер доступу додається до кожного запиту, який ви робите, тоді як маркер оновлення використовується лише під час потоку оновлення. Так менше шансів MITM побачити маркер
Частота допомагає зловмиснику. Серцеподібні -як потенційних вразливостей в SSL, потенційних вразливостей в клієнті, і потенційні недоліки безпеки на сервері все роблять витоку можливо.
Крім того, якщо сервер авторизації відокремлений від сервера додатків, що обробляє інші клієнтські запити, сервер додатків ніколи не побачить маркери оновлення. Він побачить лише маркери доступу, які не проживуть довше.
Відсікання корисно для безпеки.
І останнє, але не в останню чергу, бачити цю дивовижну відповідь
Про який маркер оновлення НЕ йдеться?
Можливість оновлення / відкликання рівня доступу через маркери оновлення є побічним продуктом вибору використання токенів оновлення, інакше окремий маркер доступу може бути відкликаний або змінити рівень доступу, коли він закінчується, і користувачі отримують новий маркер
Припустимо, ти робиш access_tokenостаннє дуже довго, а цього не маєш refresh_token, тож за один день хакер отримає цеaccess_token і він може отримати доступ до всіх захищених ресурсів!
Але якщо у вас є refresh_token, час access_tokenу прямому ефірі короткий, тому хакер важко зламати ваш, access_tokenоскільки він буде недійсним через короткий проміжок часу.
Access_tokenїх можна повернути лише за допомогою не тільки, refresh_tokenале й за допомогою client_idі client_secret, якого хакер не має.
Поки маркер оновлення зберігається сервером авторизації. Маркер доступу є автономним, тому сервер ресурсів може перевірити його, не зберігаючи його, що економить зусилля на пошук у разі перевірки. Ще один момент, який бракує в обговоренні, - це rfc6749 # page-55
"Наприклад, сервер авторизації може використовувати поворот маркера оновлення, в якому новий маркер оновлення видається з кожною відповіддю оновлення токена доступу. Попередній маркер оновлення недійсний, але зберігається сервером авторизації. Якщо маркер оновлення порушений і згодом використовується і зловмисник, і законний клієнт, один з них подасть недійсний маркер оновлення, який повідомить сервер авторизації про порушення ".
Я думаю, що вся суть використання маркера оновлення полягає в тому, що навіть якщо зловмиснику якось вдається отримати маркер оновлення, ідентифікатор клієнта та секретну комбінацію. З наступними дзвінками отримати новий маркер доступу від зловмисника можна відслідковувати у випадку, якщо кожен запит на оновлення призведе до нового маркера доступу та маркер оновлення.
A Single-Page Application (normally implementing Single-Page Login Flow) should not under any circumstances get a Refresh Token. The reason for that is the sensitivity of this piece of information. You can think of it as user credentials, since a Refresh Token allows a user to remain authenticated essentially forever. Therefore you cannot have this information in a browser, it must be stored securely.
Розглянемо систему, де кожен користувач пов'язаний з однією або декількома ролями, і кожна роль пов'язана з одним або кількома привілеями доступу. Ця інформація може бути кешована для кращої продуктивності API. Але потім можуть відбутися зміни в конфігураціях користувача та ролей (наприклад, новий доступ може бути наданий або поточний доступ може бути відкликаний), і це повинно бути відображено в кеші.
Ми можемо використовувати маркери для доступу та оновлення для цієї мети. Коли API викликає маркер доступу, сервер ресурсів перевіряє кеш на права доступу. Якщо є якісь нові гранти на доступ, це відображається не відразу. Як тільки маркер доступу закінчується (скажімо, через 30 хвилин) і клієнт використовує маркер оновлення для створення нового маркера доступу, кеш може бути оновлений оновленою інформацією про право доступу користувача з БД.
Іншими словами, ми можемо переміщувати дорогі операції з кожного дзвінка API, використовуючи маркери доступу до події генерації маркера доступу, використовуючи маркер оновлення.
По-перше, клієнт аутентифікується на сервері авторизації, надаючи дозвіл авторизації.
Потім клієнт запитує сервер ресурсів для захищеного ресурсу, надаючи маркер доступу.
Сервер ресурсів перевіряє маркер доступу та надає захищений ресурс.
Клієнт робить захищений запит ресурсу на сервер ресурсів, надаючи маркер доступу, де сервер ресурсів перевіряє його і обслуговує запит, якщо він дійсний. Цей крок продовжується, поки маркер доступу не закінчиться.
Якщо маркер доступу закінчується, клієнт аутентифікується на сервері авторизації та запитує новий маркер доступу, надаючи маркер оновлення. Якщо маркер доступу недійсний, сервер ресурсів відправляє клієнту назад недійсну відповідь на помилку маркера.
Клієнт аутентифікується на сервері авторизації, надаючи маркер оновлення.
Тоді сервер авторизації перевіряє маркер оновлення шляхом автентифікації клієнта і видає новий маркер доступу, якщо він дійсний.
access token + refresh token?