ICQ HTTP API: Authorization

Суббота 14 Апр 2012 in ,

Часть 1. Авторизация

В последнее время в ICQ наблюдается постепенный переход с бинарного протокола на HTTP. Сейчас уже реализован практически весь функционал протокола icq.

На сегодняшний день официальный клиент icq 7.7 использует примерно такую схему:

При первом подключении, клиент запрашивает realm и challengeWord, эти 2 параметра используются при md5 хешировании пароля в качестве соли.
http запрос:

https ://api.login.icq.net/auth/getChallenge
POST DATA:
devId=DEVICE_ID // идентификатор устройства (клиента) 
&f=xml // формат возвращаемых данных (XML/JSON/QS)
&s=UIN // uin\e-mail

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


  200
  OK
  
    TyPDkAAAC9gB+tJ7
    false
    true
    AOL Instant Messenger (SM)
    1258886032

После этого, клиент хэширует пароль, используя алгоритм md5 (процедура в точности напоминает функцию из бинарного протокола). И посылает новый post запрос:

https ://api.login.icq.net/auth/clientLogin
POST DATA:
clientName=ICQ_CLIENT_NAME  // название клиента
&clientVersion=ICQ_VERSION  // версия клиента
&f=xml
&k=DEVICE_ID
&pwd=MD5_PWD_SALT // "соленый" md5 хэш пароля
&s=UIN // uin / e-mail
&tid=TID // значение параметра tid, полученного из первого запроса
&tokenType=longterm // срок жизни токена (возможно указание в числовом формате UNIX)
&idType=ICQ
&digest=1

Если пароль и uin проходят валидацию, то в ответ приходит примерно такой текст:


  200
  OK
  
    
      315569260      %2FwQAAAAAAAE2mZ%2F88WmZRrostaP5z7K2S%2FRU3bxk lAPFjtoJ%2BYDFy%2Ff6pKg9wvMd4A2t853%2BZY1NJkJ2ug1BvkMjr 1yTTAdMXKFBkUh%2BWeBI%2B4nphoSKOJCiIp1Wu9KX4iqwHUAI%3D
    
    mBxNcWdfrQMR9lcB
    1328732124
    483648000

где a – это токен сессии, а sessionSecret – секретный ключ, служащий для подписи GET запросов.

Токен и секретный ключ сессии сохраняются в базе клиента, и используются для получения cookies, что бы подключиться к BOS серверу по бинарному протоколу, а так же для открытия aim сессии, подписания (sig_sha256) запросов по HTTP.

При последующих подключениях клиент берет сохраненный токен из базы и стартует сессию aim по нему, и только в случае, когда токен становится недействительным, он запрашивается снова.

Помимо способа выше есть еще порядка 5 возможностей получения токена и ключа сессии.

ps: будет интерес – продолжу описание web api icq