Не удается аутентифицироваться с новой конечной точкой токена Google OAuth 2.0 (v3)

У меня есть куча тестов с использованием учетных записей Google в качестве поставщика удостоверений с OAuth 2.0, которые с 5 декабря не работают с ошибкой в поле expires_in ответа маркера доступа не, что больше не является JSON Number но String (я использую grant_type=authorisation_code, но это не должно иметь никакого значения):Не удается аутентифицироваться с новой конечной точкой токена Google OAuth 2.0 (v3)

{ 
    "access_token": "ya29.1gD56tBWtHW3K7oZ0FINTnsqa4VYiE2YGZeQXgJ4ID79E-mZxNWoyYi7pKrs_Vyxj8FZbuxh_RGTJw", 
    "token_type": "Bearer", 
    "expires_in": "3600", 
    "refresh_token": "1/dGjGYC7sDFaBwpdUVpkJP2mYFYTU8HAh7T6szsKGYTs" 
}

Я не с помощью любого OAuth 2.0 библиотеки клиента, поэтому я иметь дело непосредственно с Содержание JSON.

Я заметил, что как веб-страницы разработчиков OpenIDConnect, так и OAuth2WebServer были обновлены 5 декабря.

Поскольку нет истории, я не мог четко видеть, что изменилось, но я заметил, что URL-адрес конечной точки маркера (возвращаемый конечной точкой OpenID Connect) имеет теперь сегмент пути v3/.

После некоторого поиска в Google я нашел старую конечную конечную точку (https://accounts.google.com/o/oauth2/token), и кажется, что эта конечная точка возвращает мне ответ токена доступа с expires_in, выраженный как номер JSON.

После прочтения спецификации OAuth 2.0 мне кажется, что expires_in следует выражать как число, а не строку, поэтому новый формат ответа не соответствует стандарту.

См. RFC 6749, раздел 4.1.4 и приложение № 14 для синтаксиса expires_in (только цифры).

Есть ли планы исправить это на стороне Google? Или мы (любой клиент OAuth 2.0 на самом деле) должны иметь дело с дополнительным специальным случаем (назовем эту гибкость :))?

источник

2014-12-08 Guillaume

Спасибо, что привлекли это к нашему вниманию.

Я нажал изменение, которое обновляет эту конечную точку, чтобы вернуть поле expires_in как номер JSON, а не в строку, как в спецификации от RFC 6749.

источник

2014-12-12 00:23:57 mdietz

Спасибо @mdietz, теперь я вижу конечную точку токена v3, возвращающую номер JSON вместо JSON String – Guillaume

С одной стороны, «expires_in» является рекомендуемым полем, а не обязательным; поэтому ваша реализация должна быть подготовлена для устранения пропущенных или ошибочных значений синтаксического анализа.

Но, конечно, Google должен следовать спецификации, если они намереваются предоставить эту функциональность. Я связался с Googler'ом в списке рабочих контактов OpenID Connect для этого, надеясь, что они ответят соответствующим образом.

источник

2014-12-08 20:31:36

Это больше похоже на комментарий, чем ответ. Кроме того, я не уверен, что согласен, что только потому, что поле рекомендуется, вы должны быть готовы принять значения, не соответствующие спецификации. Отсутствуют, да, но когда они присутствуют, они все равно должны соответствовать спецификации. – MrPotes

считают оптимальной практикой для синтаксического анализа ввода; реализация не должна нарушать его, что, судя по всему, произошло здесь; также (хотя и не рекомендуется) объекты JSON могут иметь несколько значений для одного и того же ключа, поэтому, когда это так, любые строковые значения должны игнорироваться, а числовое значение должно быть проанализировано –

Спасибо за комментарии и рекомендации. Я исправил свою сторону и хотел, чтобы Гуглеры узнали об этом регрессе. Надеюсь, скоро мы увидим улучшения :) – Guillaume

Спасибо, что сообщили нам. Мы изучаем это и попытаемся исправить это в ближайшее время.

источник

2014-12-08 20:41:15 nvnagr

Не удается аутентифицироваться с новой конечной точкой токена Google OAuth 2.0 (v3)

ответ

Смежные вопросы