Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 32
Разве OAuth (по крайней мере для facebook'а) не работает точно также как вы описали в сценарии для CAS? Если у нас пользователь не авторизован, то редиректим к facebook'у. Тот либо распознает свои куки, либо спрашивает login/pass. Затем уже с токеном редиректит назад к нам. Мы токен проверяем у фейсбука и открываем для юзера сессию. У себя в проектах использовал, работало.
Хотя опять же зависит от сервиса, у кого авторизуемся. Может кто и спрашивает постоянно login/pass при каждом обращении, не знаю.
Хотя опять же зависит от сервиса, у кого авторизуемся. Может кто и спрашивает постоянно login/pass при каждом обращении, не знаю.
Очевидно, проблема в том, что для каждого сайта из группы пользователю придётся прогулятся на фейсбук и подтвердить авторизацию, а в данном варианте после первой авторизации на любом сайте из группы, можно заходить на остальные без дополнительных телодвижений.
в случае использования CAS вам всё равно при первой попытке авторизации с каждого сайта придётся прогуляться на сервер CAS.
по сути плюс его использования относительно OAuth только в том, что OAuth будет спрашивать разрешения пользователя передать токен сайту для каждого из них, а CAS спрашивать не будет, и будет сразу передавать.
самое тупое решение, приходящее в голову — свой OAuth-провайдер, который не будет спрашивать ничего у пользователя с доверенных сайтов. итого: CAS — велосипед.
по сути плюс его использования относительно OAuth только в том, что OAuth будет спрашивать разрешения пользователя передать токен сайту для каждого из них, а CAS спрашивать не будет, и будет сразу передавать.
самое тупое решение, приходящее в голову — свой OAuth-провайдер, который не будет спрашивать ничего у пользователя с доверенных сайтов. итого: CAS — велосипед.
Наверное есть разница, один раз запрашивать авторизацию для 10 сайтов, или 10 раз для каждого сайта?
А, неправильно прочитал ваш коммент, теперь понятно.
OAuth-провайдер, который ничего не спрашивает и уже залогиненных пользователей, — это OpenID.
вы заблуждаетесь. спрашивать или нет — тоже зависит исключительно от OpenID-провайдера. а OpenID и OAuth — два разных протокола.
Я имею в виду, что OAuth что-то спрашивает как раз потому, что это протокол авторизации. И то, что он спрашивает, — это разрешение пользователя на доступ к определенным операциям, предоставляемым сервисом.
А если сервис ничего не спрашивает в плане авторизации, то никакой авторизации нет, и остаётся только аутентификация, с которой прекрасно справляется OpenID.
То есть, в описанном случае OAuth не нужен, а достаточно только OpenID — для того, чтобы аутентифицировать пользователя.
А если сервис ничего не спрашивает в плане авторизации, то никакой авторизации нет, и остаётся только аутентификация, с которой прекрасно справляется OpenID.
То есть, в описанном случае OAuth не нужен, а достаточно только OpenID — для того, чтобы аутентифицировать пользователя.
в первую очередь OAuth и OpenID выполняют одну и ту же роль: подтверждают стороннему ресурсу, что посетитель является зарегистрированным пользователем провайдера с определённым идентификатором.
доступ к операциям сервиса является вторичной и необязательной функцией OAuth-провайдеров.
доступ к операциям сервиса является вторичной и необязательной функцией OAuth-провайдеров.
Это распространённая ошибка — считать, что у OAuth и OpenID одна и та же роль.
OpenID предназначен для аутентификации, а OAuth — для авторизации.
К аутентификации OAuth плохо приспособлен. Хотя с его помощью и можно осуществлять псевдо-аутентификацию, но это отнюдь не использование по его прямому назначению.
OpenID предназначен для аутентификации, а OAuth — для авторизации.
К аутентификации OAuth плохо приспособлен. Хотя с его помощью и можно осуществлять псевдо-аутентификацию, но это отнюдь не использование по его прямому назначению.
это распространённая ошибка говорить кому-то про распространённые ошибки без каких-либо пруфлинков.
псевдо-аутентификация, или не псевдо, с точки зрения чёрного ящика, они выполняют одну и ту же функцию: предоставляют креденшиалы (будь то токен, или логин-имейл), доверяемые на основании условного доверия к провайдеру.
псевдо-аутентификация, или не псевдо, с точки зрения чёрного ящика, они выполняют одну и ту же функцию: предоставляют креденшиалы (будь то токен, или логин-имейл), доверяемые на основании условного доверия к провайдеру.
Например, вот здесь, в первом ответе, неплохо описано, почему стоит хорошо подумать, прежде чем использовать OAuth для аутентификации.
В этой статье разница между двумя протоколами описана больше с концептуальной точки зрения. Прочитав её, я думаю, вы поймёте, почему я сказал, что у OpenID и OAuth разные роли, и что в описанном вами случае достаточно OpenID.
В этой статье разница между двумя протоколами описана больше с концептуальной точки зрения. Прочитав её, я думаю, вы поймёте, почему я сказал, что у OpenID и OAuth разные роли, и что в описанном вами случае достаточно OpenID.
я не понимаю, что вы мне пытаетесь доказать. я прекрасно знаю, что OAuth отдаёт приложению не фактические креденшиалы, а токен доступа к функциям сервиса. но это лишь говорит о том, что функции OAuth шире функций OpenID, а не отличны от них.
и это лишь теория. на практике, к примеру, фейсбук отдаёт токен, в котором ключём приложения зашифрованы креденшиалы (айди, юзернейм) пользователя.
и если вернуться к началу спора, вы сказали: «OAuth-провайдер, который ничего не спрашивает и уже залогиненных пользователей, — это OpenID». попробуйте воспользоваться любым открытым OpenID
и это лишь теория. на практике, к примеру, фейсбук отдаёт токен, в котором ключём приложения зашифрованы креденшиалы (айди, юзернейм) пользователя.
и если вернуться к началу спора, вы сказали: «OAuth-провайдер, который ничего не спрашивает и уже залогиненных пользователей, — это OpenID». попробуйте воспользоваться любым открытым OpenID
попробуйте воспользоваться любым открытым OpenID провайдером. он спросит: «хотите авторизовать сайт такой-то»?
В токене фейсбука ничего не зашифровано, и расшифровке токен не поддаётся, потому что является случайно сгенерированным уникальным идентификатором, которому в соответствие поставлен id пользователя и приложения в БД фейсбука.
В теории OAuth и OpenID вещи очень разные, но по факту они могут использоваться для аутентификации совершенно на равных условиях (когда аутентифицирующий сайт не требует никакой информации о клиенте, кроме, скажем, идентификатора пользователя, чего вполне достаточно).
Авторизация — дело третье, и в этом топике я вообще этого вопроса не касался.
После написания топика много думал, и понял, что действительно, для нужн аутентификации и CAS и OpenID, и OAuth отлично подходят.
Да, для получения доп. информации о клиенте лучше подходит OAuth, но CAS провайдер может задавать те же самые вопросы, и точно так же передавать дополнительную информацию о клиенте (но не давать делать вызовы API от имени клиента, это не предусмотрено). Можно схожий функционал сделать и для OpenID, но смысла в этом нет.
Вообще, OpenID и OAuth идут в одном и том же направлении в последнее время, пытаясь угодить всем сложным вариантам использования. Думаю, нужно запастись попкорном.
Хотел написать интересный топик про аутентификацию и авторизацию сайтов с помощью Facebook и Вконтакте, но у первого так всё просто, а у второго так всё плохо, что на топик даже не тянет.
В теории OAuth и OpenID вещи очень разные, но по факту они могут использоваться для аутентификации совершенно на равных условиях (когда аутентифицирующий сайт не требует никакой информации о клиенте, кроме, скажем, идентификатора пользователя, чего вполне достаточно).
Авторизация — дело третье, и в этом топике я вообще этого вопроса не касался.
После написания топика много думал, и понял, что действительно, для нужн аутентификации и CAS и OpenID, и OAuth отлично подходят.
Да, для получения доп. информации о клиенте лучше подходит OAuth, но CAS провайдер может задавать те же самые вопросы, и точно так же передавать дополнительную информацию о клиенте (но не давать делать вызовы API от имени клиента, это не предусмотрено). Можно схожий функционал сделать и для OpenID, но смысла в этом нет.
Вообще, OpenID и OAuth идут в одном и том же направлении в последнее время, пытаясь угодить всем сложным вариантам использования. Думаю, нужно запастись попкорном.
Хотел написать интересный топик про аутентификацию и авторизацию сайтов с помощью Facebook и Вконтакте, но у первого так всё просто, а у второго так всё плохо, что на топик даже не тянет.
токен у фейсбука состоит из двух частей.
developers.facebook.com/docs/authentication/signed_request/
> Можно схожий функционал сделать и для OpenID, но смысла в этом нет.
а смысл для какого-то левого CAS?
> у второго так всё плохо, что на топик даже не тянет.
ещё год назад писал для него адаптер авторизации. через JS API всё тривиально, через oauth2 всё, как у всех.
developers.facebook.com/docs/authentication/signed_request/
> Можно схожий функционал сделать и для OpenID, но смысла в этом нет.
а смысл для какого-то левого CAS?
> у второго так всё плохо, что на топик даже не тянет.
ещё год назад писал для него адаптер авторизации. через JS API всё тривиально, через oauth2 всё, как у всех.
Произошла подмена понятий. signed_request передаётся в редких случаях, а я имел в виду полноценный access_token.
CAS — и протокол, и готовый продукт, с готовой интеграцией с хранилищами пользователей, несложный в установке, настройке и поддержке. Протокол да, ничего особенного, но работает вполне так, как от него этого ожидают.
И несмотря на то, что OpenID провайдеры из коробки не умеют SSO, и это легко устранимо, это означает то, что требуется доработка. А вы, конечно, понимаете, что доработка, особенно готового продукта в рамках разработки корпоративных и государственных продуктов сулит составление пакета отдельного пакета документации на подсистему. Поверьте, вы этого не хотите. Проще косвенно упомянуть его в паре руководств. Добавьте к этому юридический аспект (использование доработанного стороннего продукта в рамках комплексной системы), и выбор в сторону CAS становится очевидным.
И несмотря на то, что OpenID провайдеры из коробки не умеют SSO, и это легко устранимо, это означает то, что требуется доработка. А вы, конечно, понимаете, что доработка, особенно готового продукта в рамках разработки корпоративных и государственных продуктов сулит составление пакета отдельного пакета документации на подсистему. Поверьте, вы этого не хотите. Проще косвенно упомянуть его в паре руководств. Добавьте к этому юридический аспект (использование доработанного стороннего продукта в рамках комплексной системы), и выбор в сторону CAS становится очевидным.
Возможно, вы захотите это прокомментировать. Возможно, за год только добавилось проблем. JS API не имеет привязок к OAuth2.
Интересная статья.
Есть еще разрабатываемый командой Identity Team из Mozilla Labs — browserid.
Хотелось бы почитать мнения и о нем. Ибо не встречал на хабре ничего об этом.
Есть еще разрабатываемый командой Identity Team из Mozilla Labs — browserid.
Хотелось бы почитать мнения и о нем. Ибо не встречал на хабре ничего об этом.
Правильно ли я понимаю, что примерно так работает login.webmoney.com?
1) Насколько я знаю, CAS-сервер не должен делать автоматического перенаправления назад на сайт (если cookie уже есть), а всё равно должен спросить согласие пользователя. Т. е. вход получается непрозрачный (надо делать дополнительный клик и будет виден интерфейс CAS-сервера). Можно конечно это правило проигнорировать в своей реализации… Я в своей реализации на drupal это пробовал делать, но в итоге отключил.
2) Если на сайте должен быть предусмотрен и анонимный просмотр, тогда переход на CAS-аутентификацию должен быть по запросу (при клике «войти»). Опять же не прозрачно, надо кликать, потом опять кликать подтверждение.
2) Если на сайте должен быть предусмотрен и анонимный просмотр, тогда переход на CAS-аутентификацию должен быть по запросу (при клике «войти»). Опять же не прозрачно, надо кликать, потом опять кликать подтверждение.
Поправьте, пожалуйста:
- «Критка и мифы» → Критика
- «cайтом, на которым вы хотите аутентифицироваться» → котором
- «с испольованием разных технологий» → использованием
- «не подтвеждая свою личность» → подтверждая
- «подтвеждение через ссылку» → подтверждение
- «вопросы хранения аутенитификационных данных» → аутентификационных
- «Можно испльзовать вариант» → использовать
Если уж говорить о собственном сервере для SSO, то в этом случае недостаток, который вы указали для OpenID, легко устраним. И для проекта, которым я в данный момент занимаюсь, я выбрал для SSO именно собственный провайдер OpenID. Кроме простого SSO с использованием логин/пароля мне от провайдера требовался ещё и дополнительный функционал (аутентификация через соц. сети и др. OpenID/oAuth провайдеры, личный кабинет, внутренний API с авторизацией через oAuth и т.д.). Поэтому тот факт, что полноценная реализация CAS провайдера есть только на языках, которые в данный момент не являются моими фаворитами оказался существенным минусом для этого протокола.
При входе на целевой сайт вас отправят на coolopenid.net, там либо посмотрят cookie, если вы уже залогинены, либо спросят емейл и пароль, вы подтвердите свою личность, и далее входите на целевой сайт, как, например, foo1@coolopenid.net. Правда, не намного проще, чем подтвеждение через ссылку на электронную почту?Не, ну критика должна быть обоснованной. Пользователь освобождается от необходимости запоминать пароли на толпах сайтов и регистрироваться на них, даже если ему этот сайт требуется один раз в жизни.
И потом, если вся проблема в использовании OpenID и OAuth в том, что пользователю приходится каждый раз подтверждать что-то там при заходе на каждый новый сайт, то это легко лечится минимальными изменениями в коде провайдера. Ввиду нашей специфики никакое подтверждение не нужно.
Но вот какая штука. При работе с любой из упомянутых технологий, если я всё верно понимаю, авторизация каждого пользователя хранится на каждом отдельном сервере. И возможна ситуация, когда в одном окне браузера пользователь сделал выход, а в другом он по-прежнему авторизован на одном (или на всех сразу) из сайтов. Кажется, что система для межсайтовой аутентификации должна исключать такие ситуации.
Есть еще множество реализаций протокола CAS на python.
Например, django-cas-provider или CAS сервер Mozila secret-squirrel
В качестве клиента самым продвинутым был django-cas
Например, django-cas-provider или CAS сервер Mozila secret-squirrel
В качестве клиента самым продвинутым был django-cas
ООО Пирж это ты!
CAS я так понимаю работает по томуже механизму, что и OAuth, только не умеет запрашивать права на дополнительне функции.
и где тогда плюшки?
и где тогда плюшки?
Если я верно понял, то каждый из наших ресурсов должен будет иметь свою подсистему для работы с сессиями аутентификации.
В принципе можно на её место поставить библиотеку, которая будет обращаться к некоторому сервису хранения сессий, а CAS делегировать право на установку cookie с id сессии.
Но, все равно будет требоваться редирект для запроса аутентификации, а когда веб-ресурс содержит контент, который может быть доступен без идентификации, не ясно когда этот редирект должен быть выполнен.
В принципе можно на её место поставить библиотеку, которая будет обращаться к некоторому сервису хранения сессий, а CAS делегировать право на установку cookie с id сессии.
Но, все равно будет требоваться редирект для запроса аутентификации, а когда веб-ресурс содержит контент, который может быть доступен без идентификации, не ясно когда этот редирект должен быть выполнен.
сделал собственный сервер sso
всего 20 строчек кода
особенность в том, что на множестве сайтов есть единое хранилище сессий.
про алгоритм работы можно найти в моем блоге
всего 20 строчек кода
особенность в том, что на множестве сайтов есть единое хранилище сессий.
про алгоритм работы можно найти в моем блоге
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Одновременная межсайтовая аутентификация без велосипеда