Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 65
разрыв шаблона. «Блогозапись» и не Мицгол >_<
Все суета сует.
Спасибо; сохранил ваш пост по Ctrl-S.
намек понял
Чуть проще www.peeep.us/92ad2d38
спрашивайте ваши ответы кстати, если какая то атака не понятна
ВК, для новых приложений теперь возвращаем ошибку, для старых дополнительные поля error и info. Спасибо за информацию.
«После прочтения сохранить» — применимо ко многих постам на Хабре
T.chikey.nyancat.post ;)
Мне мерещится, что хабр уже сам такой большой, что мог бы выступать в роли провайдера.
Почитал описание вашего Oauth2.a — как-то все не очень внятно. Вроде читаешь — правильные слова, а смысл всей это канители ускользает. Не проще ли было бы показать отличия от стандартного OAuth2.draft31, пояснить что «вот в Oauth2 с нашей т.з. есть такие проблемы, неудобства и все такое, мы решаем это вот таким способом....»
Зачем серверу передавать указание на display=popup\page? Вы хотите в стандарте обязать сервер показывать страницы конкретными способами? Почему не использовать разные URL для этой цели, например authorize_page authorize_popup- и серверу проще и в стандарт не просочится далекое от авторизации требование…
Зачем серверу передавать указание на display=popup\page? Вы хотите в стандарте обязать сервер показывать страницы конкретными способами? Почему не использовать разные URL для этой цели, например authorize_page authorize_popup- и серверу проще и в стандарт не просочится далекое от авторизации требование…
в том то и дело что стандарт oauth2.a проще описать своими словами чем перечислить все отличия. вот они:
1. code access_token refresh_token — все это token
2. mass refreshing токенов
3. scope может быть frozen/agile
4. 1 redirect_uri, scope, response_type на всего клиента
насчет урлов — роутеру приложения как раз не удобно парсить auth_1 auth_2 и проще принять это как параметр. вообще, display это как пример. в стандарте ему делать нечего
1. code access_token refresh_token — все это token
2. mass refreshing токенов
3. scope может быть frozen/agile
4. 1 redirect_uri, scope, response_type на всего клиента
насчет урлов — роутеру приложения как раз не удобно парсить auth_1 auth_2 и проще принять это как параметр. вообще, display это как пример. в стандарте ему делать нечего
1.Это вроде имеет принципиальное значение для TokenExchange Endpointа
2. Отписал ниже
3. Непонятно, что значит frozen\agile, пояснений этим терминам нету, каждый подразумевает что угодно, например я считаю что это «замороженный\гибкий» — откровенная хрень в данном контексте, но ничего другого придумать не могу, а пояснений нету.
4. Отписал ниже
Тогда где есть описание предлагаемого именно «стандарта», а не «своими словами»?
2. Отписал ниже
3. Непонятно, что значит frozen\agile, пояснений этим терминам нету, каждый подразумевает что угодно, например я считаю что это «замороженный\гибкий» — откровенная хрень в данном контексте, но ничего другого придумать не могу, а пояснений нету.
4. Отписал ниже
Тогда где есть описание предлагаемого именно «стандарта», а не «своими словами»?
Насчет урлов — вопрос спорный, кому-то удобней параметрами кому-то урлами, фиксировать такое в стандарте — нехорошо.
Как впрочем и про передачу в #fragment части — вы принуждаете пользоваться яваскриптом для парсинга.
Не всегда на конце User будет находиться браузер с поддержкой яваскрипта и вообще с человеком, смотрящим в дисплей. Там может быть любая другая автоматическая хрень, которая умеет отрабатывать редиректы и авторизовываться на сервере (отправлять постом логин пароль, куки, кликать на кнопку и т.д). Требование яваскрипта или разбора #fragment на клиенте — спорное.
Как впрочем и про передачу в #fragment части — вы принуждаете пользоваться яваскриптом для парсинга.
Не всегда на конце User будет находиться браузер с поддержкой яваскрипта и вообще с человеком, смотрящим в дисплей. Там может быть любая другая автоматическая хрень, которая умеет отрабатывать редиректы и авторизовываться на сервере (отправлять постом логин пароль, куки, кликать на кнопку и т.д). Требование яваскрипта или разбора #fragment на клиенте — спорное.
не спорное. как раз эти моменты давно утверждены в OAuth2 и им нет замены. Объяснять долго но суть в том что хеш не идет на сервер что предотвращает лики
в Oauth2 есть сценарий, который позволяет это обойти, Server-side flow, где реально нужны только редиректы а не разбор #fragment на клиенте. У вас такого варианта вроде как нету.
поясните. у меня есть оба сценария. только server/client side выбирается в настройках приложения а не параметром в урл
кстати насчет agile/frozen homakov.blogspot.com/2012/08/how-to-cheat-on-facebook-apps.html
There are two ways to fix it (OAuth2.a deals with the issue this way):
1) when app has «frozen» scope. This is not param in URL anymore, just a field in the database. Developer don't need to check what is allowed anymore — he is sure.
2) when app has «agile» scope. Client 'proposes' scope and User can uncheck not desired permissions. App should check explicitly what is allowed for certain token.
There are two ways to fix it (OAuth2.a deals with the issue this way):
1) when app has «frozen» scope. This is not param in URL anymore, just a field in the database. Developer don't need to check what is allowed anymore — he is sure.
2) when app has «agile» scope. Client 'proposes' scope and User can uncheck not desired permissions. App should check explicitly what is allowed for certain token.
это должно быть в т.н. стандарте, а не в вашем блоге.
Советую тогда еще добавить концепт, что приложение само может иметь ограничение по scopes — очень удобно раздавать так права на API приложениям, например доступ к некоторым частям API закрывается исходя из того, что приложение не имеет права запрашивать определенные scope и они явно выкидываются из запрошенного набора, даже не показываются пользователю.
dostup zakrivaetsya smotrya na nalichie scope — tak eto samaya osnova oauth2. poyasnite eshe raz?
Помимо того что у токена есть набор scopes (заказаных при создании), у самого client application есть свой набор scopes. Когда клиентское приложение обменивает подписанный токен (code) на access_token — в ответе с access_token приходит фактически выданный scope.
Ну например — у приложения нет возможности обращаться к API со scope=user_management, пока представители явно не заключат юридический договор с провайдером api.
Приложение может попытаться отправить юзера за токеном с таким scope, но при фактической выдаче access_token ( у нас реально еще при показе гуя пользователю т.к. мы сами генерим токены которые потом должны прийти на подпись) из запрошенного перечня scope выкидывается набор scope который отсутствует еще и у приложения.
Велосипед конечно, но оказался довольно удобным для разруливания прав приложения
Ну например — у приложения нет возможности обращаться к API со scope=user_management, пока представители явно не заключат юридический договор с провайдером api.
Приложение может попытаться отправить юзера за токеном с таким scope, но при фактической выдаче access_token ( у нас реально еще при показе гуя пользователю т.к. мы сами генерим токены которые потом должны прийти на подпись) из запрошенного перечня scope выкидывается набор scope который отсутствует еще и у приложения.
Велосипед конечно, но оказался довольно удобным для разруливания прав приложения
Помимо того что у токена есть набор scopes (заказаных при создании), у самого client application есть свой набор scopes. Когда клиентское приложение обменивает подписанный токен (code) на access_token — в ответе с access_token приходит фактически выданный scope.
да. это вопрос или ответ? все правильно
вашу идею понял. привнести еще один лэер скоупов — более крутой с доп правами, только для избранных. хорошая идея
да. это вопрос или ответ? все правильно
вашу идею понял. привнести еще один лэер скоупов — более крутой с доп правами, только для избранных. хорошая идея
ээх нету редактирования коммента…
И да, в вашем упрощении вы потеряли одну сторону — у вас провайдер ресурсов и сервер авторизации — один юнит.
Это далеко не всегда так. Возьмите тот же гугл — сервер авторизации и resource provider — очень разные сущности. Это функционально нужно и полезно, зачем сводить это до единственного provider у которого и API и Oauth2 интерфейс для авторизации клиентов, заранее сужая область применения.
Да и mass refresh — имхо сомнительная фича. Вы хотите чтобы клиент мог одним запросом к серверу обновить over9000 токенов? Ну я так заддосю сервер — отправляя все токены каждую секунду на рефреш я буду порождать избыточное потребление ресурсов — серверу все токены надо перевыписать, а если для выписывания используется не рэндом а крипта какая-нить — будет еще печальней.
Не лучше ли делать lazy-refresh — т.е. реально когда понадобится обратиться к апи а токен протух — сделать быстрое обновление 1 токена…
Последнее требование в readme.md совсем стремное:
Выходит, я при всем желании не могу авторизовать через такого провайдера несколько своих сайтов, если они предоставляют разный функционал на разных URL. И такая полезная штука как Single SignOn ( залогинился в одном сайте компании = залогинен везде, например StackOverflow Network) должна быть реализована вручную, а не через implicit авторизацию. Плохая идея.
И да, в вашем упрощении вы потеряли одну сторону — у вас провайдер ресурсов и сервер авторизации — один юнит.
Это далеко не всегда так. Возьмите тот же гугл — сервер авторизации и resource provider — очень разные сущности. Это функционально нужно и полезно, зачем сводить это до единственного provider у которого и API и Oauth2 интерфейс для авторизации клиентов, заранее сужая область применения.
Да и mass refresh — имхо сомнительная фича. Вы хотите чтобы клиент мог одним запросом к серверу обновить over9000 токенов? Ну я так заддосю сервер — отправляя все токены каждую секунду на рефреш я буду порождать избыточное потребление ресурсов — серверу все токены надо перевыписать, а если для выписывания используется не рэндом а крипта какая-нить — будет еще печальней.
Не лучше ли делать lazy-refresh — т.е. реально когда понадобится обратиться к апи а токен протух — сделать быстрое обновление 1 токена…
Последнее требование в readme.md совсем стремное:
Every Client has 1 redirect_uri, 1 scope and 1 response_type. They are defined in settings of application and cannot be changed during authorization process(scope can be adjusted if it's not «fixed»).
Выходит, я при всем желании не могу авторизовать через такого провайдера несколько своих сайтов, если они предоставляют разный функционал на разных URL. И такая полезная штука как Single SignOn ( залогинился в одном сайте компании = залогинен везде, например StackOverflow Network) должна быть реализована вручную, а не через implicit авторизацию. Плохая идея.
>И да, в вашем упрощении вы потеряли одну сторону — у вас провайдер ресурсов и сервер авторизации — один юнит.
это пока. потом выпилю авторизацию в gem railsengine и это будут отдельные вещи
>Да и mass refresh — имхо сомнительная фича. Вы хотите чтобы клиент мог одним запросом к серверу обновить over9000 токенов? Ну я так заддосю сервер — отправляя все токены каждую секунду на рефреш я буду порождать избыточное потребление ресурсов — серверу все токены надо перевыписать, а если для выписывания используется не рэндом а крипта какая-нить — будет еще печальней.
Не лучше ли делать lazy-refresh — т.е. реально когда понадобится обратиться к апи а токен протух — сделать быстрое обновление 1 токена…
именно, чтобы одним запросом обновил кучу токенов. какой дос Оо. все это легко пресекается. Мас рефреш не обязателен, можно отсылать и по одному токену, только это неудобно не для провайдера не для клиента. Куда лучше по крону раз в час обновлять нужные вещи. подумайте еще раз, фича отличная
>Выходит, я при всем желании не могу авторизовать через такого провайдера несколько своих сайтов, если они предоставляют разный функционал на разных URL. И такая полезная штука как Single SignOn ( залогинился в одном сайте компании = залогинен везде, например StackOverflow Network) должна быть реализована вручную, а не через implicit авторизацию. Плохая идея.
зашибись идея. читайте threat model внимательно. Это все как для секюрити так и для удобства. Если вам принадлежит 1 redirect_uri то вы с помощью ловкости рук и никакого мошенничества запишите код в сессию и перекинете пользователя на подсайт. Implicit вообще должен использоваться когда нет бекенда. Например мобильные приложения или чисто js сайт.
никаких неудобств это не создает, зато предотвращает массу атак которые я изучал
это пока. потом выпилю авторизацию в gem railsengine и это будут отдельные вещи
>Да и mass refresh — имхо сомнительная фича. Вы хотите чтобы клиент мог одним запросом к серверу обновить over9000 токенов? Ну я так заддосю сервер — отправляя все токены каждую секунду на рефреш я буду порождать избыточное потребление ресурсов — серверу все токены надо перевыписать, а если для выписывания используется не рэндом а крипта какая-нить — будет еще печальней.
Не лучше ли делать lazy-refresh — т.е. реально когда понадобится обратиться к апи а токен протух — сделать быстрое обновление 1 токена…
именно, чтобы одним запросом обновил кучу токенов. какой дос Оо. все это легко пресекается. Мас рефреш не обязателен, можно отсылать и по одному токену, только это неудобно не для провайдера не для клиента. Куда лучше по крону раз в час обновлять нужные вещи. подумайте еще раз, фича отличная
>Выходит, я при всем желании не могу авторизовать через такого провайдера несколько своих сайтов, если они предоставляют разный функционал на разных URL. И такая полезная штука как Single SignOn ( залогинился в одном сайте компании = залогинен везде, например StackOverflow Network) должна быть реализована вручную, а не через implicit авторизацию. Плохая идея.
зашибись идея. читайте threat model внимательно. Это все как для секюрити так и для удобства. Если вам принадлежит 1 redirect_uri то вы с помощью ловкости рук и никакого мошенничества запишите код в сессию и перекинете пользователя на подсайт. Implicit вообще должен использоваться когда нет бекенда. Например мобильные приложения или чисто js сайт.
никаких неудобств это не создает, зато предотвращает массу атак которые я изучал
mass refresh — хорошо для школьных приложений с 10 пользователями. Проверните его на сайте с 100к или с 1млн пользователей — захлебнетесь, по крону, раз в час. А если реальные обращения пользователей происходят раз в день (99% браузерных игр) — 23 бессмысленных масс обновления.
Да и с точки зрения программирования — это костыли и ненужная работа. Делать надо только то, что запрашивается и только тогда, когда запрашивается.
Ну и последний гвоздик — представьте у вас 100к пользователей, обновление раз в день (даже не в час) по крону, но реально активных осталось 10. Ради этих 10 вы будете гонять несколько мегабайт запросов (100к строк в json даже если убрать ненужный token — при длине токена в 64 символа — дает 6,4Мб на запрос). Ну или будете придумывать всякую хрено-эвристику — этих обновляем, этих не обновляем, потому что столько раз не заходили.
Поверьте, индукодеры не будут этим заниматься и будут слать все токены всех пользователей каждый час. Потому что «стандарт позволяет» создавать такую нагрузку. А сервер, как дебил, имплементировавший такой стандарт, будет с этим бороться, тратя свои ресурсы.
Про multiple URL — ну да, при таком отношении к критике — пусть будет зашибись.
В чем проблема на сервере проверять redirect_uri не на совпадение с 1 строкой, а на совпадение с несколькими. Я в настройки своего приложения впишу, естественно только те URL которыми владею и обслуживаю. И речь не про разные страницы на 1 сайте типа site.com/authorize_url1 и site.com/authorize_url2 ( которые могут быть leaky), а именно про разные сайты — site1.com/authorize_url и another-service-site.com/authorize_uri
Stackoverflow как пример был приведен не просто так, там не поддомены, а абсолютно независимые домены. Хотя не удивлюсь если они там сами реализовали Single SignOn — там рукастые девелоперы.
Да и с точки зрения программирования — это костыли и ненужная работа. Делать надо только то, что запрашивается и только тогда, когда запрашивается.
Ну и последний гвоздик — представьте у вас 100к пользователей, обновление раз в день (даже не в час) по крону, но реально активных осталось 10. Ради этих 10 вы будете гонять несколько мегабайт запросов (100к строк в json даже если убрать ненужный token — при длине токена в 64 символа — дает 6,4Мб на запрос). Ну или будете придумывать всякую хрено-эвристику — этих обновляем, этих не обновляем, потому что столько раз не заходили.
Поверьте, индукодеры не будут этим заниматься и будут слать все токены всех пользователей каждый час. Потому что «стандарт позволяет» создавать такую нагрузку. А сервер, как дебил, имплементировавший такой стандарт, будет с этим бороться, тратя свои ресурсы.
Про multiple URL — ну да, при таком отношении к критике — пусть будет зашибись.
В чем проблема на сервере проверять redirect_uri не на совпадение с 1 строкой, а на совпадение с несколькими. Я в настройки своего приложения впишу, естественно только те URL которыми владею и обслуживаю. И речь не про разные страницы на 1 сайте типа site.com/authorize_url1 и site.com/authorize_url2 ( которые могут быть leaky), а именно про разные сайты — site1.com/authorize_url и another-service-site.com/authorize_uri
Stackoverflow как пример был приведен не просто так, там не поддомены, а абсолютно независимые домены. Хотя не удивлюсь если они там сами реализовали Single SignOn — там рукастые девелоперы.
1 ponyal vash point. da tut nado podumat chtoby mass refresh ne poshel vo zlo
2 kstati v OAuth2.a or Lets just fix it poste ya i predlagal ispolzyovat neskolko redirect_uri s exact_match. vposledstvii ya reshil chto 1 redirect_uri dlya prilozhenya OK. est' workarounds dlya site.com site.net obhodov. vprochim ya tozhe podumayu ob etoy funkcii — ne ochevidno dlya developera
stackoverflow krutoy site v plane oauth-brokera. smotrite, v chem problema
site.com/redirect1?code=123 redirects to anothersite/redirect1?code=123 esli oni oba imejut client_credentials? problem nikakih dlya poluchenia tokena uzhe s drugogo domena. workaround est' a znachet OK
sorry za mnoy gonitsa mi6, pishu translitov
2 kstati v OAuth2.a or Lets just fix it poste ya i predlagal ispolzyovat neskolko redirect_uri s exact_match. vposledstvii ya reshil chto 1 redirect_uri dlya prilozhenya OK. est' workarounds dlya site.com site.net obhodov. vprochim ya tozhe podumayu ob etoy funkcii — ne ochevidno dlya developera
stackoverflow krutoy site v plane oauth-brokera. smotrite, v chem problema
site.com/redirect1?code=123 redirects to anothersite/redirect1?code=123 esli oni oba imejut client_credentials? problem nikakih dlya poluchenia tokena uzhe s drugogo domena. workaround est' a znachet OK
sorry za mnoy gonitsa mi6, pishu translitov
1. А ну да, еще насчет json — там надо быть осторожнее т.к. например дефолтный форматтер в json на .NET не разбирает больше 2Мб текста. Datacontract — вообще 8кб на объект. Понятно что «проблемы негров», но есть реальный мир с реальными библиотеками и у них есть вполне внятные ограничения. ;) это JFYI
2. Ну да, девелоперы в одном экшене должны не только разрулить display=popup|page но и определить что надо сделать редирект. Зачем? ну посмотрите у реализаций от гугла или фб есть прекрасное и простое решение — несколько доверенных адресов. И в итоге redirect_uri проверяется на соответствие нескольким маскам. Кстати строгая фиксация uri тоже лишнее ограничение. State можно как в виде параметра передавать так и в виде части страницы, например mysite.com/Authorize/123456 или mysite.com/Authorize?state=123456. Оба варианта имеют право на жизнь (а первый еще и по логам искать проще ;) )
Я не понимаю немного всей логики — раз есть workaround — значит пусть остается косяк а все должны пользоваться этим workaround? Стандарт или даже протокол который навязывает использование workaround'ов-костылей — не имеет смысла.
Про mi6 зачетная отмаза ;)
2. Ну да, девелоперы в одном экшене должны не только разрулить display=popup|page но и определить что надо сделать редирект. Зачем? ну посмотрите у реализаций от гугла или фб есть прекрасное и простое решение — несколько доверенных адресов. И в итоге redirect_uri проверяется на соответствие нескольким маскам. Кстати строгая фиксация uri тоже лишнее ограничение. State можно как в виде параметра передавать так и в виде части страницы, например mysite.com/Authorize/123456 или mysite.com/Authorize?state=123456. Оба варианта имеют право на жизнь (а первый еще и по логам искать проще ;) )
Я не понимаю немного всей логики — раз есть workaround — значит пусть остается косяк а все должны пользоваться этим workaround? Стандарт или даже протокол который навязывает использование workaround'ов-костылей — не имеет смысла.
Про mi6 зачетная отмаза ;)
1. наслышан наслышан. однажды коллега писал парсер json под .net кажется. такого рода проблем и проблем с кодировками было масса.
я и не говорю что JSON надо делать везде обязательным. hyper media apis как говорит т-щ @steveklabnik
2. тут довольно принципиально
не по маске а четкое соответствие чтобы лики были невозможны и как следствие не требовалось бы требовать redirect_uri и вообще запоминать его в базе данных. Огромное упрощение как БД так и самого flow.
1 или несколько exact match redirect_uri — это уже не сильно большая разница. На данный момент я решил что 1ого как минимум достаточно. Это, как минимум, позволяет не создавать целую таблицу редирект ури и еще куча доп мишуры. А девелопер пусть со своим единственным redirect_uri делает что хочет — прячет в сессию, редиректит итд.
я и не говорю что JSON надо делать везде обязательным. hyper media apis как говорит т-щ @steveklabnik
2. тут довольно принципиально
не по маске а четкое соответствие чтобы лики были невозможны и как следствие не требовалось бы требовать redirect_uri и вообще запоминать его в базе данных. Огромное упрощение как БД так и самого flow.
1 или несколько exact match redirect_uri — это уже не сильно большая разница. На данный момент я решил что 1ого как минимум достаточно. Это, как минимум, позволяет не создавать целую таблицу редирект ури и еще куча доп мишуры. А девелопер пусть со своим единственным redirect_uri делает что хочет — прячет в сессию, редиректит итд.
обновил пост
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Безопасность OAuth2