Простая, безопасная система аутентификации API

Question

Простая, безопасная система аутентификации API

обновил вопрос @vladislav, так что вот он в родном js:

var button1 = document.getElementById('button1');
var button2 = document.getElementById('button2');
var check1 = document.getElementById('check1');
var check2 = document.getElementById('check2');

button1.addEventListener('click', function(event) {
    // check if already has ✓ letter
    if ( check1.innerHTML === '✓' ) {
       check1.innerHTML = '';
       return;
    }         
      check1.innerHTML = '✓';
      check2.innerHTML = '';
    
});

button2.addEventListener('click', function(event) {
    // check if already has ✓ letter
    if ( check2.innerHTML === '✓' ) {
       check2.innerHTML = '';
       return;
    }
    
    check1.innerHTML = '';
    check2.innerHTML = '✓';
});

<div class="pipeline-modal-content">
    <button id="button1">
        <span>name 1</span>
    </button>
    <span id="check1"></span>
</div>
<div id="a" class="pipeline-modal-content">
    <button id="button2">
        <span>name 2</span>
    </button>
    <span id="check2"></span>
</div>

, а также [114 ] ответ, потому что у вас есть jquery тег в вашем вопросе:

$('#button1').on('click', function(){

    if( $('#check1').html() == '✔' ){
        $('#check1').html('');
        return;
    }
    
    $('#check1').html('✔');
    $('#check2').html('');
});

$('#button2').on('click', function(){

    if( $('#check2').html() == '✔' ){
        $('#check2').html('');
        return;
    }
    
    $('#check2').html('✔');
    $('#check1').html('');
});

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
<div class="pipeline-modal-content">
    <button id="button1">
        <span>name 1</span>
    </button>
    <span id="check1"></span>
</div>
<div id="a" class="pipeline-modal-content">
    <button id="button2">
        <span>name 2</span>
    </button>
    <span id="check2"></span>
</div>

35

json api rest key

задан 11 May 2009 в 04:56

3 ответа

Другие вопросы по тегам:

json api rest key

Похожие вопросы:

score 4 · Answer 1

Если чей-то клиентский код скомпрометирован, он должен получить новый ключ. Если их код будет раскрыт, вы мало что сможете сделать.

Однако вы можете быть более строгими, потребовав, чтобы IP-адреса авторизованных серверов были зарегистрированы в вашей системе для данного ключа. Это добавляет дополнительный шаг и может быть излишним.

Я не уверен, что вы имеете в виду, используя «простой ключ API», но вы должны использовать какой-то тип аутентификации с закрытыми ключами (известный только клиенту и серверу) , а затем выполнить какой-то алгоритм контрольной суммы для данных, чтобы убедиться, что клиент действительно тот, кем вы его считаете, и что данные не были изменены при передаче. Amazon AWS - отличный пример того, как это сделать.

Я думаю, что это может быть немного строго, чтобы гарантировать, что код не был взломан на стороне ваших клиентов. Я считаю разумным возложить на своих клиентов ответственность за безопасность их собственных данных. Конечно, это предполагает, что злоумышленник может испортить только учетную запись этого клиента.

Возможно, вы могли бы вести журнал того, какие IP-запросы поступают от конкретной учетной записи, и, если появится новый IP-адрес, пометьте учетную запись, отправьте электронное письмо клиенту и попросите его авторизовать этот ip. Не знаю, может, что-то подобное сработает.

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

score 2 · Answer 2

Обычно у вас есть два варианта: либо ограничить доступ по IP или иметь ключ API, оба варианта имеют свои положительные и отрицательные стороны.

Ограничение по IP
Это может быть удобным способом ограничить доступ к вашему сервису. Вы можете точно определить, каким сторонним сервисам будет разрешен доступ к вашему сервису, не заставляя их реализовывать какие-либо специальные функции аутентификации. Однако проблема с этим методом заключается в том, что если сторонняя служба написана, например, полностью на JavaScript, тогда IP-адрес входящего запроса будет не IP-адресом сервера сторонней службы, а IP-адресом пользователя, поскольку запрос сделан. браузером пользователя, а не сервером. Таким образом, использование ограничения IP сделает невозможным создание клиентских приложений и заставит все запросы проходить через сервер с соответствующими правами доступа. Помните, что IP-адреса также могут быть подделаны.

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

В основном, если вы хотите быть уверены, что только несколько услуг, Если конкретно определено, что вам будет разрешен доступ к вашей службе, тогда вам останется только использовать ограничение IP и, следовательно, заставить их маршрутизировать все запросы через свои серверы. Если вы используете ключ API, у вас нет возможности принудительно применить это.

score 28 · Answer 3

Вам следует использовать OAuth.

Фактически существует две спецификации OAuth: трехсторонняя версия и двухсторонняя версия. Трехногая версия привлекает наибольшее внимание, и это не та, которую вы хотите использовать.

Хорошая новость в том, что двухногая версия делает именно то, что вы хотите, он позволяет приложению предоставлять доступ другому через общий секретный ключ (очень похожий на модель веб-службы Amazon, вы будете использовать метод подписи HMAC-SHA1) или через систему открытого / закрытого ключей (используйте метод подписи: RSA-SHA1 ). Плохая новость заключается в том, что он еще не так хорошо поддерживается, как трехсторонняя версия, поэтому вам, возможно, придется сделать немного больше, чем вам, возможно, пришлось бы прямо сейчас.

По сути, двухсторонний OAuth просто указывает способ «подписать» (вычислить хеш) несколько полей, которые включают текущую дату, случайное число, называемое «nonce», и параметры вашего запроса. Это делает очень сложным олицетворение запросов к вашей веб-службе.

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

Он более сложен, чем вы изначально хотели, но хорошая новость заключается в том, что многие люди потратили на него много времени, поэтому вы знаю, что ты ничего не забыл. Отличным примером является то, что совсем недавно Twitter обнаружил брешь в безопасности OAuth, над устранением которой сейчас работает сообщество. Если бы вы изобрели свою собственную систему, вы