Какие существуют варианты социальной аутентификации в Appengine — как они соотносятся?

[Этот вопрос предназначен как для того, чтобы зафиксировать мои выводы, так и для проверки их вменяемости — я опубликую свой набор ответов и посмотрю, какие появятся другие ответы и комментарии.]

Я потратил немного времени, пытаясь разобраться в различных вариантах социальной аутентификации для (python) Appengine. Меня особенно смутило то, как механизмы аутентификации, предоставляемые Google, могут взаимодействовать с другими механизмами аутентификации в социальных сетях. Картина усложняется тем фактом, что у Google хорошая интеграция со сторонними провайдерами OpenID, но некоторые из крупнейших социальных сетей не являются провайдерами OpenID (например, facebook, twitter). [Обратите внимание, что facebook может использовать OpenID в качестве ретранслятора, но не в качестве провайдера].

Тогда возникает следующий вопрос: каковы различные варианты социальной аутентификации в Appengine и каковы плюсы и минусы каждого из них?


python facebook-authentication google-app-engine oauth openid
person Sean M    schedule 05.10.2011    source источник

Ответы (1)


arrow_upward
11
arrow_downward

В моем исследовании этого вопроса я обнаружил, что есть три основных варианта:

  1. Используйте механизмы аутентификации Google (включая их федеративный вход через OpenID)

    • Pros:
      • You can easily check who is logged in via the Users service provided with Appengine
      • Google обеспечивает безопасность, поэтому вы можете быть уверены, что она хорошо протестирована.
    • Cons:
      • This can only integrate with third party OpenID providers; it cannot integrate with facebook/twitter at this time

  2. Используйте механизмы социальной аутентификации, предоставляемые известным фреймворком, таким как tipfy или django.

    • Pros:
      • These can integrate with all of the major social authentication services
      • Они довольно широко используются, поэтому они, вероятно, будут достаточно надежными и довольно хорошо протестированными.
    • Cons:
      • While they are probably well tested, they may not be maintained
      • Они являются частью более крупной структуры, с которой вам, возможно, придется освоиться перед развертыванием своего приложения.

  3. Сверните собственную социальную аутентификацию

    • Pros:
      • You can do mix up whatever flavours of OpenID and OAuth tickles your fancy
    • Cons:
      • You are most likely to introduce security holes
      • Если у вас нет опыта работы с этими технологиями, это, вероятно, займет больше всего времени.

Дополнительные примечания:

  • Вполне вероятно, что рано или поздно все перейдут на OpenID, и тогда везде будет работать стандартная аутентификация Google.
  • Первый вариант позволяет указать пальцем на Google, если есть проблема с их аутентификацией; второй вариант накладывает на вас больше ответственности, но все же позволяет сказать, что вы пользуетесь широко используемым решением, если есть проблема и окончательный вариант возлагает всю ответственность на вас
  • Большинство проблем связаны с управлением сеансом — в случае 1 Google выполняет все управление сеансом, и это практически незаметно для разработчика; во втором случае управление сеансом осуществляется фреймворком, а в третьем случае вы должны разработать свой собственный.
person Sean M    schedule 05.10.2011