Возможно ли реализовать Oauth 2.0 без javascript?

Question

На моем сайте электронной коммерции я предлагаю своим пользователям openid login. Все основные поставщики, за исключением facebook, предложили openid endpoint this. Facebook предлагает только oauth 2.0.

Для этого исключения я сам создал конечную точку openid, где пользователи могут войти в систему, используя facebook oauth.

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

Сейчас amazon joined the league единого входа на поставщиков. Они поддерживают только oauth 2.0.

В целом oauth 2.0, по-видимому, является победителем, а не openid, так как все провайдеры, которых я забочусь, также поддерживают oauth.

Так что я подумал о том, чтобы реализовать oauth прямо на моем сайте электронной коммерции.

Однако инструкции по внедрению сильно отличаются от поставщика провайдера.

Большинство из них требуют, чтобы на сайт загружался внешний javascript. Загрузка внешних javascripts для каждого поставщика oauth, который я хочу поддержать, - это вариант, который я бы хотел избежать.

Facebook предлагает полностью серверную сторону, без использования javascripts.

Amazon нет.

Но все ли это oauth 2.0, не так ли?

Мне кажется, что либо стандарт очень расслаблен, либо не выполняется последовательно.

Возможно ли иметь общий класс oauth 2.0, где я просто передаю конфигурацию и конечные точки, специфичные для theprovider, и получить логин?

Я посмотрел на реализацию Zend, но это действительно очень огромный ... facebook не-Javascript реализация действительно мало ...

Я немного потерял здесь. Может ли кто-нибудь указать мне в правильном направлении?

Я хочу реализовать несколько поставщиков oauth. Среди тех, кто уверен, google, facebook, amazon и twitter.

Можно ли сделать это с одной и той же кодовой базой, или мне нужно внедрить их все отдельно, используя их классы sdk и javascripts?

я мог бы сделать это без проблем, но мой Gutts действительно не нравится по нескольким причинам (обслуживания, гибкости, addint новых proviers и т.д ..)

А где OAuth 2,0 стандарта в этом?

Любая помощь предоставляется.

Личные Sidenote

Я извиняюсь за эту возможность кратко указать на то, что я не как Oauth. Он требует, чтобы каждый сайт, который использует его, регистрировался у поставщиков . Также эти поставщики могут не согласиться на сотрудничество с сайтами. Мне не нравится эта власть, я предпочитаю openid. Я знаю его не отлично, но я предпочитаю его. Кроме того, openid и oauth уязвимы для дизайна для атаки, где вредоносные сайты позволяют пользователю нажать кнопку входа и открыть страницу поддельного провайдера, где пользователь регистрирует , полагая, что он заходит на сайт провайдера. Он не может быть помог, пользователь должен посмотреть на URL-адрес, чтобы узнать, действительно ли он нужен . Я знаю, что это фундаментальная проблема и трудная задача: , но я хотел бы указать на это.

Answer 1

На самом деле, вам не нужен javascript вообще для реализации клиента OAuth. OAuth 2.0 (или 1.0) является стандартным, поэтому для подключения к любому сайту, использующему OAuth, вам необходимо следовать тем же шагам, возможно, с небольшими вариациями.

В PHP я использовал эту библиотеку, хотя я не знаю, подходит ли он OAuth 2,0, я работал с 1.0 и 1.0a:

• https://github.com/themattharris/tmhOAuth
• https://github.com/themattharris/tmhOAuth-examples

Он должен установите все серверы, которые вам нужно подключить. Кроме того, некоторые чтения о «теории» протокола OAuth могли бы вам помочь: http://oauth.net/2/

Answer 2

Существует большое сходство между провайдерами и основным потоком. В браузере часто нет необходимости в Javascript. То, что дает вам каждый поставщик, - это просто помощник, чтобы облегчить вам жизнь (если вы просто заботитесь о них).

Кажется, что вы работаете на веб-сайте. Для этого поток OAuth 2, который вам нужно реализовать, называется Код авторизационного кода. И нижняя линия это всего лишь несколько HTTP (S) запросов, которые следуют за очень похожую картину:

1. Перенаправление пользователя к провайдеру
2. Войти & страницы согласия
3. Перенаправление на ваш сайт (зарегистрированному обратного вызова адрес) с code
4. ваш сайт запрашивающего access_token от поставщика, используя code от шага # 3 и client_id/client_secret (в основном, учетные данные для вашего веб-сервера.
5. Используйте access_token, полученный в # 4, для вызова API-провайдера.

Об этом я писал here если хотите, посмотрите подробнее. Это в контексте product, над которым я работаю, но принципы одинаковы.

Где вещи получить немного более сложным, часто является:

• Разрешения scope, которые отличаются от одного провайдера к другому. Например: Facebook имеет множество опций, с очень тонким контролем над тем, что вы запрашиваете у пользователя, чтобы раскрыть (например, друзья, фотографии и т. Д.). LinkedIn имеет меньше (например, профиль, сеть, уведомления). У Amazon только два (имя, почтовый_код).

Все они являются специфическими поставщиками, поскольку они связаны с ресурсами, которыми они управляют. Обратите внимание, что OAuth по существу является протоколом авторизации (часто используется для аутентификации). Во многих случаях, если вы не собираетесь называть их API, вы в порядке с минимальной областью.

• Информация о пользователе. Большинство провайдеров имеют конечную точку /userprofile для извлечения атрибутов зарегистрированного пользователя. Но часто раз, каждый из них обычно реализует разные схемы: некоторые используют email, другие могли бы назвать это emailaddress. То же самое с last_name vs family_name и т. Д. Это зависит от вас, чтобы нормализовать профиль во что-то с общей семантикой.

Для нашей системы мы выбрали все, что возможно, для openid connect userinfo standard claims. Не всегда возможно, потому что провайдеры обычно предоставляют больше информации. (Here's что мы на самом деле поставляем)

Что касается вашей стороны, обратите внимание: вы правы, повод для использования SSL всегда. А также причина, по которой некоторые поставщики добавляют многофакторную аутентификацию.