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.
>И да, в вашем упрощении вы потеряли одну сторону — у вас провайдер ресурсов и сервер авторизации — один юнит.
это пока. потом выпилю авторизацию в gem railsengine и это будут отдельные вещи
>Да и mass refresh — имхо сомнительная фича. Вы хотите чтобы клиент мог одним запросом к серверу обновить over9000 токенов? Ну я так заддосю сервер — отправляя все токены каждую секунду на рефреш я буду порождать избыточное потребление ресурсов — серверу все токены надо перевыписать, а если для выписывания используется не рэндом а крипта какая-нить — будет еще печальней.
Не лучше ли делать lazy-refresh — т.е. реально когда понадобится обратиться к апи а токен протух — сделать быстрое обновление 1 токена…
именно, чтобы одним запросом обновил кучу токенов. какой дос Оо. все это легко пресекается. Мас рефреш не обязателен, можно отсылать и по одному токену, только это неудобно не для провайдера не для клиента. Куда лучше по крону раз в час обновлять нужные вещи. подумайте еще раз, фича отличная
>Выходит, я при всем желании не могу авторизовать через такого провайдера несколько своих сайтов, если они предоставляют разный функционал на разных URL. И такая полезная штука как Single SignOn ( залогинился в одном сайте компании = залогинен везде, например StackOverflow Network) должна быть реализована вручную, а не через implicit авторизацию. Плохая идея.
зашибись идея. читайте threat model внимательно. Это все как для секюрити так и для удобства. Если вам принадлежит 1 redirect_uri то вы с помощью ловкости рук и никакого мошенничества запишите код в сессию и перекинете пользователя на подсайт. Implicit вообще должен использоваться когда нет бекенда. Например мобильные приложения или чисто js сайт.
никаких неудобств это не создает, зато предотвращает массу атак которые я изучал
не спорное. как раз эти моменты давно утверждены в OAuth2 и им нет замены. Объяснять долго но суть в том что хеш не идет на сервер что предотвращает лики
в том то и дело что стандарт 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 это как пример. в стандарте ему делать нечего
реплэй аттака производится уже Mallory — т.е. хакером. У меня есть код другого фб, я его подставляю в свой колбэк, стэйт тоже свой. Но вхожу уже в ваш аккаунт
I dropped from school when I was a teenager and years later rejoined and ended up completing a degree in math. I have been a math teacher in summers in high school, and Perl teacher at the university for seven years in my spare time.
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.
это пока. потом выпилю авторизацию в gem railsengine и это будут отдельные вещи
>Да и mass refresh — имхо сомнительная фича. Вы хотите чтобы клиент мог одним запросом к серверу обновить over9000 токенов? Ну я так заддосю сервер — отправляя все токены каждую секунду на рефреш я буду порождать избыточное потребление ресурсов — серверу все токены надо перевыписать, а если для выписывания используется не рэндом а крипта какая-нить — будет еще печальней.
Не лучше ли делать lazy-refresh — т.е. реально когда понадобится обратиться к апи а токен протух — сделать быстрое обновление 1 токена…
именно, чтобы одним запросом обновил кучу токенов. какой дос Оо. все это легко пресекается. Мас рефреш не обязателен, можно отсылать и по одному токену, только это неудобно не для провайдера не для клиента. Куда лучше по крону раз в час обновлять нужные вещи. подумайте еще раз, фича отличная
>Выходит, я при всем желании не могу авторизовать через такого провайдера несколько своих сайтов, если они предоставляют разный функционал на разных URL. И такая полезная штука как Single SignOn ( залогинился в одном сайте компании = залогинен везде, например StackOverflow Network) должна быть реализована вручную, а не через implicit авторизацию. Плохая идея.
зашибись идея. читайте threat model внимательно. Это все как для секюрити так и для удобства. Если вам принадлежит 1 redirect_uri то вы с помощью ловкости рук и никакого мошенничества запишите код в сессию и перекинете пользователя на подсайт. Implicit вообще должен использоваться когда нет бекенда. Например мобильные приложения или чисто js сайт.
никаких неудобств это не создает, зато предотвращает массу атак которые я изучал
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 это как пример. в стандарте ему делать нечего
на колбэк переходит браузер пользователя. фильтровать айпи тут клиенту нет смысла
уважение, профессор Xavier