Comments 16
Очень похожая ситуация в протоколе FIX (протокол обмена финансовыми сообщениями). Он очень подробный, в нем описаны сотни видов сообщений между акторами, в них тысячи полей...
По факту, все компании реализуют своё маленькое подмножество протокола + накидывают свои расширения.
Ох, свежая мозоль прям заныла. Почти месяц недавно угробил на авторизацию через ну очень кастомный OAuth 1.0a. С дополнительной криптографией. С почти отсутствующей документацией, да еще и содержащей ошибки. Часть параметров в заголовках, часть в теле json-ом. Вместе с документацией выдали исходники каких-то проектов на Vuejs/Java - а там все через Store, с кучей хранимых состояний, - никаких чистых функций, чтобы было хотя бы понятно, что именно передается. Всех и вся проклял на отладке. Часть информации оказалось возможно узнать только через обращение в техподдержку - чуть не десяток раз заходили в тупик и таки задавали вопросы. А, еще и само API имело состояние + короткие пути, так что после одного корректного запроса через выданный проект могло некоторое время успешно отвечать на некорректные запросы (!) из портированной реализации, так что даже просто необходимый тут TDD дал сбой из-за ложно-положительных наборов исходных данных и результатов.
Ну OAuth 1.x был архитектурной ошибкой, неудивительно что там все плохо. Надо стараться его не использовать по возможности (разве что для легаси, где вариантов нет).
2.x не так уж и плох, если руку набить. Я бы сказал, что самая главная непреодолимая проблема там - это отсутствие четкого требования в стандарте, что получение нового рефреш-токена должно быть идемпотентным (т.е. если мы отправили запрос, а ответ прос%али, то должна быть возможность попробовать еще сколько угодно раз). Некоторые вендоры так и делают, а некоторые (из неопытных) не «просекли фишку». Про race condition - ну это же на стороне клиента логика довольно несложная, нужно делать глобальный мьютекс на получение нового аксесс- и рефреш-токена.
В самом начале статьи написано, если я смогу реализовать меньше чем за 10 минут, то вы угостите меня ужином. Готов показать и продемонстрировать подключение по auth2 использую готовую шаблонную наработку на nodejs. Мне достаточно 3-5 минут, внести данные куда, как и что и я могу получать oauth ключи для работы с апи) правда я изначально затратил порядка 2-3 часов чтобы разработать свой механизм получения и обновления, но сейчас мне достаточно сделать ctrl+c и в новом проекте ctrl+v , и я могу быть спокойным что у меня всегда будут актуальные ключи для работы.
Но, по крайней мере, я могу выбирать свой URL обратного вызова, ведь так?
Если выбрать в качестве обратного вызова «localhost:3003/callback» для Slack API, он любезно напомнит вам «для безопасности использовать https». Да, даже для localhost. К счастью, существуют решения для перенаправления OAuth на localhost.
Это вы еще не по всем граблям прошлись. Даже если воспользоваться средствами редиректа на http://localhost, то в ситуации, когда в браузере включен режим только HTTPS, вас сам браузер принудительно отправит на https://localhost
Общая проблема слишком раздутых стандартов, которые пытаются объять необъятное. В итоге имеем кучу лишнего и неменьшую кучу неописанного, но всё равно кому-то нужного фукнционала. Плюс зоопарк кастомных реализаций по принципу "кому очень надо - сами разберутся с нашими костылями". Но что по этому поводу думают разработчики стандарта?
заменить oauth на XXX и размыть подробности и мы получим в целом проблемы современных как софта так и железа:
1) переусложено
2) куча реализаций разного уровня всратости
3) каждый думает что сделает лучше
4) ломает совместимость с чем либо
с OIDC проще
OIDC прексрасная вещь, но все же не тривиальная. Недавно делал библиотеку и вместо проекта на один вечер, это вылилось в две недели каждый день по 4-5 часа после работы.
OAuth — это стандартный протокол. Ведь так?
Не так. У вас (а точнее у автора оригинальной статьи) куча ошибок в слове протоколфреймворк (о чём честно сказано в заголовке базовой RFC). Всё остальное, что описано в статье - это следствия данного факта. Когда нам вместо конкретного протокола выдают фреймворк, на базе которого каждый должен собрать собственный вариант протокола - мы неизбежно получаем все описанные в статье проблемы. А внешная похожесть этих протоколов создаёт исключительно неоправданные ожидания - от ожиданий того, что одна реализация будет работать со всеми сервисами до ожиданий того, что все протоколы обеспечивают одинаковый уровень безопасности.
Собственно, основное, чего ждут от протокола аутентификации и авторизации - безопасность. И OAuth 2.0 в этом плане - полный провал. Просто потому, что избыточная гибкость фреймворка создала слишком много возможностей что-то сделать небезопасно, и, внезапно, очень многие этими возможностями радостно воспользовались.
Без мата про это гавно даже говорить невозможно.
А уж когда, эту срань прикручивают для автоизации, какой-нить странички с котиками в сервисах, только потому, что "вот есть стандартная библиотека", офис неразгромлен, только от понимания цены оборудования.
И да. Ни разу не видел двух совместимых версий одной и той же "совместимой библиотеки"
Почему работать с OAuth сложно даже сегодня?