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

Question

Я реализую OAuth-провайдер, используя библиотеку DevDefined. Интересно, существует ли какая-либо рекомендуемая структура базы данных для хранения данных о потребителях и токенах на стороне сервера. Любые советы по этому вопросу будут оценены!

Answer 1

NB: ответ ниже применим в основном к OAuth 1.0

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

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

RequestTokens

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

AccessTokens

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

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

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

UsedNonces

• данное время
• отметка времени

Обработка одноразовых номеров была действительно самым большим вопросом дизайна для меня. 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-адреса
• Время жить за знак
• Возможность обновления / обновления токенов
• Список можно продолжить...