Реализация сервера OAuth 1.0 или 2.0? Собственная аутентификация мобильного приложения

Существует множество ресурсов, описывающих использование OAuth с точки зрения клиентов, использования API Facebook / LinkedIn / Twitter. Хорошо. Но меня интересует реализация сервера OAuth. Цель состоит в том, чтобы иметь веб-приложение, которое также может быть доступно для мобильных устройств (собственные приложения), поэтому мне нужно настроить OAuth на моем внутреннем Java-сервере. Поэтому я хотел бы знать, как LinkedIn / Facebook / Twitter реализовали OAuth на своей стороне сервера, и различать пользователей между auth_token-s и предоставлять соответствующий доступ (какое-то сопоставление базы данных - auth_token = идентификатор пользователя?).

Или, может быть, есть лучший способ аутентификации мобильного пользователя (я собираюсь использовать сервисы в стиле REST для серверной части)?


mobile java oauth-2.0 oauth facebook-oauth
person Aliaksandr Kazlou    schedule 11.12.2011    source источник

Ответы (1)


arrow_upward
5
arrow_downward

Facebook, LinkedIn и Twitter внедрили OAuth в соответствии со спецификациями для OAuth 1 (Twitter LinkedIn) и черновик для OAuth 2 (Facebook, LinkedIn).

Я бы посоветовал перейти на OAuth 1 или OAuth 2 User Agent Flow. Если вы настроены на OAuth, то это так. Вы всегда можете использовать простую базовую аутентификацию, чтобы начать и сосредоточьтесь на действительно сложных частях, а именно на дизайне вашего API.

Если вы думаете о OAuth, ознакомьтесь со списком библиотек кода: http://oauth.net/code/ < / а>. А также ознакомьтесь со спецификациями, если вы хотите реализовать поставщика OAuth, вы должны знать и понимать спецификации. В противном случае вы попадете в мир боли, ища нестандартные библиотеки, которые решат все "OAuthy" за вас.

person Jon Nylander    schedule 12.12.2011
comment
Не могли бы вы также уточнить, знакомы ли вы со спецификацией OAuth - указывает ли она, как генерировать токен и как сопоставлять токены с идентификатором пользователя (хэш-карта времени выполнения, база данных и т. Д.), Или эта часть отсутствует в спецификации , и это зависит от реализации провайдера, поэтому Twitter / Facebook / LinkedIn у каждого из них есть собственная реализация провайдера? Может быть, вы знаете какие-либо презентации / документы, доступные по архитектуре / реализации OAuth этими компаниями? - person Aliaksandr Kazlou; 12.12.2011
comment
Генерация токена и секрета не указана, это действительно зависит от разработчика со следующим утверждением: urged to err on the side of caution, and use the longest secrets reasonable. То есть использовать жесткий алгоритм шифрования с действительно случайными и сложными солями. Что касается OAuth 1, прочтите это: dev.twitter.com/docs/auth/oauth. В нем описывается, что необходимо сделать разработчику клиента, а, следовательно, и то, что вам, как провайдеру, необходимо придерживаться и поддерживать. Более подробно статей по реализации я не нашел. На мой взгляд, все сводится к пониманию спецификаций. - person Jon Nylander; 12.12.2011
comment
Другой момент заключается в том, что для проблемной области OAuth 1 потребитель (клиент) и провайдер (сервер) фактически делают одно и то же, они подписывают параметры одними и теми же секретами, поэтому клиентскую библиотеку для подписи запросов можно легко использовать для подписи запросов. для проверки на стороне сервера. Разница в том, что как только это будет сделано, одна часть отправит ответы, а другая их получит. Для OAuth 2 разница больше зависит от того, какой поток вы выберете. User Agent Flow кажется наиболее часто адаптируемым. Но имейте в виду, что OAuth 2 все еще является черновиком спецификации. - person Jon Nylander; 12.12.2011