Неполный ответ токена доступа Linkedin OAuth 2.0

Мой вопрос касается ответа токена доступа OAuth2 от API Linkedin. Когда я пытаюсь получить этот токен, я получаю следующий ответ:

{"access_token":"...","expires_in":...}

Но дело в том, что согласно документации OAuth2 (в абзаце 5.1) должно быть хотя бы еще один обязательный параметр - "token_type". Итак, вопрос в следующем: можно ли как-то настроить, чтобы API linkedin возвращал этот параметр с ответом на токен доступа, или это просто отступление от правила, и этот параметр не будет возвращен?

Заранее спасибо.


person Pavlo Kolesnykov    schedule 02.02.2018    source источник


Ответы (2)


Я столкнулся с той же проблемой. Согласно документам LinkedIn:

Успешный запрос токена доступа вернет объект JSON, содержащий следующие поля:

  • access_token — токен доступа для пользователя. Это значение должно храниться в безопасности в соответствии с вашим согласием с Условиями использования API.
  • expires_in — количество секунд, оставшихся с момента запроса до истечения срока действия токена. В настоящее время все токены доступа выпускаются со сроком жизни 60 дней.

они отвечают с

{"access_token":"...","expires_in":...}

что нарушает стандарт.

В настоящее время я использую Spring Security 5.0.3, и для решения этой проблемы мне пришлось пропатчить один класс:

com.nimbusds.oauth2.sdk.token.BearerAccessToken

Весь класс выкладывать не буду, только значимую часть:

public static BearerAccessToken parse(final JSONObject jsonObject)
        throws ParseException {

        // Parse and verify type
        AccessTokenType tokenType;
        try {
            tokenType = new AccessTokenType(JSONObjectUtils.getString(jsonObject, "token_type"));
        } catch (ParseException ex) {
            tokenType = AccessTokenType.BEARER;
        }

        if (!tokenType.equals(AccessTokenType.BEARER))
            throw new ParseException("Token type must be \"Bearer\"");
        //...
}
person ka1eka    schedule 14.03.2018

Я надеялся получить ответ от участника Linkedin, так как они заявили на своем сайте, что stackoverflow — подходящее место для таких вопросов. Но поскольку от них нет ответа, и я не нашел никакой соответствующей информации по этому вопросу, я считаю, что именно так они реализовали протокол OAuth 2.0.

person Pavlo Kolesnykov    schedule 06.07.2018