Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
Автор, пожалуйста, не путайте людей: OAuth — авторизация, OIDC — аутентификация, но не идентификация. Даже Вики по запросу «идентификация» пишет: «Термин «идентификация» в отношении личности пользователей в информационной безопасности часто ошибочно используется вместо понятий аутентификация и авторизация.»
Так же, в OAuth, ResourceServer НЕ хранит данные пользователей (в контексте OAuth), согласно RFC6749:
resource server
The server hosting the protected resources, capable of accepting
and responding to protected resource requests using access tokens.
т.е. там защищенные ресурсы, те к которым получает доступ пользователь, а не «данные пользователей».
Так же, в OAuth, ResourceServer НЕ хранит данные пользователей (в контексте OAuth), согласно RFC6749:
resource server
The server hosting the protected resources, capable of accepting
and responding to protected resource requests using access tokens.
т.е. там защищенные ресурсы, те к которым получает доступ пользователь, а не «данные пользователей».
Согласен, что с терминами авторизация, аутентификация и идентификация все время путаница. В статье я использую термин “идентификация” как объединяющий для авторизации и аутентификации. Но где, действительно, важна разница там использую конкретные термины.
Название статьи было бы терминологически правильным, но громоздким: “Современные стандарты авторизации: OAuth 2.0 и аутентификации: OpenID Connect, WebAuthn”
Название статьи было бы терминологически правильным, но громоздким: “Современные стандарты авторизации: OAuth 2.0 и аутентификации: OpenID Connect, WebAuthn”
Идентификация, аутентификация и авторизация — три разные понятия. Странно использовать одно из трех, для объединения двух совершенно других.
Согласен, но для обычного пользователя привычен термин идентификация, который обьединяет все 3 понятия. Пытаюсь соблюсти баланс между читаемостью статьи и технической точностью… )
О каких обычных пользователях вы говорите? Не-программистах? Зачем им программистская статья? Или вы не считаете свою статью такой?
Да, мы есть. Мы существуем и читаем такие статьи. Ликбез по «что там творится, если выбрать „Зарегистрироваться через facebook“ очень интересен. Спасибо автору.
У вас в профиле написано — разработчик. Да и описание достаточно хардкорное, вы определенно технарь.
Вы действительно относите себя к "обычным пользователям" и хотели бы видеть не очень корректные термины, потому что они более "привычны"?
P.S. Точность терминов не так уж критична в данном случае, меня удивила мотивация — использовать то, что якобы привычно неким обычным пользователям.
Если бы я писал техзадание для программистов, то, конечно, использовал бы точные термины. Но аудитория Хабра гораздо шире.
После моих предыдущих статей ко мне подходили коллеги и говорили, что наконец поняли как работает блокчейн или облака. Поэтому я упрощаю терминологию так, чтобы и программистам было интересно и “не программистам” понятно)
И ради интереса можно сделать опрос среди программистов о том, кто знает разницу между идентификацией, аутентификацией и авторизацией, у меня есть ощущение, что таких будет явно не большинство)
После моих предыдущих статей ко мне подходили коллеги и говорили, что наконец поняли как работает блокчейн или облака. Поэтому я упрощаю терминологию так, чтобы и программистам было интересно и “не программистам” понятно)
И ради интереса можно сделать опрос среди программистов о том, кто знает разницу между идентификацией, аутентификацией и авторизацией, у меня есть ощущение, что таких будет явно не большинство)
Если уж упомннать OAuth и webAuthn в одной статье, то надо и про Oath сказать
Что за у людей за жажда в простое взаимодействие добавить дополнительных точек отказа?
Урок с OpenId никто не усвоил чтоль, когда все аккаунты попревращались в тыквы? Так же и тут: надо быть уверенным что условный фейсбук не заблокирует пользователя, не заблокирует сервис, на котором авторизуемся, самого фейсбука не заблокирует какой-нибудь госорган или не произойдет какой-нибудь технический сбой, как это было с гуглом относительно недавно.
Урок с OpenId никто не усвоил чтоль, когда все аккаунты попревращались в тыквы? Так же и тут: надо быть уверенным что условный фейсбук не заблокирует пользователя, не заблокирует сервис, на котором авторизуемся, самого фейсбука не заблокирует какой-нибудь госорган или не произойдет какой-нибудь технический сбой, как это было с гуглом относительно недавно.
Вариантов то немного, каждый выбирает сам:
— Продолжаем мучатся с хранением паролей
— Используем широко известные зарубежные сервера для идентификации / аутентификации / авторизации с понятными рисками
— Используем мало распространенные российские системы с непонятными рисками
— Сами разрабатываем и обслуживаем сервера со всеми возможными рисками )
— Продолжаем мучатся с хранением паролей
— Используем широко известные зарубежные сервера для идентификации / аутентификации / авторизации с понятными рисками
— Используем мало распространенные российские системы с непонятными рисками
— Сами разрабатываем и обслуживаем сервера со всеми возможными рисками )
Я лучше помучаюсь. Мне почему-то хорошо запомнилось как схлопнулся myopenid.com, затем один за другим все крупняки начали заменять openid на oauth с вытекающей из этого централизацией.
Возможно придумают какую-нибудь избыточность? Т.е. не смог подключиться к одному, подключился к другому?
Мне, кстати, как-то показалось, что оно уже где-то так и работает. Просто был эккаунт на одном форуме, который был создан через аутентификацию с github. Github чего-то там ругнулся и в итоге через него я не смог зайти на форум. Но я просто нажал «войти через Google» — и вуаля — я опять залогинен на форуме с тем же профилем.
Мне, кстати, как-то показалось, что оно уже где-то так и работает. Просто был эккаунт на одном форуме, который был создан через аутентификацию с github. Github чего-то там ругнулся и в итоге через него я не смог зайти на форум. Но я просто нажал «войти через Google» — и вуаля — я опять залогинен на форуме с тем же профилем.
Необязательно же использовать oidc только по прямому назначению (использовать аутентификацию google, facebook и т.п.). У нас, например, на работе все было завязано на Windows, в т.ч. и аутентификация (ntlm/kerberos) у веб-приложений asp.net. В настоящее время в эпоху импортозамещения переходим на linux, домен пока на Windows. Если раньше с аутентификацией, идентификацией и приложениями, написанными на Net Framework вопросов не возникало, то при ASP.Net Core и Linux в качестве сервера приложений, проблемы с аутентификацией были: приходилось с использованием стороннего nuget-пакета novel.ldap проверять доменные логин и пароль пользователя (SSO не было, схема negotiate не работала). Начиная с Core 3.0 была добавлена возможность использования negotiate с kestrel (т.е. уже можно заголовок Authorization отправлять приложению (вебсервер на линуксе)), но непонятно, как это все в будущем будет работать при изменении версии Core, и придется копипастить аутентификацию из проекта в проект. Плюс еще не решили, на чем разрабатывать будем еще: java, php, python и т.д. Везде своя настройка аутентификации (negotiate). Хотелось в идеале использовать некий стандарт, чтобы любое разрабатываемое приложение, независимо от платформы (публикация) и языка разработки, могло просто использовать его. Доработанный IdentityServer 4 подходит для этого. Доустанавливаем туда пакет Negotiate (есть шаблон IS4 с аутентификацией Windows, но в качестве хоста возможно использовать только IIS, т.е. Windows), делаем его внешним провайдером. Вопрос с аутентификацией решен. Есть самописный сервер авторизации (REST). Настраиваем его в качестве API для клиентов в IS4. С авторизацией вопрос тоже решен. Итого: не нужны Windows'ы (требования к госкомпаниям до 2024 года), т.е. независим от платформы, независим от языка разработки (нужно только настроить разноязыковые проекты на использование oidc). При этом есть прозрачная аутентификация и SSO. Если уходить от домена на что-то другое, то можно доработать IS4 на использование этого другого в качестве внешнего провайдера. Иначе — для разработчиков головная боль с этими импортозамещениями. В общем, с oidc — одной проблемой меньше.
Я понимаю, что с импортозамещением не все однозначно, но в IT сфере вижу, что все куда-то движется: у нас уже есть отечественный процессор Эльбрус, ROSA Linux, блокчейн Мастерчейн, Национальная облачная платформа, Единая биометрическая
система и т.д… На первый взгляд кажется, что сочетание облачной платформы с биометрической могут вполне стать основой для “Национальной платформы для аутентификации” ну и + ГосУслуги для идентификации…
система и т.д… На первый взгляд кажется, что сочетание облачной платформы с биометрической могут вполне стать основой для “Национальной платформы для аутентификации” ну и + ГосУслуги для идентификации…
В энтерпрайзе SAML 2.0 — наше всё. Всё на нём.
Так ли перспективны эти технологии как вы указали в начале статьи?
По мне так в них не хватает кроме идентификации системы управления ключами. Причем не только своими. Но и чужими — управление правами и привилегиями, что то типа атрибутивных сертификатов.
Кто поймет и сделает такое получит хороший бизнес.
По мне так в них не хватает кроме идентификации системы управления ключами. Причем не только своими. Но и чужими — управление правами и привилегиями, что то типа атрибутивных сертификатов.
Кто поймет и сделает такое получит хороший бизнес.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Современные стандарты идентификации: OAuth 2.0, OpenID Connect, WebAuthn