Как интегрировать OAuth с одностраничным приложением?

Ответ 1

В большинстве случаев перенаправление подходит даже для SPA, потому что пользователям не нравится размещать свои учетные данные службы X на любом другом сайте, кроме X. Альтернативой будет использование небольшого всплывающего окна, вы можете проверить, что Discourse. IMHO перенаправление лучше всплывающего окна.

Google Некоторые поставщики поддерживают ресурс владельца ресурсов, который вы описали как отправка имени пользователя и пароля, но это не приятно. Это проблемы, которые я вижу:

• Запрос учетных данных Google для пользователей на вашем сайте будет недействительным для некоторых пользователей.
• Потребителям ресурсов необходимо также client_secret, и это то, что вы НЕ должны вставлять в javascript на стороне клиента. Если вы создадите экземпляр потока ресурсов у своего серверного приложения, и ваше приложение не находится в том же географическом регионе, что и пользователь, пользователь получит предупреждение "эй, кто-то пытается получить доступ с вашими учетными данными из Индии".

OAuth описывает поток на стороне клиента, называемый неявный поток. Используя этот поток, вам не нужно никакого взаимодействия на стороне сервера, и вам не нужен client_secret. Поставщик OAuth перенаправляет ваше приложение с помощью "# access_token = xx". Он называется неявным, потому что вам не нужно обменивать код авторизации на токен доступа, вы получаете напрямую access_token.

Google реализует неявный поток, проверьте: Использование OAuth2 для клиентских приложений.

Если вы хотите использовать неявный поток с каким-то провайдером, который не поддерживает его, как Github, вы можете использовать брокер аутентификации, например Auth0.

отказ от ответственности: Я работаю для Auth0.

Ответ 2

То, что сказал Хосе Ф. Романелло, верно. Тем не менее, ваш вопрос широк, и поэтому я считаю, что любые предлагаемые выводы - это просто обобщения на данном этапе.

Состояние приложения

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

Примечание. Вы увидите много советов, чтобы просто игнорировать это в Интернете. Это связано с тем, что многие люди хранят большую часть состояния своего приложения в серверном хранилище сеансов и очень мало на своем (тонком) клиенте. Иногда по ошибке, иногда это действительно имеет смысл - убедитесь, что это делает для вас, если вы решите проигнорировать его. Если вы разрабатываете толстый клиент, обычно этого не происходит.

Всплывающие диалоги

Я понимаю, что всплывающие окна имеют плохую репутацию в Интернете из-за всех их злоупотреблений, но нужно учитывать хорошее применение. В этом случае они служат точно таким же целям, как и доверенные диалоги в других типах систем (думаю, Windows UAC, fd.o polkit и т.д.). Эти интерфейсы все становятся узнаваемыми и используют свои базовые функции платформы, чтобы убедиться, что их нельзя подделать, и что вход или отображение не могут быть перехвачены непривилегированным приложением. Точная параллель заключается в том, что хром браузера и, в частности, замок-замок не могут быть подделаны, и что политика одного происхождения предотвращает доступ приложения к всплывающей DOM. Взаимодействие между диалоговым окном (popup) и приложением может происходить с использованием обмена сообщениями между документами или другими методами.

Вероятно, это оптимальный способ, по крайней мере, до тех пор, пока браузеры каким-то образом не стандартизируют авторизацию привилегий, если они когда-либо будут. Даже тогда процессы авторизации для определенных поставщиков ресурсов могут не соответствовать стандартизованным практикам, поэтому гибкие пользовательские диалоги, которые мы видим сегодня, могут быть просто необходимы.

Переходы с одним окном

Имея это в виду, верно, что эстетика всплывающего окна является субъективной. В будущем браузеры могут предоставить API-интерфейсы, позволяющие загружать документ в существующее окно без выгрузки существующего документа, а затем разрешить новому документу выгружать и восстанавливать предыдущий документ. Будет ли "скрытое" приложение работать или заморожено (подобно тому, как технологии виртуализации могут заморозить процессы) является еще одним дебатом. Это позволит выполнить ту же процедуру, что и при всплывающих окнах. Нет такого предложения, о котором я знаю.

Примечание. Вы можете имитировать это, сделав так, чтобы все состояние вашего приложения было легко сериализуемым и имело процедуру, которая хранит и восстанавливает его в/из локального хранилища (или удаленного сервера). Затем вы можете использовать перенаправления старой школы. Как предполагалось в начале, это потенциально очень навязчиво для кода приложения.

Вкладки

Еще одной альтернативой, конечно же, является открытие новой вкладки, общение с ней точно так же, как вы бы всплывали, а затем закрыть ее таким же образом.

При получении учетных данных пользователя из непривилегированного приложения

Конечно, он может работать только в том случае, если ваши пользователи доверяют вам достаточно, чтобы не отправлять учетные данные на ваш сервер (или в любом месте, где они не хотят, чтобы они заканчивались). Если вы открываете исходный код и выполняете детерминированные сборки/минимизацию, теоретически это возможно для пользователей для аудита или для кого-то для проверки кода, а затем автоматически убедитесь, что вы не нарушили версию среды выполнения, тем самым завоевывая доверие. Инструментом для этого в Интернете является несуществующий AFAIK.

При этом иногда вы хотите использовать OAuth с поставщиком удостоверений под вашим контролем/авторитетом/брендом. В этом случае вся эта дискуссия спорна - пользователь вам уже доверяет.

Заключение

В конце концов, это сводится к (1), насколько толстый ваш клиент, и (2) что вы хотите UX.

Ответ 3

OAuth2 имеет 4 потока aka типов грантов, каждый из которых выполняет определенную цель:

• Код авторизации (тот, на который вы ссылались, который требует перенаправления)
• неявный
• Учетные данные клиента
• Учетные данные владельца ресурса

Короткий ответ: использовать Неявный поток.

Зачем? Выбор типа потока или типа зависит от того, может ли какая-либо часть вашего кода оставаться частной, таким образом, способна хранить секретный ключ. Если это так, вы можете выбрать наиболее безопасный поток OAuth2 - Authorization Code, иначе вам придется идти на компромисс в менее безопасном потоке OAuth2. например, для одностраничного приложения (SPA), которое будет иметь Implicit поток.

Поток Client Credential работает только в том случае, если веб-служба и пользователь являются одним и тем же объектом, т.е. Веб-служба обслуживает только этого конкретного пользователя, тогда как поток Resource Owner Password Credential является наименее безопасным и используется в качестве последнего средства, поскольку пользователю требуется дать ей учетные данные социального входа в службу.

Чтобы полностью понять разницу между рекомендуемым Implicit потоком и потоком Authorization Code (тот, на который вы ссылались и требует перенаправления), взгляните на поток бок о бок:

Эта диаграмма взята из: https://blog.oauth.io/introduction-oauth2-flow-diagrams/