Каждая инженерная команда в конечном итоге сталкивается с этим решением с высокими ставками-которое влияет на безопасность, масштабируемость и скорость продукта-будь то создание аутентификации.
Ставки выросли только по мере того, как современные приложения требуют большего от своих систем AUTH для поддержки таких функций, как отдельный вход, SCIM, RBAC, обнаружение бота и многое другое. Что начинается как простой поток входа в систему быстро, чтобы стать критической инфраструктурой применения.
Да, вы можете построить его. Но настоящий вопрос: вы должны?
Там нет единого ответа. Но как человек, который проводил инженерные команды через это решение несколько раз, я научился распознавать ключевые точки перегиба, где стоит вернуться назад, чтобы переоценить ценность строительства и поддержания собственной аудитории. Наблюдение этих триггеров на раннем этапе поможет вам избежать дорогостоящих перестройков и сосредоточить свою инженерную команду на том, что действительно отличает ваш продукт.
Строительство автора
Инженеры любят строить. Есть гордость за то, что сами решают сложные проблемы, и как только вы пошли по пути, желание совершить и увидеть это. И иногда создание аутентификации на самом деле действительно является правильным вызовом.
Если вы создаете простой прототип на ранней стадии (например, просто имя пользователя/пароль), вам нужен высокоспециализированный UX или работаете в ограниченной среде, такой как локальные, где вы не можете полагаться на сторонние услуги, может иметь смысл. В этих случаях полный контроль над вашими аудирующими потоками имеет приоритет.
Но не заблуждайтесь, создание аутентификации не является проектом; Вы регистрируетесь на долгосрочные инвестиции в инфраструктуру.
Мой опыт создания автоза
В Plaid, платформе подключения к банке, где я работал над бэкэнд-системами для аутентификации и предотвращения мошенничества, нам пришлось создать нашу аутентификацию. Рынок просто не предлагал решения, которые соответствовали нашим требованиям к соблюдению и безопасности в то время, а также обеспечивают достаточный контроль над UX. Но это решение привело к тому, что аутентификация потребляла больше времени, чем ожидалось.
То, что началось как поток входа в систему, стало длинным инженерным путешествием.
Мы потратили много месяцев на создание услуги по обнаружению мошенничества на заказ, чтобы предотвратить начинку по учете и атаки по поглощению счетов, которые каждую неделю требовали постоянного технического обслуживания для продолжения настройки и переработки. Пользователи упали из-за трения в нашем опыте входа в систему, и в то же время мошенники воспользовались нашими банковскими интеграциями для автоматизации попыток поглощения счетов. Многие из банков, с которыми мы работали, не поддерживали многофакторную аутентификацию (MFA), поэтому мы в итоге создали MFA с нуля, поддерживая одноразовые пароли по электронной почте и SMS. Мы обсуждали, следует ли реализовать распознавание лиц или магические ссылки, но сроки для создания их собственных мест было трудно оправдать для того, какое влияние мы получили бы.
Этот опыт научил меня этому зданию внутри дома дает вам гибкость, но это содержится за крутой стоимостью. У вас есть все: управление сеансами, сброс пароля, интеграции, SMS и доставка электронной почты, случаи по краям протокола, обнаружение мошенничества и многое другое.
Строительство автозаправления может быть оправдано, когда вы впервые начинаете, и у вас есть простые, простые требования. Но в большинстве случаев то, что начинается как первое мышление, превращается в медленное сопротивление на инженерной скорости. Вы отправляете медленнее, и ваша команда будет тратить больше времени на поддержание инфраструктуры, чем на продвижение возможностей вашего собственного продукта.
И это приводит к решающему вопросу: укомплектован ли ваша команда для поддержки этой ответственности? Вы нанимаете экспертов по аутентификации и создаете команду идентификации? Или вы просите инженеров -продуктов выучить SAML и OAuth с нуля?
Если вы готовы инвестировать в строительство собственного места, вот современные проблемы с аутентификацией, которые вам необходимо подготовиться по мере масштабирования.
Точки перегиба: как современные требования AUTH Scale
Для аутентификации очень важно думать не только о том, что вам нужно сегодня, но и о том, что вам нужно через шесть месяцев или года.
Аул не статическая особенность. Он развивается — слой от слоя — по мере роста вашего продукта ваша пользовательская база диверсифицирует, а клиенты предприятия представляют новые требования. Со временем простая система, с которой вы начали, вынуждена простираться далеко за пределы своей первоначальной архитектуры.
Каждая инженерная команда, которая строит AUTH Внутренне, будет столкнуться с ключевыми точками перегиба — моменты, когда сложность, риск безопасности и бремя обслуживания начнут перевешивать преимущества контроля.
Многопользо и организации
Первый серьезный скачок в аутентификации обычно происходит при переходе от модели пользовательских данных к многопользовательской модели данных. Чтобы поддержать команды, компании или рабочие места, ваши системы должны различать пользователей и организации.
Строительство многопользовательства означает пересмотр того, как личность, сессии и разрешения охватывают и изолированы среди арендаторов. Он также вводит новый уровень сложности, в котором каждая организация должна будет настроить свои собственные настройки авторов, такие как обеспечение, приглашения участников, разрешенные домены электронной почты, методы аутентификации и многое другое.
Многие команды изначально включают это, только чтобы обнаружить, что модернизация многопользовательских настроек и изолированные в систему с одним оттенком приводит ко многим техническим долгам.
Одиночный вход (SSO)
Как только вы продаете в более крупные предприятия, SSO станет трудным требованием для предприятий. Клиенты хотят интегрироваться со своими собственными поставщиками личности, такими как Okta, Microsoft Entra или Google Workspace, используя такие протоколы, как SAML или OIDC.
Реализация этих протоколов нетривиальна, особенно когда у каждого клиента есть свои собственные причуды и ожидания вокруг адаптации, обмена метаданных и картирования пользователей. И это до того, как вы вступите в поддержание обратной совместимости, отладки тонких ошибок и краев, а также укрепите вашу систему против гнезда уязвимостей безопасности шершня в потоках на основе XML, таких как SAML.
SSO часто является первым местом, где команды начинают искать внешнюю помощь — не потому, что они не могут ее построить, а потому, что они понимают, что предпочли бы потратить время на создание своего продукта.
SCIM и разрешение
После того, как SSO зарегистрировался, следующее требование предприятия часто является SCIM (Система для управления идентификацией междомена). SCIM, также известный как Directory Sync, позволяет организациям автоматически предоставлять учетные записи пользователей через своего поставщика личности. Поддержка его должным образом означает синхронизацию между вашей системой и их и изящной обработкой частичных сбоев.
Поскольку SCIM также включает в себя синхронизацию атрибутов пользователей, таких как отделение, заголовок и роли, которые обычно используются для предоставления и обеспечения разрешений. Это, естественно, вводит следующий уровень сложности: реализация политик авторизации, такую как контроль доступа на основе ролей (RBAC). Клиенты корпорации захотят назначить пользователей на такие роли, как администратор, участник или даже пользовательские роли. На этом этапе ваше собственное решение не просто обрабатывает аутентификацию-оно сейчас отвечает за мелкозернистое разрешение и контроль доступа.
M2M Auth, сторонние приложения и OAuth
По мере расширения вашего продукта вы, вероятно, представите микросервисы или интеграции с внешними API и приложениями. Теперь вы имеете дело с аутентификацией машины-машины (M2M) и сторонними приложениями, которые нуждаются в делегированном доступе к вашему приложению.
Вам необходимо построить поддержку OAuth 2.0-в комплекте с учетными данными клиента, истечением срока действия токенов, потоками обновления, областями областей и экранами согласия-для облегчения интеграции сторонних сторон с вашим собственным приложением. OAuth — это мощный, но очень сложный протокол, и ошибки могут ввести серьезные уязвимости.
Мошенничество и предотвращение рисков
Между тем, по мере того, как растет область поверхности вашего продукта, также вы можете эксплуатировать плохие актеры, которые стремятся использовать вашу платформу. Мошенничество и злоупотребление могут принимать разные формы, часто нацеленные на бесплатный доступ или ресурсы, которые можно использовать с помощью автоматизации. Это включает, но не ограничивается:
- Бесплатное злоупотребление аккаунтом.
- Вычисление и злоупотребление ресурсами.
- Регистрации ботов и фальшивые учетные записи.
- Поглощение учетных записей и начинка по учете учетных данных.
Чтобы смягчить эти угрозы, командам необходимо будет реализовать расширенные функции безопасности, такие как обнаружение бота, снятие спечатков пальцев устройства, двигатели правил безопасности, ограничение динамического ставки и многое другое.
Аутентификация агента AI
Новейшая волна сложности в современной аутентификации поступает от агентов ИИ и приложений с ЛИМ. Эти агенты искусственного интеллекта могут автономно действовать от имени пользователей, инициировать рабочие процессы, запросить API или управлять данными, которые вводят новый набор проблем идентичности и безопасности.
Чтобы поддержать это, вашей системе аутентификации потребуется более надежный делегированный доступ на основе OAuth. Например, агенты ИИ должны динамически зарегистрироваться. В то же время пользователи должны быть в состоянии авторизовать их через потоки согласия человека в петле, с четко определенными областями и возможностью отозвать доступ в любое время.
Это быстро развивающееся пространство, и модели аутентификации и авторизации все еще определяются. Однако, если ваш продукт интегрируется с агентами искусственного интеллекта, ваш стек аутентификации должен быть создан для непосредственной поддержки согласия, делегированного доступа и разрешений.
Последние мысли: постройте то, что отличает вас
Современная аутентификация начинается как простой поток входа в систему, но она не остается так долго. Как масштабируется ваш продукт, также выполняют ваши требования AUTH. Вы переедете от однопользовательских моделей в многопользовательские организации, от паролей до SSO, от базового доступа к SCIM и RBAC, а также от входов пользователей до агентов искусственного интеллекта, действующих автономно от чьего-либо имени. Каждая из этих вех авторов вводит архитектурную сложность — новые краевые случаи, протоколы и обязанности безопасности, которые со временем составляют.
Аутентификация является основополагающей, но для большинства компаний это не то, что делает вас особенным. Лучшие инженерные команды, с которыми я работал, ясны в этих компромиссах. Они фокусируют свою энергию на том, что их отличает — функции продукта, производительность, пользовательский опыт — и они прагматичны в том, что создавать и что купить.
Если вы привержены созданию современной аутентификации, рассматриваемые нами этапы должны помочь вам предвидеть, что впереди, и принять обоснованные решения на каждом этапе.
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Джулианна Лэмб является техническим директором и соучредителем Stytch, идентификационной платформы для разработчиков, где она возглавляет техническое видение компании и усилия по упрощению аутентификации для всех. Подробнее от Джулианны Лэмб
