Делается некий веб-аппликейшн — скажем, самый лучший to-do list, который должен поддерживать аутентификацию через логин-пароль, гугл и фейсбук. Станете вы по умолчанию делать всё руками — со своей таблицей Users, в которой username, password, email, googleId, facebookId, со своим кодом для отправки "Confirm your email", "Reset password", и т.д., или сразу скажете клиенту: "готовься платить за Okta/Auth0"?
Здравствуйте, rosencrantz, Вы писали:
R>или сразу скажете клиенту: "готовься платить за Okta/Auth0"?
А просто предложить оба варианта клиенту? Мол или делаем свое, но подольше и подороже, или сразу используем сервис, но потом будут платежи за его использование.
Здравствуйте, rosencrantz, Вы писали:
R>Делается некий веб-аппликейшн — скажем, самый лучший to-do list, который должен поддерживать аутентификацию через логин-пароль, гугл и фейсбук. Станете вы по умолчанию делать всё руками — со своей таблицей Users, в которой username, password, email, googleId, facebookId, со своим кодом для отправки "Confirm your email", "Reset password", и т.д., или сразу скажете клиенту: "готовься платить за Okta/Auth0"?
Только руками. Т.к. "самый лучший" experience можно сделать только самому, не полагаясь на сторонние апи и сервисы с неуправляемым качеством.
Другое дело в корпоративщине — где важнее не UI/UX, а стоимость разработки и поддержка разнообразных интеграций, типа того же XACML.
Здравствуйте, rosencrantz, Вы писали:
R>Делается некий веб-аппликейшн — скажем, самый лучший to-do list, который должен поддерживать аутентификацию через логин-пароль, гугл и фейсбук. Станете вы по умолчанию делать всё руками — со своей таблицей Users, в которой username, password, email, googleId, facebookId, со своим кодом для отправки "Confirm your email", "Reset password", и т.д., или сразу скажете клиенту: "готовься платить за Okta/Auth0"?
Не хватает НФТ — требований по UX, по нагрузке, по методам аутентификации, требований СБ и так далее.
Вот в зависимости от требований и решаем.
Но вообще свой писать не так уж и сложно, если делать это не в первый раз.
Здравствуйте, rosencrantz, Вы писали:
R>Делается некий веб-аппликейшн — скажем, самый лучший to-do list, который должен поддерживать аутентификацию через логин-пароль, гугл и фейсбук. Станете вы по умолчанию делать всё руками — со своей таблицей Users, в которой username, password, email, googleId, facebookId, со своим кодом для отправки "Confirm your email", "Reset password", и т.д., или сразу скажете клиенту: "готовься платить за Okta/Auth0"?
По умолчанию делал бы руками. Не люблю все эти сервисы.
Здравствуйте, rosencrantz, Вы писали:
R>Делается некий веб-аппликейшн — скажем, самый лучший to-do list, который должен поддерживать аутентификацию через логин-пароль, гугл и фейсбук. Станете вы по умолчанию делать всё руками — со своей таблицей Users, в которой username, password, email, googleId, facebookId, со своим кодом для отправки "Confirm your email", "Reset password", и т.д., или сразу скажете клиенту: "готовься платить за Okta/Auth0"?
Руками. Там обычно ничего особо сложного нет, к тому же есть библиотеки которые это предоставят на уровне ".UseFacebook()".
А со сторонними сервисами неясно какие данные и в какой стране они хранят, можно и под закон попасть какой, если кому-то захочется докопаться.
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, rosencrantz, Вы писали:
R>>или сразу скажете клиенту: "готовься платить за Okta/Auth0"?
Doc>А просто предложить оба варианта клиенту? Мол или делаем свое, но подольше и подороже, или сразу используем сервис, но потом будут платежи за его использование.
Предположим, что у клиента нет технических людей и от вас как от эксперта ожидается "правильное решение" — как скажете, так и будет. Какое ваше решение?
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>Здравствуйте, rosencrantz, Вы писали:
R>>Делается некий веб-аппликейшн — скажем, самый лучший to-do list, который должен поддерживать аутентификацию через логин-пароль, гугл и фейсбук. Станете вы по умолчанию делать всё руками — со своей таблицей Users, в которой username, password, email, googleId, facebookId, со своим кодом для отправки "Confirm your email", "Reset password", и т.д., или сразу скажете клиенту: "готовься платить за Okta/Auth0"?
ДФ>Не хватает НФТ — требований по UX,
Ну чтоб "как у всех". Письмо с подтверждением, кнопка "забыл пароль", возможность поменять email позже с подтверждением.
ДФ>по нагрузке,
Низкая-средняя.
ДФ>по методам аутентификации,
Пароль, Google, Facebook.
ДФ>требований СБ и так далее.
Нет явных требований, но конечно если юзер 5 раз вводит пароль неправильно, было бы здорово что-то с этим сделать.
ДФ>Вот в зависимости от требований и решаем. ДФ>Но вообще свой писать не так уж и сложно, если делать это не в первый раз.
Из моего опыта — чем меньше про это читаешь, тем легче выглядит задача. Но стоит прочитать пару статей и сразу понятно, что "не так уж и сложно" будет (не) обладать определёнными качествами.
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, rosencrantz, Вы писали:
R>>Делается некий веб-аппликейшн — скажем, самый лучший to-do list, который должен поддерживать аутентификацию через логин-пароль, гугл и фейсбук. Станете вы по умолчанию делать всё руками — со своей таблицей Users, в которой username, password, email, googleId, facebookId, со своим кодом для отправки "Confirm your email", "Reset password", и т.д., или сразу скажете клиенту: "готовься платить за Okta/Auth0"?
bnk>Руками. Там обычно ничего особо сложного нет, к тому же есть библиотеки которые это предоставят на уровне ".UseFacebook()". bnk>А со сторонними сервисами неясно какие данные и в какой стране они хранят, можно и под закон попасть какой, если кому-то захочется докопаться.
С .useFacebook() действительно всё довольно прямолинейно, но вот как быть если хочется ещё username-password?
Здравствуйте, rosencrantz, Вы писали:
R>Предположим, что у клиента нет технических людей и от вас как от эксперта ожидается "правильное решение" — как скажете, так и будет. Какое ваше решение?
Вопрос частью не технический. Готов ли сам клиент платить ежемесячно за сервис (и сколько). Если нет — то и вариантов нет. Но допустим клиент не против.
Второй момент — что за проект, бюджет и сроки разработки (и если ли свои готовые наработки). Т.е. какая часть бюджета и сроков пойдет на свою систему аутентификации, сравниваем фичи что сами сделаем и что есть в сервисе. Отсюда и будет решение.
Здравствуйте, rosencrantz, Вы писали:
R>>>Делается некий веб-аппликейшн — скажем, самый лучший to-do list, который должен поддерживать аутентификацию через логин-пароль, гугл и фейсбук. Станете вы по умолчанию делать всё руками — со своей таблицей Users, в которой username, password, email, googleId, facebookId, со своим кодом для отправки "Confirm your email", "Reset password", и т.д., или сразу скажете клиенту: "готовься платить за Okta/Auth0"?
bnk>>Руками. Там обычно ничего особо сложного нет, к тому же есть библиотеки которые это предоставят на уровне ".UseFacebook()". bnk>>А со сторонними сервисами неясно какие данные и в какой стране они хранят, можно и под закон попасть какой, если кому-то захочется докопаться.
R>С .useFacebook() действительно всё довольно прямолинейно, но вот как быть если хочется ещё username-password?
Ну а сколько там форм? Пять? Напрячься да написать. Для этого сценария даже библиотеки особо не нужны, он фреймворком обычно как-то поддерживается.
Если нужна 2FA, будет наверное еще пять. Всего десять. Ну несколько дней и должно быть.
Все равно же тебе профиль пользователя делать, раз логин делаешь, так хоть будет все в одной кучке.
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, rosencrantz, Вы писали:
R>>Предположим, что у клиента нет технических людей и от вас как от эксперта ожидается "правильное решение" — как скажете, так и будет. Какое ваше решение?
Doc>Вопрос частью не технический. Готов ли сам клиент платить ежемесячно за сервис (и сколько). Если нет — то и вариантов нет. Но допустим клиент не против. Doc>Второй момент — что за проект, бюджет и сроки разработки (и если ли свои готовые наработки). Т.е. какая часть бюджета и сроков пойдет на свою систему аутентификации, сравниваем фичи что сами сделаем и что есть в сервисе. Отсюда и будет решение.
Короче, вам сколько подробностей не дай, ваша позиция — это не "писать аутентификацию руками — плохая идея, поэтому, дорогой клиент, давайте или платный сервис купим, или какой-нибудь open source аналог развернём сбоку, но точно давайте не будем писать это руками".
Здравствуйте, bnk, Вы писали:
bnk>>>Руками. Там обычно ничего особо сложного нет, к тому же есть библиотеки которые это предоставят на уровне ".UseFacebook()". bnk>>>А со сторонними сервисами неясно какие данные и в какой стране они хранят, можно и под закон попасть какой, если кому-то захочется докопаться.
R>>С .useFacebook() действительно всё довольно прямолинейно, но вот как быть если хочется ещё username-password?
bnk>Ну а сколько там форм? Пять? Напрячься да написать. Для этого сценария даже библиотеки особо не нужны, он фреймворком обычно как-то поддерживается. bnk>Если нужна 2FA, будет наверное еще пять. Всего десять. Ну несколько дней и должно быть.
bnk>Все равно же тебе профиль пользователя делать, раз логин делаешь, так хоть будет все в одной кучке.
Ну там не только к формочкам всё сводится ведь.
1. Если это наша головная боль — слать имейлы, значит нужно озабочиваться через что их слать.
2. Вот зашёл пользователь через логин-пароль, мы ему что? Кукиз? Токен? Истекать/рефрешиться оно как-то будет?
3. Зарегистрировался пользователь с имейлом a@example.org. В какой-то момент пытается его поменять на b@example.org, а b@example.org уже занят другим юзером. Должна об этом голова болеть?
В моём понимании там много таких вот вещей, которые вроде и не сказать, что сложные, но их реально очень много. Формочек мало, а обвеса — много.
Здравствуйте, rosencrantz, Вы писали:
R>Короче, вам сколько подробностей не дай, ваша позиция — это не "писать аутентификацию руками — плохая идея, поэтому, дорогой клиент, давайте или платный сервис купим, или какой-нибудь open source аналог развернём сбоку, но точно давайте не будем писать это руками".
Свои фантазии про меня держите при себе, ок?
И чтобы не было вопросов повторю еще раз — все будет зависеть от проекта (требований), сроков и бюджета. Возможно сервис, возможно OS, возможно свое.
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, rosencrantz, Вы писали:
R>>Короче, вам сколько подробностей не дай, ваша позиция — это не "писать аутентификацию руками — плохая идея, поэтому, дорогой клиент, давайте или платный сервис купим, или какой-нибудь open source аналог развернём сбоку, но точно давайте не будем писать это руками".
Doc>Свои фантазии про меня держите при себе, ок? Doc>И чтобы не было вопросов повторю еще раз — все будет зависеть от проекта (требований), сроков и бюджета. Возможно сервис, возможно OS, возможно свое.
Прошу прощения! У меня не было цели под-бать или обидеть. Перечитайте что я написал — речь исключительно о том, что вы не станете говорить "точно не руками и не о чем тут говорить".
"Всё будет зависеть от требований" — это понятный ответ для вопроса "сколько будет стоить проект", но он не очень уместен для вопроса который определяется не столько хотелками клиента, сколько стандартами индустрии и лучшими практиками.
Здравствуйте, rosencrantz, Вы писали:
R>Прошу прощения! У меня не было цели под-бать или обидеть. Перечитайте что я написал — речь исключительно о том, что вы не станете говорить "точно не руками и не о чем тут говорить".
R>"Всё будет зависеть от требований" — это понятный ответ для вопроса "сколько будет стоить проект", но он не очень уместен для вопроса который определяется не столько хотелками клиента, сколько стандартами индустрии и лучшими практиками.
Так и практики будут разные для разных проектов (по типу и требованиям). Универсального решения, вроде "всегда юзаем OS либы для этого", нет.
Здравствуйте, rosencrantz, Вы писали:
R>Делается некий веб-аппликейшн — скажем, самый лучший to-do list, который должен поддерживать аутентификацию через логин-пароль, гугл и фейсбук. Станете вы по умолчанию делать всё руками — со своей таблицей Users, в которой username, password, email, googleId, facebookId, со своим кодом для отправки "Confirm your email", "Reset password", и т.д., или сразу скажете клиенту: "готовься платить за Okta/Auth0"?
"Готовься поставить сбоку бесплатный Keycloak (https://keycloak.org) и включить в нём нужные identity providers, а в приложении у тебя будет стандартный jwt token со всей нужной инфой из КК (username, email, etc.)".
Здравствуйте, rosencrantz, Вы писали:
R>Делается некий веб-аппликейшн — скажем, самый лучший to-do list, который должен поддерживать аутентификацию через логин-пароль, гугл и фейсбук. Станете вы по умолчанию делать всё руками — со своей таблицей Users, в которой username, password, email, googleId, facebookId, со своим кодом для отправки "Confirm your email", "Reset password", и т.д., или сразу скажете клиенту: "готовься платить за Okta/Auth0"?
"Я сейчас один умный вещь скажу, только ты не обижайся" (с)
Ничего, никогда не нужно делать руками, если есть готовое. В данном случае, аутентификация с авторизацией только кажутся простыми. На моей памяти, такую штуку пытались прикрутить самостоятельно раза три или четыре, и каждый раз спустя полтора года обнаруживаешь отдельную команду разработчиков, пм-ов, тестеров и еще фиг знает кого, которая ковыряется с этим куском на стадии перманентной бэтты. И так с каждой фичей, которую кажется проще сделать самому, чем взять готовую.
Так что нет, never again — все что можно взять готовым, надо брать готовым, иначе это обойдется дороже и себе и заказчику. Пилить надо только то чего нет, лучший to-do лист, в данном случае.
Здравствуйте, rosencrantz, Вы писали:
R>Делается некий веб-аппликейшн — скажем, самый лучший to-do list, который должен поддерживать аутентификацию через логин-пароль, гугл и фейсбук. Станете вы по умолчанию делать всё руками — со своей таблицей Users, в которой username, password, email, googleId, facebookId, со своим кодом для отправки "Confirm your email", "Reset password", и т.д., или сразу скажете клиенту: "готовься платить за Okta/Auth0"?
для систем, где требуется хоть какая-то безопасность — свое писать нельзя. Шансов написать свой велосипед на эту тему и что-б его потом не хакнули просто нет.
Угу. Чтоб хакнули все разом и твой сервис заодно, который так никому не нужен был бы.
А вообще база юзеров это зачастую очень ценная коммерческая информация. Порой сервисы только ради этой базы и покупают. А вы всё это так легко готовы отдать незнамо кому.
R>Делается некий веб-аппликейшн — скажем, самый лучший to-do list, который должен поддерживать аутентификацию через логин-пароль, гугл и фейсбук. Станете вы по умолчанию делать всё руками — со своей таблицей Users, в которой username, password, email, googleId, facebookId, со своим кодом для отправки "Confirm your email", "Reset password", и т.д., или сразу скажете клиенту: "готовься платить за Okta/Auth0"?
Необязательно платить, можно и самостоятельно запилить на основе IdentityServer4. Достаточно популярная вещь.
Здравствуйте, rosencrantz, Вы писали:
R>Делается некий веб-аппликейшн — скажем, самый лучший to-do list, который должен поддерживать аутентификацию через логин-пароль, гугл и фейсбук. Станете вы по умолчанию делать всё руками — со своей таблицей Users, в которой username, password, email, googleId, facebookId, со своим кодом для отправки "Confirm your email", "Reset password", и т.д., или сразу скажете клиенту: "готовься платить за Okta/Auth0"?
Здравствуйте, Михaил, Вы писали:
R>>Делается некий веб-аппликейшн — скажем, самый лучший to-do list, который должен поддерживать аутентификацию через логин-пароль, гугл и фейсбук. Станете вы по умолчанию делать всё руками — со своей таблицей Users, в которой username, password, email, googleId, facebookId, со своим кодом для отправки "Confirm your email", "Reset password", и т.д., или сразу скажете клиенту: "готовься платить за Okta/Auth0"?
М>Почему что то такое не заюзать?
Если я прально понял то это как раз вариант "готовься платить за Okta/Auth0"
Y>>Необязательно платить, можно и самостоятельно запилить на основе IdentityServer4. Достаточно популярная вещь.
НС>Но довольно сложная, мутная и скоро будет платной.
IdentityServer4 платным не станет. Лет на 5 точно хватит, а там посмотрим. А Duende — да уж, лучше OpenIddict.
Здравствуйте, yenik, Вы писали:
НС>>Но довольно сложная, мутная и скоро будет платной. Y>IdentityServer4 платным не станет.
Станет. Не станет IdentityServer4 4.x. Duende IdentityServer это просто переименование.
Y> Лет на 5 точно хватит, а там посмотрим.
Софтвер, который security critical — там довольно особенные требования к обновленим обычно. 5 лет без апдейтов — такое далеко не всегда прокатит.
Y> А Duende — да уж, лучше OpenIddict.
Это не совсем взаимозаменяемые вещи. IS4 это практически готовое решение, которому только бэк надо подсунуть (ту же Скорубу, которая сама по себе та еще гадость). А OpenIddict это набор мидлверов для построения своего OAuth2 сервера. С одной стороны это большой плюс, так как он гибкий и более менее грамотно спроектирован, так что почти не блокирует разнообразные сценарии. С другой — это минус, потому что искаропки есть только чуть больше базового функционала, и если нужны всякие изыски типа token revocation или поддержки ADFS, то придется повозиться.
НС>Софтвер, который security critical — там довольно особенные требования к обновленим обычно. 5 лет без апдейтов — такое далеко не всегда прокатит.
Они не отказываются от поддержки IdentityServer4. Хотя понятно, что она не вечная.
Y>> А Duende — да уж, лучше OpenIddict.
НС>Это не совсем взаимозаменяемые вещи. IS4 это практически готовое решение, которому только бэк надо подсунуть (ту же Скорубу, которая сама по себе та еще гадость). А OpenIddict это набор мидлверов для построения своего OAuth2 сервера. С одной стороны это большой плюс, так как он гибкий и более менее грамотно спроектирован, так что почти не блокирует разнообразные сценарии. С другой — это минус, потому что искаропки есть только чуть больше базового функционала, и если нужны всякие изыски типа token revocation или поддержки ADFS, то придется повозиться.
Это понятно. Тут дилемма, что многое что искаропки нафиг не нужно, а зато многое необходимо кастомизировать, и возникает соблазн взять что-то более гибкое. С другой стороны, более гибкое заставляет слишком много стучать по клаве и неизбежно косячить.
Здравствуйте, yenik, Вы писали:
НС>>Софтвер, который security critical — там довольно особенные требования к обновленим обычно. 5 лет без апдейтов — такое далеко не всегда прокатит. Y>Они не отказываются от поддержки IdentityServer4.
У тебя есть надежда что они что то будут активно бекпортить в ветку 4.х? Гложут меня смутные сомнения. На существующих проектах может еще и можно пострадать, но тащить такие риски в новые ...
Мы уже победили, просто это еще не так заметно...
