Кілька сценаріїв можуть допомогти проілюструвати мету доступу та оновлення жетонів та інженерних компромісів при розробці системи oauth2 (або будь-якої іншої автентичності):
Сценарій веб-додатків
У сценарії веб-додатків у вас є кілька варіантів:
- якщо у вас є власне управління сеансом, збережіть і access_token, і refresh_token проти вашого ідентифікатора сеансу в стані сеансу на службі стану сеансу. Коли користувач запитує сторінку, яка вимагає від вас доступу до ресурсу, використовуйте access_token, а якщо термін доступу_token закінчився, використовуйте refresh_token, щоб отримати новий.
Уявімо, що комусь вдається викрасти ваш сеанс. Єдине, що можливо - це запитувати ваші сторінки.
- якщо у вас немає керування сеансом, покладіть access_token у файл cookie та використовуйте його як сеанс. Потім, кожного разу, коли користувач запитує сторінки з вашого веб-сервера, надсилає домен access_token. Ваш сервер додатків може оновити access_token за потреби.
Порівняння 1 і 2:
У 1, access_token і refresh_token проїжджають лише через провід на шляху між сервером авторизації (у вашому випадку Google) та сервером додатків. Це було б зроблено на захищеному каналі. Хакер може викрасти сеанс, але вони зможуть взаємодіяти лише з вашим веб-додатком. У 2 році хакер може забрати access_token і сформувати власні запити до ресурсів, до яких користувач надав доступ. Навіть якщо хакер має доступ до доступу_token, у них буде лише коротке вікно, в якому вони можуть отримати доступ до ресурсів.
Так чи інакше, refresh_token та clientid / secret відомі лише серверу, що робить неможливим у веб-браузері отримати довгостроковий доступ.
Давайте уявимо, що ви реалізуєте oauth2 і встановите тривалий час на маркері доступу:
В 1) Тут немає великої різниці між коротким і довгим маркером доступу, оскільки він прихований на сервері додатків. У 2) хтось може отримати access_token у браузері, а потім використовувати його для прямого доступу до ресурсів користувача протягом тривалого часу.
Мобільний сценарій
На мобільному пристрої є кілька сценаріїв, про які я знаю:
Зберігайте клієнт / секрет на пристрої та майте пристрій оркеструвати, отримуючи доступ до ресурсів користувача.
Використовуйте сервер додатків, щоб утримати клієнта / секрет і зробити це оркестрацією. Використовуйте access_token як своєрідний ключ сеансу та передайте його між клієнтом та сервером додатків.
Порівнюючи 1 і 2
У 1) Після того, як у вас є пристрій / секрет на пристрої, вони більше не є секретними. Будь-хто може декомпілювати та потім почати діяти так, ніби це ви, з дозволу користувача, звичайно. Access_token і refresh_token також знаходяться в пам'яті і до них можна отримати доступ на компрометованому пристрої, що означає, що хтось може діяти як ваш додаток, не надаючи користувачеві своїх даних. У цьому сценарії довжина access_token не має жодних значень для хакерства, оскільки refresh_token знаходиться там же, що і access_token. У 2) клієнт / секрет, а також маркер оновлення не порушені. Тут тривалість закінчення терміну access_token визначає, як довго хакер міг би отримати доступ до ресурсів користувачів, якщо вони отримають його.
Довжина терміну дії
Тут залежить від того, що ви захищаєте у своїй системі аутентифікації щодо того, як довго повинен бути термін дії вашого_доступу. Якщо це щось особливо цінне для користувача, воно повинно бути коротким. Щось менш цінне, воно може бути і довше.
У деяких людей, як Google, не закінчується термін refresh_token. Деякі, як stackflow. Рішення про закінчення терміну дії є компромісом між легкістю користувача та безпекою. Довжина маркера оновлення пов'язана з довжиною повернення користувача, тобто встановіть оновлення на те, як часто користувач повертається до вашої програми. Якщо маркер оновлення не закінчується, єдиний спосіб їх відкликання - це явне відкликання. Зазвичай реєстрація не скасовується.
Сподіваюсь, що досить довгий пост корисний.