graywolf's lair

Inhuman being's diary…

OAuth2 – промінчик світла в темному царстві?

| 5 Comments

OAuth2 logo

З давніх давен мене завжди харила необхідність реєстрації на сайтах. Чесно. Причому не з якихось там параноїдальних міркувань (мене це дуже мало бентежить), а банально: знову вводити ім’я користувача, придумувати пароль, тощо… І тому коли треба реєструватись на комусь сайті доводиться через стандартну логін/пароль/e-mail процедуру це мене запросто може відлякнути від реєстрації взагалі. Потім з’явилися всякі OpenID, Facebook Connect, OAuth і життя стало налагоджуватись – реєстрації на одному з популярних сервісів типу Google/Facebook/Twitter зазвичай вистачає аби мати можливість логінитись на нормальні сайти в один клік: наприклад той самий Покупон ніколи б не отримав моїх грошиків ні за які знижки аби у нього не було реєстрації через Facebook та оплати по Webmoney, коли можна було придбати купончика фактично не торкаючись клавіатури, а просто в кілька тицків мишкою. І впевнений, що я такий не один. Тому останнім часом завжди коли доводиться писати сайт з реєстрацією мну намагається всунути туди реєстрацію через “3rd party” сервіси. Але ще рік тому це була нефігова проблема, бо усі ці сервіси використовували різні протоколи і незважаючи на те, що всі вони намагались зробити якнайкраще – виходило як завжди, бо об’єднати все це в якусь уніфіковану систему не так вже й тривіально. Чи не найбільше мене напрягав OAuth, бо при першому знайомстві з його процесом обмінами токенів наскоком без півлітри не розібратися. Причому мало того, кожен сервіс часто використовував свою варіацію протоколу, що знову ж таки ускладнювало написання гнучкого коду.

Коли довелося причіплювати мультиавторизацію останній раз, я вже поступово готувався засісти в ці окопи надовго. Хоча в цьому випадку було простіше – у Django принаймні добрі люди написали django-publicauth. Документація там бідненька, тому як правильно його заюзати довелося гуглити по коду інших open-source проектів, які його використовували. Facebook тим не менш завівся досить живенько, а от на ВКонтакті вже мило чекали перші граблі: модуль більше року не оновлювався і там API для авторизації встиг змінитися. Доктор сказав “Різати!” Як виявилося, російський недофейсбук встиг перейти на OAuth2 і (о, диво!) там все було просто як гранчастий стакан (щоб отримати токен для подальших запитів треба зробити лише один редірект та один фоновий запит з мінімумом параметрів). Причому там все було настільки просто і так чудово лягло на архітектуру бекендів django-publicauth, що все пофіксилось буквально за пару годин (включно з вдуплянням в те як все парцює, першим прототипом та подальшим рефакторингом). Мало того, при пошуку інформації про новий протокол виявилося, що Google та Facebook вже теж його підтримують. Коротше кажучи, наступного вечора я переписав і ці дві системи під OAuth2 і все працювало як швейцарський годинник. На все про все менше 8 годин часу і майже готовий патч. Кароче, вирішив я форкнути django-publicauth на bitbucket та влити туди свої правки 😎 Єдина поки що паршива вівця – це Twitter, який поки не підтримує другу версію, але благо перша там працює нормально.

OAuth2 server-side app flow

OAuth2 flow for server-side applications

Ложка дьогтю: не дивлячись на простоту реалізації стандарт OAuth2 ще не затверджено остаточною. Існує кілька його драфтів і всі використовують свої власні інтерпретації. Але за рахунок його простоти складність правок під конкретну реалізацію зазвичай є справою перевизначення пари методів. Причому насправді відмінності дуже тупі. Вконтакт повертає JSON-відповідь із “зайвим” рівнем вкладеності, Гугл вимагає авторизувати токен через POST-запит, а Фейсбук повертає результат не в JSON, а в urlencoded query string 😕

Стандартизація рулить 😎

5 Comments

  1. От єдине що не зрозумів в потоці виконання – чим код відрізняється від токена, і чому б не отримувати одразу токен?

    • Все досить просто: користувач має підтвердити те, що він надає право використовувати свої дані третій стороні на сайті сервісу, який дозволяє авторизацію по OAuth2. Для цього користувач редіректиться на сайт. Після підтвердження йде редірект назад на сайт, що запитав авторизацію (callback) з кодом. Далі третя сторона напряму (не через браузер користувача) міняє code на token, причому в параметрах фігурує secret key, який унікальний для кожного додатку, але про який не має знати користувач (якщо я правильно розумію – аби уникнути фальшивої авторизації).

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

    • Ось трохи більше деталей по безпеці OAuth2: http://blog.springsource.org/2011/11/30/10317/

  2. http://www.janrain.com/ – 100$ в год (по моему) и куча Open ID, что б не мучаться.
    Конечно понятно, что заказчики на это могут и не огласиться, но ведь это спасает от "изобретения велосипеда" 🙂
    Хотя, если ты говоришь за 8 часов справился, тогда конечно есть смысл и самому писать, хотя зная тебя – далеко не все так умеют и могут 😉

    • Хм, интересный сервис – надо будет посмотреть детальнее, но в данном случае это было бы убер-решение 🙂

      А насчет времени – там дело-то не пыльное было… Основную часть уже сделали для меня, а я только немножко поправил 😉 Можно было бы написать еще быстрее.

Залишити відповідь

Required fields are marked *.