Comments 49
UFO just landed and posted this here
UFO just landed and posted this here
Используйте Oauth 2.0 и не мучайтесь. В большинстве случаев вам необходимо осуществить авторизацию пользователя из внешних систем, а точнее социальные сети и иже с ними. И со стороны клиента там все хорошо.
Немного поясню в чем же автор считает Oauth 2.0 хуже. Во первых в стандарте не определен такой момент как алгоритм генерации уникальных кодов как со стороны сервера, так со стороны клиента (в oauth 1.0 был определен). Во вторых использование TLS как достаточной меры безопасности.
Теперь опять же вот про эту цитату:
Мне сильно хочется посмотреть на этих вебразработчиков. OAuth 2.0 проще в использовании.
Чего же реально не хватает, это стандартизации получения информации о пользователе и передачи информации о том какую информацию запрашивает приложение. В результате авторизацию получить одинаково изменяя только префикс и ключи можно, а вот информацию нет и надо городить отдельную реализацию чтения профиля пользователя, на каждый источник данных.
Немного поясню в чем же автор считает Oauth 2.0 хуже. Во первых в стандарте не определен такой момент как алгоритм генерации уникальных кодов как со стороны сервера, так со стороны клиента (в oauth 1.0 был определен). Во вторых использование TLS как достаточной меры безопасности.
Теперь опять же вот про эту цитату:
В то время как веб-разработчики хотели улучшенную версию OAuth 1.0 с исправлениями в необходимых областях, представители корпоративного мира хотели получить фреймворк, который они могли бы без проблем встроить в свои существующие корпоративные системы.
Мне сильно хочется посмотреть на этих вебразработчиков. OAuth 2.0 проще в использовании.
Чего же реально не хватает, это стандартизации получения информации о пользователе и передачи информации о том какую информацию запрашивает приложение. В результате авторизацию получить одинаково изменяя только префикс и ключи можно, а вот информацию нет и надо городить отдельную реализацию чтения профиля пользователя, на каждый источник данных.
Я только удивился — а 1.0 вообще ещё кто-то использует? И вокруг 2.0 бегает некий OpenId Connect
Twitter.
У них тоже Oauth 2.0 во все поля есть.
Месяц назад интегрировались с твиттером и разработчик, который этим занимался сказал что там нет и не планируется OAuth 2, я чего-то не знаю?
dev.twitter.com/discussions/397
Все правильно, пока только OAuth1
Все правильно, пока только OAuth1
В этой же теме есть ссылка на Oauth2 кстати.
Ну им видимо за державу обидно. С моей точки зрения Oauth 2.0 весьма удачен. Он ПРОСТОЙ и ПОНЯТНЫЙ. В отличии от того же OpenID и Oauth 1.0
Ну мы вроде с тобой это и обсуждали :) А OpenId Connect хорошая тема на первый взгляд во всяком случае.
Э… OAuth 2.0 это фреймворк. Он как вы написали «простой и понятный» потому, что действительно сложные и важные вещи он попросту не определяет. Их из спецификации просто напросто повыбрасывали. Или, как они политкорректно пишут «оставили на усмотрение разработчика».
То есть любой корпоратив может сделать реализацию со своей собственной системой генерации и верификации токенов, не совместимой ни с кем. С одной стороны как бы всё нормально. Но с другой стороны тогда не понятно, зачем тогда вообще нужна стандартизация. MS, например, в осликах долгое время лепил свои стандарты на html и css, не взирая ни на что. Теперь MS пихает свой «фреймворк» ОО-XML в качестве утвержденного «открытого» стандарта обмена документами. И все разводят руками, стандарт, типа открытый, только кроме никто ничего там по нормальному сделать не сможет без самого MS'а. Ну, клёво…
В данном случае, я более чем понимаю Эрана. Заниматься мартышкиным трудом для корпоративов, которые в конечном счете устроят из OAuth 2.0 свалку в пылу конкурентной борьбы, нормальному человеку, который без проблем найдет себе интересную работу, не нужно…
То есть любой корпоратив может сделать реализацию со своей собственной системой генерации и верификации токенов, не совместимой ни с кем. С одной стороны как бы всё нормально. Но с другой стороны тогда не понятно, зачем тогда вообще нужна стандартизация. MS, например, в осликах долгое время лепил свои стандарты на html и css, не взирая ни на что. Теперь MS пихает свой «фреймворк» ОО-XML в качестве утвержденного «открытого» стандарта обмена документами. И все разводят руками, стандарт, типа открытый, только кроме никто ничего там по нормальному сделать не сможет без самого MS'а. Ну, клёво…
В данном случае, я более чем понимаю Эрана. Заниматься мартышкиным трудом для корпоративов, которые в конечном счете устроят из OAuth 2.0 свалку в пылу конкурентной борьбы, нормальному человеку, который без проблем найдет себе интересную работу, не нужно…
То есть любой корпоратив может сделать реализацию со своей собственной системой генерации и верификации токенов, не совместимой ни с кем.
В draft механизм подключения описан довольно четко и не привязан к тому как токены генерируются. Про какую верификацию речь идет? В какой момент? Текущая версия oauth никак эти токены не верифицирует.
UFO just landed and posted this here
Прескорбно что уже сейчас все соцсети не соответствуют текущей спецификации OAuth 2. Даже Facebook не всегда возвращает то что описано в протоколе.
UFO just landed and posted this here
Меня некоторое время назад, кстати, удивило весьма вольное трактование спецификации некоторыми, весьма крупными веб-сервисами.
В конце своей блогозаписи Эран Хаммер пишет
Думал — Мицгол, оказалось — ализар...
По теме: похоже, что крупные вещи (типа стандартов и мегакорпораций) могут удержать на плаву и в адекватном состоянии только диктаторские методы управления. Хорошие примеры — Торвальдс и Гейтс.
просто вброс без конструктива. oauth2 куда проще и удобней а по безопасности не уступает кроме пары моментов которые еще можно исправить.
о, наконец-то подоспели специалисты, которые в любом протоколе и стандарте разбираются лучше, чем авторы протокола и стандарта.
А вы оригинал замечаний читали? Ну так просто, любопытно.
А делали хоть что-то через Oauth1 и Oauth2, руками а не через чужие либы. Ну мне просто любопытно на тему «А судьи кто».
Кстати советую почитать прекрасный ответ на тот вброс
On the Deadness of OAuth 2
Да, печально видеть что главный редактор стандарта так хлопнул дверью. Да, Oauth2 страдает от некоторого отсутствия четких и недвусмысленных указаний — что и как должно быть. Да, в том числе есть расхождения в реализации, потому что разные сервисы реализовывали разные драфты неготового стандарта.
Но поверьте мне — поработав руками с Oauth1 и Oauth2, я выберу только Oauth2. А все что не описано в стандарте — формализую самостоятельно, с учетом моих знаний по ИБ.
По сути стандарту немного не хватает приказного тона при описании — типа «урл должен быть вот такого вида», или «сервис должен отвечать метаданными в формате json на well-known endpoint» или хотя бы давать рекомендации по выбору тех или иных ограничений — а-ля желательно поддерживать токен не короче 32-64-128 символов, он там должен соответствовать надежным практикам безопасности, установленным на момент реализации вашего приложения.
А делали хоть что-то через Oauth1 и Oauth2, руками а не через чужие либы. Ну мне просто любопытно на тему «А судьи кто».
Кстати советую почитать прекрасный ответ на тот вброс
On the Deadness of OAuth 2
Да, печально видеть что главный редактор стандарта так хлопнул дверью. Да, Oauth2 страдает от некоторого отсутствия четких и недвусмысленных указаний — что и как должно быть. Да, в том числе есть расхождения в реализации, потому что разные сервисы реализовывали разные драфты неготового стандарта.
Но поверьте мне — поработав руками с Oauth1 и Oauth2, я выберу только Oauth2. А все что не описано в стандарте — формализую самостоятельно, с учетом моих знаний по ИБ.
По сути стандарту немного не хватает приказного тона при описании — типа «урл должен быть вот такого вида», или «сервис должен отвечать метаданными в формате json на well-known endpoint» или хотя бы давать рекомендации по выбору тех или иных ограничений — а-ля желательно поддерживать токен не короче 32-64-128 символов, он там должен соответствовать надежным практикам безопасности, установленным на момент реализации вашего приложения.
вот именно. oauth2 тупо удобнее и проще. осталось решить моменты связанные с безопасностью(стать строже а не просто SHOULD) ну и побольше стандартных урлов для interoperability
> Ну мне просто любопытно на тему «А судьи кто».
этот тип аргумента в интернете называют обычно «сперва добейся». я на него тоже отвечу, но мне кажется, что можно было бы проявить чуть больше уважения к нескольким годам работы человека над стандартом. ну то есть не писать глупую строчку «просто вброс без конструктива. oauth2 куда проще и удобней а по безопасности не уступает кроме пары моментов», а на минутку представить, что позиция хаммера обдумана, вызвана какими-то причинами, будет иметь какие-то последствия, которые хаммер тоже обдумал. то есть мне кажется, что допущение, что хаммер — разумен, это нормальное допущение и любой разумный человек должен из этого допущения исходить.
а этот однострочный комментарий исходит из допущения «я умный хаммер дурак»
> А вы оригинал замечаний читали? Ну так просто, любопытно.
нет
> А делали хоть что-то через Oauth1 и Oauth2, руками а не через чужие либы.
да
> Кстати советую почитать прекрасный ответ на тот вброс
читал
этот тип аргумента в интернете называют обычно «сперва добейся». я на него тоже отвечу, но мне кажется, что можно было бы проявить чуть больше уважения к нескольким годам работы человека над стандартом. ну то есть не писать глупую строчку «просто вброс без конструктива. oauth2 куда проще и удобней а по безопасности не уступает кроме пары моментов», а на минутку представить, что позиция хаммера обдумана, вызвана какими-то причинами, будет иметь какие-то последствия, которые хаммер тоже обдумал. то есть мне кажется, что допущение, что хаммер — разумен, это нормальное допущение и любой разумный человек должен из этого допущения исходить.
а этот однострочный комментарий исходит из допущения «я умный хаммер дурак»
> А вы оригинал замечаний читали? Ну так просто, любопытно.
нет
> А делали хоть что-то через Oauth1 и Oauth2, руками а не через чужие либы.
да
> Кстати советую почитать прекрасный ответ на тот вброс
читал
это у вас аргументы «сперва добейся». чтобы критиковать пианиста надо хорошо уметь играть? чтобы критиковать высер одного из авторов стандарта надо быть автором стандарта? я читал обе спецификации и реализовывал. несмотря на некоторые слабости oauth2 их еще можно исправить. а неудобный oauth1 осталось только сжечь.
Давайте, Егор, предположим, что вы целиком правы. тогда новый стандарт почти во всём хороший, а старый стандарт очень плохой, так? но Хаммер говорит обратное. Следует ли из этого, с вашей точки зрения, что Хаммер — дурак? (мне кажется, что если вы правы, то это должно следовать)
Не передергивайте. Кстати вы зря не читали оригинал — Хаммер там говорит «не так».
В новом стандарте есть нечетко прописанные места и в случае секурити он полагается на TLS, а не как O1 на подписывание запросов. Но один этот ход делает работу с протоколом просто на порядок легче.
Хаммер недоволен тем, что все противостоят добавлению конкретики что вот так надо делать, вот так надо называть и пр. С другой стороны я понимаю что у каждого есть свое видение как надо расширить протокол и все хотят оставить пространство для маневра в пределах спецификации.
Да, в итоге может получиться несовместимая реализация или будет невозможна (или очень сложна) общая реализация, но надо не ныть по поводу — «вот тащат все в Ынтерпрайз» а просто предлагать конкретные вещи (хотя думаю он предлагал) — явно не хватает autodiscovery и метаданных на провайдера, стоит зафиксировать имена эндпоинтов (token_auth и token_exchange), потребовать пару-тройку минимальных ограничений — на способы аутентификации клиента, на минимальную длину токена, на всякие времена жизни и т.д.
Ну и имхо — выкинуть нафик сценарий с login\password =) одно это приведет к #security-fail, что приложение будет хранить логин и пароль плэйн текстом…
В новом стандарте есть нечетко прописанные места и в случае секурити он полагается на TLS, а не как O1 на подписывание запросов. Но один этот ход делает работу с протоколом просто на порядок легче.
Хаммер недоволен тем, что все противостоят добавлению конкретики что вот так надо делать, вот так надо называть и пр. С другой стороны я понимаю что у каждого есть свое видение как надо расширить протокол и все хотят оставить пространство для маневра в пределах спецификации.
Да, в итоге может получиться несовместимая реализация или будет невозможна (или очень сложна) общая реализация, но надо не ныть по поводу — «вот тащат все в Ынтерпрайз» а просто предлагать конкретные вещи (хотя думаю он предлагал) — явно не хватает autodiscovery и метаданных на провайдера, стоит зафиксировать имена эндпоинтов (token_auth и token_exchange), потребовать пару-тройку минимальных ограничений — на способы аутентификации клиента, на минимальную длину токена, на всякие времена жизни и т.д.
Ну и имхо — выкинуть нафик сценарий с login\password =) одно это приведет к #security-fail, что приложение будет хранить логин и пароль плэйн текстом…
>Ну и имхо — выкинуть нафик сценарий с login\password =) одно это приведет к #security-fail, что приложение будет хранить логин и пароль плэйн текстом…
нельзя. самый прикол этой отенфикации что приложение НЕ хранит их. оно использует их только чтобы получить токен и рефреш токен. хранить НЕЛЬЗЯ. это сделали чтобы приложению не пришлось открывать браузер и вырезать акцес токен из хеша.
нельзя. самый прикол этой отенфикации что приложение НЕ хранит их. оно использует их только чтобы получить токен и рефреш токен. хранить НЕЛЬЗЯ. это сделали чтобы приложению не пришлось открывать браузер и вырезать акцес токен из хеша.
Мну грустно уже от того, что какое-то приложение захочет чтобы я ему вбил пароль от Gmail и понадеялся на то, что оно его передаст со всеми возможными адекватными мерами безопасности.
К тому же в этом сценарии refresh_token — optional. И как всегда дружелюбные индокодеры будут хранить, чтобы каждый раз при запуске пользователя не дергать.
К тому же в этом сценарии refresh_token — optional. И как всегда дружелюбные индокодеры будут хранить, чтобы каждый раз при запуске пользователя не дергать.
Пара моментов — про вброс — не ко мне ;).
Про судьи кто — дело не в том, чтобы сказать «сперва добейся», а в том, что вы так же прибежали и начали язвительно указывать на «специалистость» комментаторов. Хотя и не удосужились прочитать исходный материал, все равно считаете что он полон конструктивных аргументов и продуманных последствий. Я прочитал его еще в четверг twitter.com/centur/status/228449629472182272 (хабр тормозит =) )
Независимо от моего отношения к Хаммеру — я согласен с аргументами chikey, что стандарт — хороший. Не подробный, есть что улучшить или усилить, но куда лучше O1.
И да, про «Великий смысл поступка и продуманность последствий» — не всегда надо искать черную кошшу в темной комнате — ее может там и не быть.
Про судьи кто — дело не в том, чтобы сказать «сперва добейся», а в том, что вы так же прибежали и начали язвительно указывать на «специалистость» комментаторов. Хотя и не удосужились прочитать исходный материал, все равно считаете что он полон конструктивных аргументов и продуманных последствий. Я прочитал его еще в четверг twitter.com/centur/status/228449629472182272 (хабр тормозит =) )
Независимо от моего отношения к Хаммеру — я согласен с аргументами chikey, что стандарт — хороший. Не подробный, есть что улучшить или усилить, но куда лучше O1.
И да, про «Великий смысл поступка и продуманность последствий» — не всегда надо искать черную кошшу в темной комнате — ее может там и не быть.
> дело не в том, чтобы сказать «сперва добейся», а в том, что вы так же прибежали и начали язвительно указывать на «специалистость» комментаторов
О, похоже тролль детектед. Сначала начал язвить про специалистов, а когда последовал ответ в его же манере — сказал что сделал справедливо потому что «вы тоже начали». Хронологию ответов и кто откуда начал — сами проследите или потыкать?
Давайте обсуждать топик по делу, а не форсить унылые мемы. Есть что сказать по сути вопроса — говорите, нет — вернитесь пожалуйста на двачик или туда, где научились так «вести беседу».
Давайте обсуждать топик по делу, а не форсить унылые мемы. Есть что сказать по сути вопроса — говорите, нет — вернитесь пожалуйста на двачик или туда, где научились так «вести беседу».
Шикарный ответ… Цитирую: «Я тут типа чайник. Нифига не понимаю в криптографии (поликорректный вариант перевода, прим. переводчика), и обожаю PKI, путаю авторизацию и аутентификацию… Я сам Этана не знаю, но слышал о нем пару крепких выражений от людей которые знают...» И дальше еще полтора экрана подобного бреда. Прямо одесский анекдот какой-то… Хорошие у вас авторитеты…
Вы из без стандарта OAuth2 можете себе всё что угодно формализовать. Благо кроме вас это никому нафиг не нужно будет, потому как всё равно не будет ни с чем совместимо…
Вы из без стандарта OAuth2 можете себе всё что угодно формализовать. Благо кроме вас это никому нафиг не нужно будет, потому как всё равно не будет ни с чем совместимо…
Ок, замечания дальше первого абзаца прочитали?
То что вы называете бредом — вообще то аргументированные факты:
* Фреймворк используется, уже widely adopted, удобней чем 1.0.
* Ну да, есть Ынтерпрайз который обычно хочет странного — (ну так они обычно этого везде хотят), чтобы была возможность сделать ни с кем несовместимый плагин и продавать за деньги.
* Основное ядро фреймворка — выжило, вменяемо, можно юзать.
Всё. Ваши одесские анекдоты в переводе лучше исключить, а то вы уже «наперевели», что даже за комментарий такой неудобно.
Давайте чтобы не было неправильных трактовок, хотя бы начала ответа, я приведу первый абзац целиком, а то «обожаю PKI» и «PKI деревенщина»- немного разные переводы. Да и strong opinions — это не «крепкие выражения», это — «твердые мнения». Вы уверены что текст правильно поняли?
То что вы называете бредом — вообще то аргументированные факты:
* Фреймворк используется, уже widely adopted, удобней чем 1.0.
* Ну да, есть Ынтерпрайз который обычно хочет странного — (ну так они обычно этого везде хотят), чтобы была возможность сделать ни с кем несовместимый плагин и продавать за деньги.
* Основное ядро фреймворка — выжило, вменяемо, можно юзать.
Всё. Ваши одесские анекдоты в переводе лучше исключить, а то вы уже «наперевели», что даже за комментарий такой неудобно.
Давайте чтобы не было неправильных трактовок, хотя бы начала ответа, я приведу первый абзац целиком, а то «обожаю PKI» и «PKI деревенщина»- немного разные переводы. Да и strong opinions — это не «крепкие выражения», это — «твердые мнения». Вы уверены что текст правильно поняли?
Wow, did Eran Hammer ever go off. His noisy slamming of the OAuth 2 door behind him has become a news story. I have opinions too.
First of all, if you read his (long-ish) piece, you pretty much owe it to yourself to read the (very long) comments too.
Second: I’m kind of a n00b here. I’m a crypto cretin, a PKI peasant, an attribute-exchange airhead, and have been known to confuse authentication with authorization. Having said that:
* I’ve spent a lot of time, the last few months, getting to grips with real actual OAuth 2 software, and
* I’ve learned over the years that when you’re in the process of first using a new technology, that’s a good time to write about it.
Disclosure: I don’t know Eran. I’ve heard plenty of strong opinions about him from people who do. You can go out and find ’em on the Net if you think it’s material.
По поводу перевода: Начните с русского. Что такое «твёрдое мнение»? Есть еще «мягкое мнение»? Подберите нормальный русский эквивалент, тогда и сравним. Значение каждого слова по отдельности я знаю…
На счет peasant посыпаю голову пеплом… прочитал как pleasant…
Правильно ли я понял пусть рассудят хабравчане.
На счет самого письма: Сравните уровень аргументации вашего «деревенщины» и Этана. Например по этому тексту:
Ваш деревенщина всё сводит к тому, что у кого-то что-то работает, а всё остальное не нужно… При этом он не обламывается вставлять фразы типа: I haven’t tried those, but I doubt it works out of the box.
Избавьте меня от чтения мнения таких псевдоспецов…
На счет peasant посыпаю голову пеплом… прочитал как pleasant…
Правильно ли я понял пусть рассудят хабравчане.
На счет самого письма: Сравните уровень аргументации вашего «деревенщины» и Этана. Например по этому тексту:
Indecision Making
These changes are all manageable if put together in a well-defined protocol. But as has been the nature of this working group, no issue is too small to get stuck on or leave open for each implementation to decide. Here is a very short sample of the working group’s inability to agree:
No required token type
No agreement on the goals of an HMAC-enabled token type
No requirement to implement token expiration
No guidance on token string size, or any value for that matter
No strict requirement for registration
Loose client type definition
Lack of clear client security properties
No required grant types
No guidance on the suitability or applicability of grant types
No useful support for native applications (but lots of lip service)
No required client authentication method
No limits on extensions
On the other hand, 2.0 defines 4 new registries for extensions, along with additional extension points via URIs. The result is a flood of proposed extensions. But the real issues is that the working group could not define the real security properties of the protocol. This is clearly reflected in the security consideration section which is largely an exercise of hand waving. It is barely useful to security experts as a bullet point of things to pay attention to.
In fact, the working group has also produced a 70 pages document describing the 2.0 threat model which does attempt to provide additional information but suffers from the same fundamental problem: there isn’t an actual protocol to analyze.
Ваш деревенщина всё сводит к тому, что у кого-то что-то работает, а всё остальное не нужно… При этом он не обламывается вставлять фразы типа: I haven’t tried those, but I doubt it works out of the box.
Избавьте меня от чтения мнения таких псевдоспецов…
Не все устойчивые выражения имеют антонимы. Вы никогда не встречали высказывания типа «он человек твердых взглядов и убеждений»? Ну и тут тоже есть примеры использования далекие от дословного «крепкие выражения». Да и вообще — «Мой дядя самых честных правил» — вы же не спрашиваете про нечестность правил.
Далее — на тему тз от Эрана и «этого нуба». Они друг другу только противоречат в одном — в судьбе, рисуемой для OAuth2:
у Эрана это — «распространение трэшового протокола, увядание и забвение»
у Tim Bray (угу, он самый, тупой «нубас-крестьянин») — «Да все будет ок, каркас правильный, несмотря на загаженность Ынтерпрайзом, а уж нужные элементы нарастим»
А так — оба говорят об особенностях и в целом по делу — один о недостатках протокола и процедуры, другой о том, что несмотря на все недостатки — уже стало распространяться, так зачем же хлопать дверью.
Я не вижу смысла по пунктам разбирать оба текста, т.к. не вижу кардинальных противоречий. Оба мнения содержат аргументы — одно технические, другое — фактический уровень использования драфта.
А избавить вас… даже не знаю что сказать, если только — «избавляю, не читайте». Читайте Эрана, он же директор по стандартам в умирающей Yahoo, а не нуб-крестьянин.
PS: «Рассуждения» хабром можно особо не ждать, думаю в топике остались только мы с вами, ну еще мб chikey заглянет. А все остальные уже с интересом обсуждают другие новости…
Далее — на тему тз от Эрана и «этого нуба». Они друг другу только противоречат в одном — в судьбе, рисуемой для OAuth2:
у Эрана это — «распространение трэшового протокола, увядание и забвение»
у Tim Bray (угу, он самый, тупой «нубас-крестьянин») — «Да все будет ок, каркас правильный, несмотря на загаженность Ынтерпрайзом, а уж нужные элементы нарастим»
А так — оба говорят об особенностях и в целом по делу — один о недостатках протокола и процедуры, другой о том, что несмотря на все недостатки — уже стало распространяться, так зачем же хлопать дверью.
Я не вижу смысла по пунктам разбирать оба текста, т.к. не вижу кардинальных противоречий. Оба мнения содержат аргументы — одно технические, другое — фактический уровень использования драфта.
А избавить вас… даже не знаю что сказать, если только — «избавляю, не читайте». Читайте Эрана, он же директор по стандартам в умирающей Yahoo, а не нуб-крестьянин.
PS: «Рассуждения» хабром можно особо не ждать, думаю в топике остались только мы с вами, ну еще мб chikey заглянет. А все остальные уже с интересом обсуждают другие новости…
Да стандарт. То, что действительно надо было стандартизировать, чтобы системы системы facebook'а и Google стыковались из коробки, про что Брей пишет, стандартизировать не стали.
В итоге остался фреймворк, а ля RoR только узкоспециализированный. Зачем его стандартизировать, не понятно. Корпоративы собрались и в складчину разработали для себя продукт. Продукт не плохой. Но причем тут стандартизация?
В итоге остался фреймворк, а ля RoR только узкоспециализированный. Зачем его стандартизировать, не понятно. Корпоративы собрались и в складчину разработали для себя продукт. Продукт не плохой. Но причем тут стандартизация?
Стандартизированный фреймворк хорош тем, что все понимают какой должен быть flow операций, почему он такой, что можно а что нельзя делать и какие есть угрозы в модели безопасности.
Если вы считаете что стандарт это банальное описание того, как называть урлы и переменные, чтобы работало из коробки — мне кажется мы с вами сильно рсходимся в понимании стандарта.
Если вы считаете что стандарт это банальное описание того, как называть урлы и переменные, чтобы работало из коробки — мне кажется мы с вами сильно рсходимся в понимании стандарта.
Зачем мне понимать какой у вас flow операций, если для того, чтобы интегрироваться с вашим сервисом мне всё равно придется брать ваши инструменты, поскольку мои гарантированно будут не совместимы с вашими?
Вспомните в чем была проблема с OAuth 1.0 и почему было решено разрабатывать новый стандарт. OAuth 2.0 в конечном счете эту задачу не решил… Уход из комитета представителей от сообщества конкретный показатель, что в этом виде он сообществу не нужен. И в конечном счете даже самому Эрану стал неинтересен.
Кстати, поставьте себя в эту ситуацию: Вы руководитель проекта, который довели до такого абсурда, что для вас он потерял всякий смысл. Причем на столько, что вы предпочли, чтобы ваше имя убрали из числа авторов проекта. По мне так у чувака просто ангельское терпение. Я бы ушёл гораздо раньше…
А то, что за счет ОAuth 2.0 десяток коммерческих компаний сэкономят средства на разработке инфраструктуры c нуля, это конечно же прекрасно… Просто задача стандарта изначально заключалась в повышении возможностей интеграции и общего уровня безопасности публичных сервисов, за счет того, что основополагающие протоколы и механизмы защиты будут частью стандарта. Но имеем то что имеем…
Вспомните в чем была проблема с OAuth 1.0 и почему было решено разрабатывать новый стандарт. OAuth 2.0 в конечном счете эту задачу не решил… Уход из комитета представителей от сообщества конкретный показатель, что в этом виде он сообществу не нужен. И в конечном счете даже самому Эрану стал неинтересен.
Кстати, поставьте себя в эту ситуацию: Вы руководитель проекта, который довели до такого абсурда, что для вас он потерял всякий смысл. Причем на столько, что вы предпочли, чтобы ваше имя убрали из числа авторов проекта. По мне так у чувака просто ангельское терпение. Я бы ушёл гораздо раньше…
А то, что за счет ОAuth 2.0 десяток коммерческих компаний сэкономят средства на разработке инфраструктуры c нуля, это конечно же прекрасно… Просто задача стандарта изначально заключалась в повышении возможностей интеграции и общего уровня безопасности публичных сервисов, за счет того, что основополагающие протоколы и механизмы защиты будут частью стандарта. Но имеем то что имеем…
Зачем мне понимать какой у вас flow операций, если для того, чтобы интегрироваться с вашим сервисом мне всё равно придется брать ваши инструменты, поскольку мои гарантированно будут не совместимы с вашими?
Это откровенная глупость. С чего бы инструментам быть несовместимыми если принцип один и тот же а URI — должны быть в конфигах. Если бы было так, как вы говорите — не существовало бы ни DotNetOpenAuth, ни OmniAuth, ни oauth2-php.
Sign up to leave a comment.
Редактор OAuth 2.0 попросил вычеркнуть своё имя из спецификаций