Обратный инжиниринг заголовка авторизации API приложения Xbox One Smartglass

Question

Поскольку Microsoft решила разместить страницы профиля для пользователей Xbox Live за стеной входа в систему по какой-то глупой причине, я был вынужден найти другие способы определить, подключен ли пользователь Xbox Live к сети или нет.

Для этого я использовал mitmproxy, чтобы выяснить, какие запросы выполняет приложение Xbox One Smartglass для iOS. Похоже, что для любого запроса, требующего аутентификации, приложение заполняет поле заголовка "Аутентификация" "XBL3.0 x={computed auth token}".

Я выяснил, что приложение получает токен доступа, выполнив запрос POST к https://login.live.com/oauth20_token.srf и передает закодированные в форме данные, одним из свойств которых является "refresh_token" пользователя. Вы можете получить этот токен обновления, просто посмотрев на любой из этих запросов с помощью mitmproxy.

Затем приложение переходит к выполнению запроса POST по https://user.auth.xboxlive.com/user/authenticate передавая различную информацию, происхождение которой я не могу определить. Ниже приведен пример полезной нагрузки JSON этого запроса:

{
    "Properties": {
        "AuthMethod": "RPS", 
        "RpsHeader": "<data removed for safety>", 
        "RpsTicket": "<data removed for safety>", 
        "SiteName": "user.auth.xboxlive.com"
    }, 
    "RelyingParty": "http://auth.xboxlive.com", 
    "TokenType": "JWT"
}

Ответ на этот запрос содержит следующий JSON:

{
    "DisplayClaims": {
        "xui": [
            {
                "uhs": "<data removed for safety>"
            }
        ]
    }, 
    "IssueInstant": "2014-08-02T23:44:56.5868148Z", 
    "NotAfter": "2014-08-16T23:44:56.5868148Z", 
    "Token": "<data removed for safety>"
}

Содержимое соединенных вместе "uhs" и "token", по-видимому, является отсутствующим токеном авторизации из заголовка авторизации "XBL3.0 x=".

Проблема в том, что я абсолютно не знаком с веб-стеком Microsoft, и после нескольких часов поиска я не могу понять, откуда берутся значения для "RpsHeader" и "RpsTicket".

Answer 1

Вы фактически отправляете запрос GET на https://login.live.com/oauth20_authorize.srf, за которым сразу же следует запрос POST на https://login.live.com/ppsecure/post.srf. Если вы посмотрите на ответ на этот запрос POST, вы увидите подстроку с именем access_token в поле Location, и это ваш RpsTicket.

Я не вижу RpsHeader ни в одном из моих запросов, поэтому я не знаю об этом.

Answer 2

Я полагаю, что RPS относится к федеративным входам в систему с действующими учетными записями / учетными записями Microsoft. Таким образом, RpsHeader и RpsTicket - это информация, полученная с поста на login.live.com. Как эти данные создаются из данных, полученных с live.com, может быть сложнее понять, но я предполагаю, что они берут некоторые данные из ответа love.com, и base64 их кодирует или что-то в этом роде.