Как клиентские JS-библиотеки для OAuth2 поддерживают безопасную аутентификацию?

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

Трудность использования JS-клиента для OAuth2 заключается в том, что вы не можете хранить секрет клиента, потому что он будет широко доступен в браузере. То есть в этом вопросе SO наивысший рейтинг говорит:

"Я думаю, что параметры tokenSecret и consumerSekret должны быть секрет! Как они могут оставаться секретными при загрузке в браузер?!!!"

Поэтому, как рамки OAuth2 на стороне клиента, такие как hello.js или oauth.io преодолеть эту проблему? Я знаю, что они используют прокси-сервер на стороне сервера (который знает ID и секрет) для своих запросов, но клиентский JS-код все равно должен каким-то образом сообщить прокси-серверу, кто он. Итак, что мешает кому-либо принимать JS-код с моего сайта и разговаривать с прокси-сервером от моего имени?

Я также нашел Клиентскую библиотеку API Google API для JavaScript. AFAIK там клиентский код не передает секрет. Правильно ли я понимаю, что они справляются с этим, имея предопределенный адрес ответа OAuth? (так что токены всегда возвращаются через предопределенный HTTP-адрес). Так что, даже если кто-то пытается олицетворять мой сайт, используя мой идентификатор, токены все равно будут возвращены на мой сайт?

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

Ответ 1

В OAuth2 есть потоки, которые не требуют секретов (например, поток implicit обычно используется для клиентов на базе JS, SPA и т.д.). Однако не все поставщики поддерживают этот поток, поэтому в таких ситуациях вам нужен компонент на стороне сервера, который согласовывает это для вас, а затем обрабатывает взаимодействия с вашим интерфейсом/устройством.

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

Образцы этих потоков находятся здесь: https://docs.auth0.com/protocols#5

Update: Существует специальный протокол обмена протоколом/токеном для "публичных клиентов", который добавляет дополнительную безопасность: PKCE (как это работает: https://auth0.com/docs/protocols#oauth2-pkce-for-public-clients)

Ответ 2

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

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

Ответ 3

Вся путаница касается параметров, которые мы должны пройти для получения токена доступа. Я сделал небольшой код lib. @ git вы можете проверить это.

https://github.com/dev-sandeep/oauth-js

var deferred = jQuery.ajax({
            url: '',//Access URL goes here
            method: 'POST',
            dataType: 'text',
            data: {
                scope: scope, //your scope
                client_id: clientId,//client id
                client_secret: clientSecretId,//client secret id
                grant_type: 'client_credentials'
            },
            headers: {
                'Accept': 'application/json, application/x-www-form-urlencoded',
                'Content-Type': 'application/x-www-form-urlencoded',
            },
            complete: function (xhr, data) {
                /* YOUR WORK STARTS HERE! */
                console.warn(xhr, data);
            }
        });