Лучший способ обработать аутентификацию пользователя на веб-сайте и в гем-клиенте

Question

Мы работаем над сервисом, который будет иметь доступ к веб-сайту для статистики и других задач, но большая часть использования будет через клиентские гемы и рейки. Каков наилучший способ обработки аутентификации для обеих частей.

Похоже, что fiveruns_tuneup, getexceptional, New Relic и другие имеют веб-сайты с именем пользователя и паролем, но используют ключи API, хранящиеся в ./config/serviceName.yml. По любым причинам лучше использовать ключи API, а не user / pass config (они используют ключи, потому что часто ключ проверяется в SCM и используется по всему проекту, где наш не будет проверен и будет индивидуальным для каждого пользователя)

GitHub позволяет вам разместить свой открытый ключ на серверах github и использует его, но я думаю, что git поддерживает открытый / закрытый ключ по умолчанию.

Было бы предпочтительнее сохранить ./config/serviceName.yml или так как мы должны создать подкаталог с другой информацией, имеющей ./serviceName/config.yml? (означает, что для каждого пользователя, не хранящегося в SCM, лучше хранить все это в одном исключенном каталоге?)

Просто ищите несколько мыслей и идей по передовому опыту перед началом реализации.

Answer 1

Я рекомендую использовать сочетания имени пользователя и пароля для учетных записей веб-сайта и ключи API для любых веб-служб. Вот преимущества этой техники:

1. Связав ключи API с учетной записью, вы можете получить множество ключей API для одного и того же пользователя. Возможно, это можно использовать для многих удаленных веб-серверов, которые используют эту службу данных, или для выполнения уникального отслеживания.
2. Присоединение ключей API к учетной записи также позволяет сохранить бескомпромиссное имя пользователя и пароль пользователя, поскольку ключ API не будет содержать их. Многие пользователи используют одно и то же имя пользователя и пароль во многих службах, поэтому вы помогаете защитить их.
3. Вы можете ограничить доступ к частям функциональности для каждого ключа API, но дать своему имени пользователя доступ ко всему, к чему у их учетной записи должен быть доступ. Кроме того, вы даже можете дать им возможность ограничить доступ к API-ключу.

Большинство основных служб (Yahoo! API, Flickr, Google API и т. Д.) Используют учетные записи с именем пользователя и паролем для входа в веб-аккаунт и ключами API для точек интеграции.

Answer 2

Никогда не используйте user / pass, когда вы можете помочь. Проблемы безопасности ужасны. Если пользователь / пароль утек, вы должны изменить свой пароль, или они получат доступ ко всей вашей учетной записи.

Ключи API лучше, потому что их легче изменить, и их можно ограничить только той частью, к которой вам нужен доступ через API (т. Е. Если у кого-то есть ваш пароль, он может изменить ваш пароль. есть ключ API).

Различные API-ключи для каждого клиента или безопасный обмен токенами (например, OAuth) - лучшее решение, если у вас в API будет больше, чем просто ваш клиент.

Answer 3

Подход github - это начальная загрузка поверх существующих методов git, однако это неплохая идея, поскольку, предположительно, у каждого пользователя будет свой собственный закрытый ключ, соответствующий опубликованному общедоступному ключу в центральном органе управления. Поскольку ключевой агент уже предоставляет средства безопасной аутентификации, это кажется очень безопасным подходом. Открытый / закрытый ключи - это хорошо продуманная схема аутентификации, которая, к сожалению, многократно переосмысливалась до ограниченного успеха.

Проблема с ключом API заключается в том, что любой, кто получает копию ключа API, может делать все, что ему разрешено. Хранение ключа API где-то в проекте требует от пользователей совместного использования ключа. Если вы связываете открытые ключи с пользователем, можно предоставлять права клиенту для каждого пользователя, и правильный подход агента ключа предполагает, что они не будут храниться в SCM где-либо еще.

Я не уверен, что соблюдаю разницу между config / serviceName.yml или serviceName / config.yml. Не похоже, что было бы уместно, если у вас есть открытый / закрытый ключи в качестве метода аутентификации для клиента.