Рекомендуемая структура базы данных для провайдера OAuth

Question

Я реализую OAuth-провайдер с использованием библиотеки DevDefined.

Интересно, существует ли какая-либо рекомендуемая структура базы данных для хранения данных о потребителях и токенах на стороне сервера.

Любые рекомендации на этот счетбыть оцененным.

Answer 1

Примечание: приведенный ниже ответ применим в основном к OAuth 1.0

Я действительно ничего не знаю о библиотеке DevDefined.Но вот нетехническое описание структуры базы данных, с которой я закончил работать в своем последнем проекте с использованием базы данных SQL.

Оно должно охватывать все необходимое для соблюдения базовой спецификации.Я пытался свести его к абсолютному минимуму.

RequestTokens

• токен (здесь я использую MD5, первичный ключ)
• consumerKey (уникальный идентификатор для потребителя)
• секрет (SHA1)
• createTime (временная метка)
• обратный вызов

AccessTokens

• токен (MD5, первичный ключ)
• секрет (SHA1)
• consumerKey
• userID (относится к владельцу ресурса)
• createTime

Потребители (зарегистрированные сторонние приложения)

• consumerKey (MD5, первичный ключ)
• consumerSecret (SHA1)
• userID (относится к разработчику, зарегистрировавшему приложение, не уникальное)
• description (текст для описания приложения)
• name (theназвание приложения)
• обратный вызов

UsedNonces

• nonce
• метка времени

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

Я обычно удаляю одноразовые номера старше 5 минут, исходя из того, что все запросы с отметкой времени старше 5 минут отклоняются.Я немного прощаюсь при проверке временных меток, они должны быть в формате UTC и должны быть не старше 5 минут и не опережать время моего сервера более чем на одну минуту.

Answer 2

Существует несколько способов решения этой проблемы. Одним из примеров приложения, реализующего функции как поставщика, так и потребителя, является Jira Atlassian - вот их структура:

    <prim-key field="id"/>

    <index name="oauth_consumer_token_key_index" unique="true">
        <index-field name="tokenKey"/>
    </index>
    <index name="oauth_consumer_token_index">
        <index-field name="token"/>
    </index>
</entity>

 <entity entity-name="OAuthConsumer" table-name="oauthconsumer" package-name="">
    <field name="id" type="numeric"/>
    <field name="created" type="date-time"/>
    <field name="name" col-name="consumername" type="long-varchar"/>
    <field name="consumerKey" type="long-varchar"/>
    <field name="service" col-name="consumerservice" type="long-varchar"/>
    <field name="publicKey" type="very-long"/>
    <field name="privateKey" type="very-long"/>
    <field name="description" type="very-long"/>
    <field name="callback" type="very-long"/>
    <field name="signatureMethod" type="short-varchar"/>
    <field name="sharedSecret" type="very-long"/>

    <prim-key field="id"/>

    <index name="oauth_consumer_index" unique="true">
        <index-field name="consumerKey"/>
    </index>
    <index name="oauth_consumer_service_index" unique="true">
        <index-field name="service"/>
    </index>
</entity>

<!-- OAUTH ServiceProvider-->
<entity entity-name="OAuthServiceProviderConsumer" table-name="oauthspconsumer" package-name="">
    <field name="id" type="numeric"/>
    <field name="created" type="date-time"/>
    <field name="consumerKey" type="long-varchar"/>
    <field name="name" col-name="consumername" type="long-varchar"/>
    <field name="publicKey" type="very-long"/>
    <field name="description" type="very-long"/>
    <field name="callback" type="very-long"/>

    <prim-key field="id"/>

    <index name="oauth_sp_consumer_index" unique="true">
        <index-field name="consumerKey"/>
    </index>
</entity>

<entity entity-name="OAuthServiceProviderToken" table-name="oauthsptoken" package-name="">
    <field name="id" type="numeric"/>
    <field name="created" type="date-time"/>
    <field name="token" type="long-varchar"/>
    <field name="tokenSecret" type="long-varchar"/>
    <field name="tokenType" type="short-varchar"/>
    <field name="consumerKey" type="long-varchar"/>
    <field name="username" type="long-varchar"/>
    <field name="ttl" type="numeric"/>
    <field name="auth" col-name="spauth" type="short-varchar"/>
    <field name="callback" type="very-long"/>
    <field name="verifier" col-name="spverifier" type="long-varchar"/>
    <field name="version" col-name="spversion" type="short-varchar"/>

    <prim-key field="id"/>

    <index name="oauth_sp_token_index" unique="true">
        <index-field name="token"/>
    </index>
    <index name="oauth_sp_consumer_key_index">
        <index-field name="consumerKey"/>
    </index>
</entity>

Обычно основы имитируют спецификацию - за исключением пользовательских расширений, с которыми вы можете иметь дело:

• IP-адрес ограничения
• Время жить за токен
• Возможность обновления / обновления токенов
• Список можно продолжить ...