З давніх давен мене завжди харила необхідність реєстрації на сайтах. Чесно. Причому не з якихось там параноїдальних міркувань (мене це дуже мало бентежить), а банально: знову вводити ім’я користувача, придумувати пароль, тощо… І тому коли треба реєструватись на комусь сайті доводиться через стандартну логін/пароль/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 flow for server-side applications

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

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