понятно, а в случае если сетка падает\разделяется и восстанавливается — будет 2 Availability кластера да? А по восстановлению они как-то синхронизируются\обмениваются обновившимися данными или это за пределами функционала базы?
Вы не упомянули, но на офф сайте написано, что это все in-memory — т.е. выключили машинку — потеряли базу, правильно?
А как ноды общаются и синхронизируются между собой, ну например, у меня 3 VM, на каждом запущено по Apache Ignite — какие порты открывать, какой протокол, как и через что делается node discovery? Или это только для одного сервера ?
Если я добавляю ноду — насколько быстро она получит нужные данные в Replicated режиме? Будет ли она собирать c каждого инстанса по отдельному диапазону или просто с одной из реплик качнет все что нужно?
Я правильно понимаю что для запуска нужен только наггет пакет? т.е. там внутри и jar для базы и обертка на.нет чтобы его стартовать?
А вы тут сами себе отвечаете? self-contained token — хорошая оптимизация для good path. Т.е. можно токен при запросах валидировать и проверять без центральной синхронной базы. Это экономит поход за проверкой на каждый запрос пользователя = серьезно экономит ресурсы. Недостаток подхода — что отозвать такой токен тоже непросто. Можно не отзывать вообще и сделать небольшое окно жизни типа 10 минут. Понятно что в автоматическом режиме спама это не спасет, чем дальше уменьшаем окно — тем больше нагрузка за счет увеличения частоты перевыписывания токена. Ищем баланс и проглатываем риски.
Черный список — это та же проверка в базе, ну ее можно оптимизировать по памяти всякими свертками и временем жизни кэша (не имеет смысл держать записи отозваных токенов если текущее время уже после exp токена). Если он асинхронный — у вас та же проблема — спаммер может попасть на сервер с необновившимся списком, если синхронный = каждый отзыв токена вызывает волну обновлений и задержку работы валидного пользователя… И все равно на каждый запрос будете делать сверку с этим blacklist.
Так что эта модель не сильно в принципе отличается от модели хранения в базе — все равно на каждый запрос делаем валидацию + проверку = лишняя нагрузка.
Так что подбираем комфортное окно и проглатываем риски...
Добро пожаловать в распределенный мир — не все сервера видят одно и то же состояние. Просто если это все мелко и быстро — пользователь не замечает рассинхронизации, а если масштабно — инвалидация кэша это больно
Перечитал тред. "Не совсем так" относилось только к валидности access токена — его можно обновить если пользователь еще активный и у вашего сервиса есть возможность направить пользователя на переавторизацию. Такая авторизация второй раз уже может произойти без всяких consent окошек, т.е. втихую. Или рефреш токеном.
В остальном — все правильно, так и используется.
В период существования только стандарта oauth2 — фишка с offline и refresh_token — была на усмотрение каждого провайдера. C принятием OIDC — это теперь часть стандарта OIDC Core — это ответ на изначальный вопрос — "у всех так или только у гугла".
Про сервер-сервер — лишнее пояснение на самом деле потому что ни один из сценариев протокола не предусматривает полное отсутствие пользователя. Всегда есть пользователь с браузером\клиентом понимающим http, хотя бы в начале протокола, чтобы дать согласие или инициировать первый шаг — перейти по ссылке. Остальные вещи — это просто увлекся описанием...
Сервер-сервер сам по себе не случается, должен быть инициатор поведения — пользователь, который говорит — хочу пользоваться ВебсайтомХ (или приложением которое поможет мне с gmail), не хочу регистрироваться, хочу залогиниться с гуглом, но не хочу давать им свой пароль от гугла. Вот из-за этого конфликта в мозгу пользователя и были созданы протоколы — openId1.0, openId2.0 Oauth1.o Oauth2.0, Open Id connect. Первые три умерли, четвертый выжил но его пользовали не по делу — вместо задуманной авторизации делали аутентификацию пользователей (потому что аутентификацию никто адекватно не сделал). В итоге OIDC, который протокол аутентификации был сделан поверх протокола авторизации. И вроде как теперь покрывает обе А-ции.
Описанный у вас сервер сервер — да, второй раз не выдаст, ваше левое почтовое приложение при появлении пользователя скажет ему — не могу логиниться, давай меня заново авторизуй. Что пользователь сам по себе и рад сделать, ибо привык что периодически что-то может отвалиться.
На самом деле чтобы ответить на вопрос — "а зачем такой токен ?" надо понимать протоколы и модель злоумышленника. Т.е. сначала понимаете как можно с помощью современных атак сделать гадость от имени пользователя, если вдруг удастся заполучить его токен, а потом смотрите на протоколы и понимаете — вот такое ограничение в таком режиме — потому что иначе яваскрипт через xss может сделать такую вот каку и чтобы это не случилось — протокол не разрешает какую-то такую фичу...
PS простой момент — протокол не защищает от man in the middle ( это вам к Oauth1 c подписями), он просто снижает риск того что случайный МитМ получит меньше возможностей. Если МитМ постоянный — тут не важно какие токены — он вас поимеет в любом случае.
Это не совсем так — если случился случай 2 — все верно, пользователь обменял, злоумышленник в дураках. Если же злоумышленник адекватный — он обменяет пару сразу, получив монопольный доступ ( потому что у него будет и новый валидный рефреш и валидный аксесс токен). Пользователь же — в лучшем случае будет выкинут из системы (если система при обновлении токена инвалидирует старый аксес токен немедленно), в худшем же (если access_token — self contained и он не инвалидируется а просто истекает) — продолжит пользоваться пока аксесс токеном и спустя время жизни этого токена — будет разлогинен или сервис перестанет работать как надо…
На что 99% пользователей поругают криворуких разработчиков и залогинятся еще раз ( потому что мы привыкли что веб кривой, перезайти — хороший способ пофиксить проблему...). В итоге сервис выдаст новую пару аксесс и рефреша для того же самого девайса и забудет про это (или вообще если нет возможности верифицировать deviceId).
Только очень сложные и умные сервисы ( читай — много денег вложено в эти вопросы) — будут приставать к пользователю с табличками что вот кто-то логинился сюда из неизвестной локации, с валидным токеном (см пункт 1 — у злоумышленника валидная и обновляемая пара) и может вы нам подскажете — вы ли это были, а если нет — мы тот рефреш и аксесс заблокируем по вашему желанию...
Не то что бы я против refresh токенов, но надо понимать особенности их использования и связанные с этим риски...
Это не так, пользователь уже дал доступ к своим данным "навсегда", единственное что сервису надо делать когда истекает 1час жизни access_token — это организовать запрос по получению access token, — если пользователь залогинен в гугле, и пользователь уже дал свое согласие (consent) — выдача access_token происходит в серии редиректов автоматически. Единственное принципиальное требование — надо чтобы пользовательский браузер был онлайн. Т.е. токен можно обновить только при непосредственном активном участии браузера пользователя ( при этом — почти прозрачно для пользователя т.к. редиректы). В Implicit flow — абсолютно прозрачно через js.
Оффлайн доступ подразумевает что сервис может обновить access token самостоятельно, без вовлечения пользователя в процесс обмена. Что более рисковано потому что если refresh токен утекает — любой знающий токен сможет им воспользоваться для обновления — вся остальная информация о деталях flow и client id — публична.
Это все было очень "гибко" описано в стандарте OAuth2 вот тут 1.5 Refresh Token.
Issuing a refresh token is optional at the discretion of the authorization server.
Настолько гибко что каждый сервис имплементировал это как они сами хотят и был зоопарк мнений и походов (без единого стандарта, как в общем и в остальных вопросах, уж очень гибкий Oauth2 получился).
В итоге в OpenID Connect сказали — хватит разврата и "закопали стюардессу" — т.е. добавили более строгое описание в свой стандарт — 11. Offline Access
тут уже и четко прописано какой скоуп запрашивать, как сервер должен себя вести и все такое.
Оно конечно не то что бы сильно упростило весь разврат вокруг любимых AuthN & AuthZ, но по крайней мере определило — куда слать и какие есть ограничения по поведению...
https://tools.ietf.org/html/rfc6749#page-10
Спека с вами не согласна. скоупы там просто для того чтобы определить что можно с токеном звать а что нет, offline_access — это вообще чей то частный скоуп, в спеке ни слова про offline.
Вы случайно не путаете чью-то реализацию Oauth 2.0 (Facebook? ) с самим протоколом?
но там есть оговорки, все же абзац весь выглядит так :
The authorization server MAY issue a new refresh token, in which case
the client MUST discard the old refresh token and replace it with the
new refresh token. The authorization server MAY revoke the old
refresh token after issuing a new refresh token to the client. If a
new refresh token is issued, the refresh token scope MUST be
identical to that of the refresh token included by the client in the
request.
А вообще протокол часто используется не по делу =) для аутентификации, а не авторизации (хотя на фоне всех остальных протоколов аутентификации — он прост и понятен...)
Вообще есть куда более простое объяснение — момент аутентификации\авторизации — более уязвим для атакующего чем момент доступа к ресурсам..
Т.е. если Ева перехватила оба токена — то тут все довольно плохо — в зависимости от реализации — она может выдавить легального пользователя Алису. Но такой перехват — сложнее потому что нужно угадать момент.
Перехват же access Token — проще — любой запрос и токен в заголовке. Просто и ценность такого токена низкая -его хватит только до конца его времени жизни, а потом он превращается в тыкву. Если сервис например делает время жизни токена в 15 минут — то Ева сможет почитать данные только 15 минут, потом всё.
Речь конечно не идет о постоянном MitM на Алису — там никакие схемы и токены не помогут...
Да уж, "хорошая шпаргалка"… Эту шпаргалку писали люди которые с ажуром знакомы только по маркетинговой документации .
Вот прям по пунктам с самого начала — одни косяки
Service Fabric — аналогов особо нету, ближайший это наверное Akka.net и WebJobs от того же ажура, зверек уникальный, и уж точно не Lambda и API Gateway, Azure Functions — это вот есть AWS Lambda
WebApps — только хероку туда попадает
Cloud Services — Это beanstalk, а совсем не EC2, менеджмента машин там нету, все настроено за нас, все развертывание — в портале зип файл с xml загрузил и только смотришь как оно разворачивается...
А вот уже IaaS\ AzureVM — это всеми любимые EC2
TableStorage — чистый noSQL, никакого между там нету, Key-Value Storage
Мс ориентируется на рынок и на своих больших ынтерпрайз партнеров, а там мало кто на десктопе сидит на линуксе. А сервера — SQL Server первая ласточка, Service Fabric, да и много всего потянется. В общем не все так категорично и однозначно. А еще полезно иногда выглянуть из echo-chamber и посмотреть на то, что реально происходит, и куда МС движется, а не критиковать с позиций фактов 5летней давности.
И да, такой хинт — многие в МС говорят, что публично компания релизит только то, что внутри обкатывали по несколько лет, теперь давайте пофантазируем о том, что публичный МС — это то что там внутри было три года назад, а то что мы увидим через 3 года — строят сегодня. Так что будущие они — могут быть оочень очень интересными. И главное — не судить на основе фактов о старом МС. МС Балмера и МС Сатьи — 2 разных компании
ну почему же виндофилы. Безаппеляционное утверждение что поддержки линукс от МС "конечно же" нет — .NET Core, VSCode, Azure Storage Explorer и другие тулы от МС которые кроссплатформенные и на электроне — конечно же поддерживают этот аргумент.
Остальные претензии что это не уровень слака без банальной скидки на возраст продукта выглядят больше как оскорбления, т.е. вы хотите чтобы все продукты выходили и тут же убивали своей крутизной крупнейших конкурентов на рынке? Так только в сказке бывает..
Что слак мог бы позаимствовать так это например приложения в табах — можно делать кастомный набор интеграций и под себя создавать персонализированную площадку для работы (более доступный пример такого подхода — meetfranz.com — центр персональных коммуникаций), а не делать как слак — принуждать интеграции любить пользователя только "рекомендованным способом".
Интересно, у нас 2 два новых — живут спокойно > 20 дней и ставим заряжаться — там еще ~5-7%
Серцебиение у всех рандомно, сравнивал Band2 FitbitHR и оба Хонгми, который 1s с белыми диодами и который новый — все показывают рандом, а еще если рядом сидит медик и меряет на второй руке пульс — такая хрень у всех выходит. Но к чести ближе всех к истине был новый Хонгми.
Шаги врут но немного, у нас на диапазоне 5к-7к на обоих расхождение было в 200 шагов, так что приемлемая погрешность (а главное стабильная — один и тот же всегда меньше показывает чем второй).
Я зажигание отключил — ночью этот фонарь в глаза бьет если включаешь случайно — может поэтому дольше батарея живет ??
http://www.yegor256.com/books.html
понятно, а в случае если сетка падает\разделяется и восстанавливается — будет 2 Availability кластера да? А по восстановлению они как-то синхронизируются\обмениваются обновившимися данными или это за пределами функционала базы?
Комменты не обновлялись. Вопросы 1 и 4 не актуальны.
Есть несколько вопросов —
А вы тут сами себе отвечаете? self-contained token — хорошая оптимизация для good path. Т.е. можно токен при запросах валидировать и проверять без центральной синхронной базы. Это экономит поход за проверкой на каждый запрос пользователя = серьезно экономит ресурсы. Недостаток подхода — что отозвать такой токен тоже непросто. Можно не отзывать вообще и сделать небольшое окно жизни типа 10 минут. Понятно что в автоматическом режиме спама это не спасет, чем дальше уменьшаем окно — тем больше нагрузка за счет увеличения частоты перевыписывания токена. Ищем баланс и проглатываем риски.
Черный список — это та же проверка в базе, ну ее можно оптимизировать по памяти всякими свертками и временем жизни кэша (не имеет смысл держать записи отозваных токенов если текущее время уже после exp токена). Если он асинхронный — у вас та же проблема — спаммер может попасть на сервер с необновившимся списком, если синхронный = каждый отзыв токена вызывает волну обновлений и задержку работы валидного пользователя… И все равно на каждый запрос будете делать сверку с этим blacklist.
Так что эта модель не сильно в принципе отличается от модели хранения в базе — все равно на каждый запрос делаем валидацию + проверку = лишняя нагрузка.
Так что подбираем комфортное окно и проглатываем риски...
Добро пожаловать в распределенный мир — не все сервера видят одно и то же состояние. Просто если это все мелко и быстро — пользователь не замечает рассинхронизации, а если масштабно — инвалидация кэша это больно
Перечитал тред. "Не совсем так" относилось только к валидности access токена — его можно обновить если пользователь еще активный и у вашего сервиса есть возможность направить пользователя на переавторизацию. Такая авторизация второй раз уже может произойти без всяких consent окошек, т.е. втихую. Или рефреш токеном.
В остальном — все правильно, так и используется.
В период существования только стандарта oauth2 — фишка с offline и refresh_token — была на усмотрение каждого провайдера. C принятием OIDC — это теперь часть стандарта OIDC Core — это ответ на изначальный вопрос — "у всех так или только у гугла".
Про сервер-сервер — лишнее пояснение на самом деле потому что ни один из сценариев протокола не предусматривает полное отсутствие пользователя. Всегда есть пользователь с браузером\клиентом понимающим http, хотя бы в начале протокола, чтобы дать согласие или инициировать первый шаг — перейти по ссылке. Остальные вещи — это просто увлекся описанием...
Сервер-сервер сам по себе не случается, должен быть инициатор поведения — пользователь, который говорит — хочу пользоваться ВебсайтомХ (или приложением которое поможет мне с gmail), не хочу регистрироваться, хочу залогиниться с гуглом, но не хочу давать им свой пароль от гугла. Вот из-за этого конфликта в мозгу пользователя и были созданы протоколы — openId1.0, openId2.0 Oauth1.o Oauth2.0, Open Id connect. Первые три умерли, четвертый выжил но его пользовали не по делу — вместо задуманной авторизации делали аутентификацию пользователей (потому что аутентификацию никто адекватно не сделал). В итоге OIDC, который протокол аутентификации был сделан поверх протокола авторизации. И вроде как теперь покрывает обе А-ции.
Описанный у вас сервер сервер — да, второй раз не выдаст, ваше левое почтовое приложение при появлении пользователя скажет ему — не могу логиниться, давай меня заново авторизуй. Что пользователь сам по себе и рад сделать, ибо привык что периодически что-то может отвалиться.
На самом деле чтобы ответить на вопрос — "а зачем такой токен ?" надо понимать протоколы и модель злоумышленника. Т.е. сначала понимаете как можно с помощью современных атак сделать гадость от имени пользователя, если вдруг удастся заполучить его токен, а потом смотрите на протоколы и понимаете — вот такое ограничение в таком режиме — потому что иначе яваскрипт через xss может сделать такую вот каку и чтобы это не случилось — протокол не разрешает какую-то такую фичу...
PS простой момент — протокол не защищает от man in the middle ( это вам к Oauth1 c подписями), он просто снижает риск того что случайный МитМ получит меньше возможностей. Если МитМ постоянный — тут не важно какие токены — он вас поимеет в любом случае.
Это не совсем так — если случился случай 2 — все верно, пользователь обменял, злоумышленник в дураках. Если же злоумышленник адекватный — он обменяет пару сразу, получив монопольный доступ ( потому что у него будет и новый валидный рефреш и валидный аксесс токен). Пользователь же — в лучшем случае будет выкинут из системы (если система при обновлении токена инвалидирует старый аксес токен немедленно), в худшем же (если access_token — self contained и он не инвалидируется а просто истекает) — продолжит пользоваться пока аксесс токеном и спустя время жизни этого токена — будет разлогинен или сервис перестанет работать как надо…
На что 99% пользователей поругают криворуких разработчиков и залогинятся еще раз ( потому что мы привыкли что веб кривой, перезайти — хороший способ пофиксить проблему...). В итоге сервис выдаст новую пару аксесс и рефреша для того же самого девайса и забудет про это (или вообще если нет возможности верифицировать deviceId).
Только очень сложные и умные сервисы ( читай — много денег вложено в эти вопросы) — будут приставать к пользователю с табличками что вот кто-то логинился сюда из неизвестной локации, с валидным токеном (см пункт 1 — у злоумышленника валидная и обновляемая пара) и может вы нам подскажете — вы ли это были, а если нет — мы тот рефреш и аксесс заблокируем по вашему желанию...
Не то что бы я против refresh токенов, но надо понимать особенности их использования и связанные с этим риски...
Это не так, пользователь уже дал доступ к своим данным "навсегда", единственное что сервису надо делать когда истекает 1час жизни access_token — это организовать запрос по получению access token, — если пользователь залогинен в гугле, и пользователь уже дал свое согласие (consent) — выдача access_token происходит в серии редиректов автоматически. Единственное принципиальное требование — надо чтобы пользовательский браузер был онлайн. Т.е. токен можно обновить только при непосредственном активном участии браузера пользователя ( при этом — почти прозрачно для пользователя т.к. редиректы). В Implicit flow — абсолютно прозрачно через js.
Оффлайн доступ подразумевает что сервис может обновить access token самостоятельно, без вовлечения пользователя в процесс обмена. Что более рисковано потому что если refresh токен утекает — любой знающий токен сможет им воспользоваться для обновления — вся остальная информация о деталях flow и client id — публична.
Это все было очень "гибко" описано в стандарте OAuth2 вот тут 1.5 Refresh Token.
Настолько гибко что каждый сервис имплементировал это как они сами хотят и был зоопарк мнений и походов (без единого стандарта, как в общем и в остальных вопросах, уж очень гибкий Oauth2 получился).
В итоге в OpenID Connect сказали — хватит разврата и "закопали стюардессу" — т.е. добавили более строгое описание в свой стандарт — 11. Offline Access
тут уже и четко прописано какой скоуп запрашивать, как сервер должен себя вести и все такое.
Оно конечно не то что бы сильно упростило весь разврат вокруг любимых AuthN & AuthZ, но по крайней мере определило — куда слать и какие есть ограничения по поведению...
топик про Oauth 2.0 не про OpenId Connect
https://tools.ietf.org/html/rfc6749#page-10
Спека с вами не согласна. скоупы там просто для того чтобы определить что можно с токеном звать а что нет, offline_access — это вообще чей то частный скоуп, в спеке ни слова про offline.
Вы случайно не путаете чью-то реализацию Oauth 2.0 (Facebook? ) с самим протоколом?
но там есть оговорки, все же абзац весь выглядит так :
А вообще протокол часто используется не по делу =) для аутентификации, а не авторизации (хотя на фоне всех остальных протоколов аутентификации — он прост и понятен...)
Вообще есть куда более простое объяснение — момент аутентификации\авторизации — более уязвим для атакующего чем момент доступа к ресурсам..
Т.е. если Ева перехватила оба токена — то тут все довольно плохо — в зависимости от реализации — она может выдавить легального пользователя Алису. Но такой перехват — сложнее потому что нужно угадать момент.
Перехват же access Token — проще — любой запрос и токен в заголовке. Просто и ценность такого токена низкая -его хватит только до конца его времени жизни, а потом он превращается в тыкву. Если сервис например делает время жизни токена в 15 минут — то Ева сможет почитать данные только 15 минут, потом всё.
Речь конечно не идет о постоянном MitM на Алису — там никакие схемы и токены не помогут...
Да уж, "хорошая шпаргалка"… Эту шпаргалку писали люди которые с ажуром знакомы только по маркетинговой документации .
Вот прям по пунктам с самого начала — одни косяки
Service Fabric — аналогов особо нету, ближайший это наверное Akka.net и WebJobs от того же ажура, зверек уникальный, и уж точно не Lambda и API Gateway, Azure Functions — это вот есть AWS Lambda
WebApps — только хероку туда попадает
Cloud Services — Это beanstalk, а совсем не EC2, менеджмента машин там нету, все настроено за нас, все развертывание — в портале зип файл с xml загрузил и только смотришь как оно разворачивается...
А вот уже IaaS\ AzureVM — это всеми любимые EC2
TableStorage — чистый noSQL, никакого между там нету, Key-Value Storage
Ну и так далее…
Мс ориентируется на рынок и на своих больших ынтерпрайз партнеров, а там мало кто на десктопе сидит на линуксе. А сервера — SQL Server первая ласточка, Service Fabric, да и много всего потянется. В общем не все так категорично и однозначно. А еще полезно иногда выглянуть из echo-chamber и посмотреть на то, что реально происходит, и куда МС движется, а не критиковать с позиций фактов 5летней давности.
И да, такой хинт — многие в МС говорят, что публично компания релизит только то, что внутри обкатывали по несколько лет, теперь давайте пофантазируем о том, что публичный МС — это то что там внутри было три года назад, а то что мы увидим через 3 года — строят сегодня. Так что будущие они — могут быть оочень очень интересными. И главное — не судить на основе фактов о старом МС. МС Балмера и МС Сатьи — 2 разных компании
Самое понятное объяснение что такое .NET Standard я видел у David Fowler вот тут
на электроне? Странные у вас цифры, у мня всего 6 команд залогинено и все эта коммуникационная тттелега тормозит хуже visual studio 2010...
ну почему же виндофилы. Безаппеляционное утверждение что поддержки линукс от МС "конечно же" нет — .NET Core, VSCode, Azure Storage Explorer и другие тулы от МС которые кроссплатформенные и на электроне — конечно же поддерживают этот аргумент.
Остальные претензии что это не уровень слака без банальной скидки на возраст продукта выглядят больше как оскорбления, т.е. вы хотите чтобы все продукты выходили и тут же убивали своей крутизной крупнейших конкурентов на рынке? Так только в сказке бывает..
Что слак мог бы позаимствовать так это например приложения в табах — можно делать кастомный набор интеграций и под себя создавать персонализированную площадку для работы (более доступный пример такого подхода — meetfranz.com — центр персональных коммуникаций), а не делать как слак — принуждать интеграции любить пользователя только "рекомендованным способом".
Серцебиение у всех рандомно, сравнивал Band2 FitbitHR и оба Хонгми, который 1s с белыми диодами и который новый — все показывают рандом, а еще если рядом сидит медик и меряет на второй руке пульс — такая хрень у всех выходит. Но к чести ближе всех к истине был новый Хонгми.
Шаги врут но немного, у нас на диапазоне 5к-7к на обоих расхождение было в 200 шагов, так что приемлемая погрешность (а главное стабильная — один и тот же всегда меньше показывает чем второй).
Я зажигание отключил — ночью этот фонарь в глаза бьет если включаешь случайно — может поэтому дольше батарея живет ??