В чем смысл авторизации через сторонние сервисы ?

Чтобы не регистрироваться на каждом говноресурсе и не запоминать 100500 разных логинов-паролей, очевидно же.

Одна учетка во всех сервисах. Ты никогда не логинился через Google\Facebook чтоли?

С точки зрения владельцев\разработчиков сайта это еще и решает проблему хранения пользователей и вообще поддержки систмы аутентификации - выполнить полтора запроса к сторонней системе проще, чем поддерживать какое-то свое решение с БД и прочим.

Один аккаунт на одну личность на всю жизнь.

Только если сторонняя система упадет - в твою, работает она или нет, войти будет нельзя.

Чтобы копрорациям зла было проще следить за тобой.

Ну, везде есть свои риски.

Не понял, кстати, что за Okta там у ТС, может это внешняя система, но пилит и поддерживает ее та же компания, которая работает и с остальными сайтами этого проекта, тогда возможно что основной профит тут - разделение команд разработки и зон ответственности.

Чтобы не регистрироваться на каждом говноресурсе и не запоминать 100500 разных логинов-паролей, очевидно же.

И при компрометации остаться с голым задом не только перед условной корпорацией (который ты доступ к своему аналу уже сам дал), но и перед всем остальным миром.

Это уже другая сторона вопроса. Но, например, двухфакторная аутентификация.

С точки зрения владельцев\разработчиков сайта это еще и решает проблему хранения пользователей и вообще поддержки систмы аутентификации

Чувак, ты не разрабатывал хранение пользователей. Это вообще не решает. Это как сказать, что битрикс решает проблему обмена номенклатурой и заказами с конфигурацией 1с (битрикс в типичной ситуации не решает, а усложняет)

Я не знаю что там в битрикс, но я занимаюсь системой, через которую могут логиниться пользователи с других систем, плюс был небольшой проектик, где я для этого обращался к гуглу - гораздо проще редиректнуть пользователя на страничку auth-провайдера, получить токен и дернуть необходимые данные (и хранить у себя, соответственно, только необходимые для общения с auth-провайдером данные, и то хранить в каком-нибудь кэше), чем держать БД под пользовательскую информацию, «пароли» (ну не сами, пароли, конечно) + обвязку для их смены, саму систему регистрации и аутентификации пользователей, и в довершение заниматься вопросами что кому-то там письмо не дошло и подобными (небольшой опыт в этом тоже есть, не «продакшн», конечно, но все равно знаю что даже на <50 пользователей тут можно выхватить проблем).

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

Только если сторонняя система упадет - в твою, работает она или нет, войти будет нельзя.

Вероятность что упадет твоя система выше.

Это интернет, детка. Тут не действуют законы логики.
Тут до сих практикуют «отличные» идеи - регистрацию по емайлу, двухфакторная авторизация по смс, передачу конфиденциальных данных по общедоступным сетям (пусть даже с использованием криптосредств, сертифицированных правительствами, лол), доверять CA, подконтрольным АНБ, привязывать банковский счет к платежному говносервису ноунейм компании (говно-кошелек.com и прочие).
Клиентские сертификаты это слишком сложно для пользователя, поэтому нужно было cделать черезжопные решения. А потом, когда все это поломалось в результате очередного факапа, сделать поверх них еще больше черезжопных решений. Одно радует - централизованный интернет катится прямиком в ад. Хотя у распределенного интернета будет та же участь, потому что его развитием занимаются те же лица.

Чья бы ни упала - в-бут в итоге все равно тебя.

Плюсую товарища. Хранить пользователей у себя всё равно придётся. Мало того, ещё и взаимодействие со сторонней системой аутентификации придётся налаживать.

А плюс этой штуки только для пользователя существует: одна учётка для кучи сервисов, не надо логин и пароль придумывать/вспоминать.

Принципиально не регистрируюсь на таких помойках.

И при компрометации остаться с голым задом не только перед условной корпорацией (который ты доступ к своему аналу уже сам дал), но и перед всем остальным миром.

Количество говносайтов настолько зашкалило, что даже если например кучка говносайтов привязанных к одному логину будут скормпрометированы это ничего не меняет - говносайты и есть говносайты.

Это если держать левую учётку для говна и основную для не говна. По аналогии с почтой получается. Но кто так делает? Единицы?

Это если держать левую учётку для говна и основную для не говна. По аналогии с почтой получается. Но кто так делает? Единицы?

То есть надо запоминать стопятсот разных паролей и логинов, да? А так кто делает? Те кто не сможет две учетки разных завести - у них и пароль один на все. И засвечен на стапятсот разных несекурных ресурсов.

Чудес не бывает - любая секрность требует желания и усилий по ее поддержанию.

По аналогии с почтой получается

Кстати, если ты просрёшь почту, то и все учётки на других сайтах тоже угонят. Так что твой предыдущий аргумент так себе.

Это я к тому, что эти «опен идэ» и прочие авторизации через единый акк делают сетку в решете еще крупнее в обмен на якобы удобность.

Не говоря уже о вредности в том плане, что мизерное количество пользователей понимают, что за сомнительный сервис отдают еще часть своей конфиденциальности.

Чем больше уязвимых мест, тем выше вероятность проблем.

А плюс этой штуки только для пользователя существует:

Хм, а профит от собираемых на пользователя данных?

И при компрометации остаться с голым задом не только перед условной корпорацией (который ты доступ к своему аналу уже сам дал), но и перед всем остальным миром.

Корпорация при утечке быстро все заблочит. А вот личный/рабочий комп вирусняк распостраняет годами. Особенно в госорганизациях - были случаи.

Это я к тому, что эти «опен идэ» и прочие авторизации через единый акк делают сетку в решете еще крупнее в обмен на якобы удобность.

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

Еще раз, фраза бесплатный сыр бывает только в мышеловке она и про «кококо у меня все бесплатно на домашнем компе а не в облаке где ты платишь за все личными данными»

Не говоря уже о вредности в том плане, что мизерное количество пользователей понимают, что за сомнительный сервис отдают еще часть своей конфиденциальности.

В обмен на то что их проблемами будут заниматься другие люди. Еще раз - хорошо быть поехавшим на секруности бородатым асоциальным линупс-школьником. Все остальные не админят свой комп по очевидным причинам - и в таком случае перенос сервисов туда где за ними следят это очевидное развитие событий. И облака эти примерно из этого же выросли - из того админить дома подобный сервис будут меньше одного процента людей.

В том, что identity management — очень сложная тема. Существует много всяких требований к жизненному циклу паролей-данных и сертификаций.

Взять хотя бы новые законы России о хранении персональных данных.

Большинство пользователей успешно прошли процедуру регистрации в сервисе Okta, который отныне становится единым центром авторизации и аутентификации, а также единой точкой входа во все наши служебные сервисы.

Okta — довольно крутая система. И реализовывать привязку к ней довольно просто. Гораздо проще, чем разрабатывать identity management у себя.

Плюсую товарища. Хранить пользователей у себя всё равно придётся.

Нет. man shibboleth, saml.

Мало того, ещё и взаимодействие со сторонней системой аутентификации придётся налаживать.

Ерунда по сравнению с хранением identity. Если там веб-приложение, то всё вообще придумано до нас.

Если ты задаешь такие вопросы, у меня для тебя плохие новости

1. Пользователь ленив, и если можно зайти через существующий аккаунт, а не заводить отдельную учётку - пользователей будет больше.
2. Грамотно реализовать аутентификацию не так просто, много подводных камней. А тут умные дяди всё запили и отдали тебе API. IaaS, прикрутил и всё работает.

Нет. man shibboleth, saml.

Что «нет»? Сейчас на пальцах поясню. Вот представь, что мы захотели прикрутить этот самый shibboleth к ЛОРу (или любую другую систему SSO). Вот юзер ткнул в иконку, его перекинуло к провайдеру аутентентификации (или identity provider, как его там называют), там он ввёл свой логин и пароль, провайдер вернул на ЛОР информацию, что всё ок, это тот самый юзер и есть. Хорошо, а что дальше происходит? Вот мы юзера аутентифицировали, дальше его надо авторизовать. Для этого нужно сопоставить его личность (мы её подтвердили) с правами, которые у нас для него на сайте записаны. И вот тут мы приходим к тому, что нам нужно завести локального пользователя, который ничем от других пользователей отличаться не будет, кроме того что он будет связан с айдшником shibboleth. Также и вся активность пользователя на сайте (создание топиков на форуме, написание комментов) тоже будет связана с локальным пользователем. Т.е. буквально там foreign key указывает на табличку с локальными пользователями. Понимаешь?

Прекрасно понимаю.

Для авторизации не обязательно создавать локального юзера. Аутентифицировавшийся пользователь вполне может упасть в какую-то группу и авторизоваться по ролям, присвоенным этой группе. Или авторизовываться по аттрибутам из saml. Более того, можно заиметь авторизацию в том же лдапе, который является бэкендом для identity provider, и ходить за авторизацией в этот лдап.

Вся активность пользователя... можно без записи в таблице, а просто иметь что-то вроде poor man's Fk — хранить в колонках айди из самла.

Но даже если создавать какие-то записи в БД, в них хранится не identity. В них хранится «тень» identity. Этой «тенью» не надо управлять. Ей не надо менять пароль, не надо восстанавливать пароль, не надо проверять сложность пароля, не надо париться о хэшировании, о локауте юзера, о том, как распространяются персональные данные юзера и соответсвуют ли политики стандарту PCI DSS. Это безликий user_id.