Кратко

Срок назначал поставщик, книгу счетов вёл сайт

В феврале 2014 года Google приветствовала утверждение OpenID Connect и одновременно назвала дату окончания старого пути: поддержку OpenID 2.0 она прекратит 20 апреля 2015 года. Компания намеревалась сосредоточить федеративный вход на новом стандарте и предлагала собственные инструменты подключения. Времени до отключения оставалось больше года. Но срок принадлежал оператору службы идентификации. Зависимый сайт мог изменить своё приложение, не мог по своему усмотрению продлить работу прежнего входа у Google.

Внутри сайта старый идентификатор давно мог стать ключом к покупке, документу, подписке или правам пользователя. OpenID 2.0 передавал проверенный Claimed Identifier, который сайт мог хранить как ключ аккаунта. OpenID Connect описывает личность иначе: парой издателя токена и субъекта. Человек может быть тем же, а запись для поиска в базе — другой. Успешная новая авторизация без переноса приводит к новому пустому аккаунту. Неверное соединение ключей может открыть историю одного человека другому.

20 марта 2015 года Google повторила предупреждение. OpenID 2.0 и несколько других устаревших способов связи остановятся 20 апреля. Приложения, которые не перейдут на поддерживаемые протоколы, могут лишиться подключения к Google, возможно и функции входа, пока не закончат миграцию. Это было описание риска, а не статистика уже произошедших сбоев. Оно показывало, какую дверь компания действительно могла закрыть: собственный старый пункт аутентификации.

Окончательный текст приняли почти у порога

OpenID Foundation объявила итоги голосования 16 апреля 2015 года: 28 голосов за, ни одного против, четыре воздержавшихся. До назначенной Google даты оставалось четыре дня. Это не срок, отведённый на всю разработку. Компания сообщила о планах в 2014 году, а приложение к окончательному стандарту сравнивает его с руководством Google за июнь того же года. Четыре дня отделяли формальное завершение общей процедуры доказательства связи от запланированного закрытия прежнего входа.

Спецификация начинает с двух различных форм записи личности. В OpenID 2.0 использовался проверенный заявленный идентификатор. В OpenID Connect — пара издателя и субъекта. Сайт добавляет openid2 к области запроса аутентификации, чтобы получить старое имя вместе с новым. Если поставщик знает прежний идентификатор данного пользователя, он помещает его в ID Token как openid2_id. Сайт проверяет токен, а затем должен выяснить, вправе ли его издатель утверждать что-либо о прежнем идентификаторе. Само присутствие старого адреса в новом подписанном сообщении этого права не доказывает.

Окончательный текст даёт проверке место в последовательности. В узком случае сайт может сопоставить общую власть над старым и новым пунктами входа. В остальных он обращается к URI прежнего идентификатора с заголовком Accept: application/json, получает поле iss и требует его точного совпадения с издателем ID Token. Для XRI предусмотрен отдельный путь. Если ни одно подтверждение полномочий не срабатывает, старый идентификатор нельзя использовать для объединения аккаунтов. Лишь после доказательства спецификация советует связать существующий аккаунт OpenID 2.0 с новой парой. Окончательное изменение происходит в базе самого сайта.

Приложение B записывает отличия от руководства Google, датированного июнем 2014 года. Согласно сравнению авторов стандарта, руководство применяло openid.realm, а окончательный текст выбрал openid2_realm; старый идентификатор назывался там openid_id, а в стандарте — openid2_id. Авторы также отмечают отсутствие в том руководстве проверок запрашивающего сайта и полномочий издателя в отношении старого идентификатора, которые входят в окончательный документ. Это сравнение с конкретной версией руководства, а не проверка всех производственных систем Google. Оно объясняет, почему общий способ переноса аккаунтов требовал отдельной формулировки.

Исходные документы не считают завершённых миграций и неправильно объединённых аккаунтов. Для такой оценки нужны журналы отдельных сайтов. Разделение решений уже видно: Google назначила конец своему протоколу, а каждый хранитель старого аккаунта должен был доказать, кому выдаёт доступ к записи.