database design - certification - ¿Cuál es la estructura de base de datos recomendada para el proveedor de OAuth?

oauth2 php

Question

Estoy implementando un proveedor OAuth usando la biblioteca DevDefined. Me pregunto si hay alguna estructura de base de datos recomendada para almacenar datos de token y de consumidor en el lado del servidor. ¡Cualquier consejo sobre esto sería apreciada!

Answer 1

Hay varias formas de abordar esto, un ejemplo de una aplicación que implementa la funcionalidad del proveedor y del consumidor es la Jira de Atlassian: aquí está su estructura:

 <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>

Normalmente, los conceptos básicos imitan la especificación, a excepción de las extensiones personalizadas que puede introducir para tratar con:

• Restricciones de direcciones IP
• Tiempo de vivir para el token
• Permitir refrescar / renovar fichas.
• La lista continua...

Answer 2

NB: La respuesta a continuación se aplica principalmente a OAuth 1.0

Realmente no sé nada acerca de la biblioteca DevDefined. Pero aquí hay una descripción no técnica del diseño de la base de datos con la que terminé trabajando en mi último proyecto, utilizando una base de datos SQL.

Debe cubrir todo lo necesario para seguir la especificación básica. He tratado de mantenerlo en un mínimo absoluto.

RequestTokens

• token (yo uso un MD5 aquí, clave principal)
• consumerKey (el identificador único para el consumidor)
• secreto (SHA1)
• createTime (timestamp)
• llamar de vuelta

AccessTokens

• token (MD5, clave principal)
• secreto (SHA1)
• consumerKey
• ID de usuario (se refiere al propietario del recurso)
• createTime

Consumidores (aplicaciones de terceros registradas)

• consumerKey (MD5, clave principal)
• ConsumerSecret (SHA1)
• ID de usuario (se refiere al desarrollador que registró la aplicación, no es único)
• Descripción (un texto para describir la aplicación)
• nombre (el nombre de la aplicación)
• llamar de vuelta

UsadoNonces

• mientras tanto
• marca de tiempo

El manejo de nonces fue realmente la mayor pregunta de diseño para mí. OAuth te dice que nunca permitas que el mismo nonce se use con la misma marca de tiempo nunca más. Pero eso haría para una base de datos infinitamente enorme. Creo que la mayoría de los proveedores separan los artículos antiguos al menos de vez en cuando.

De forma rutinaria, borro los objetos que tienen más de 5 minutos, en base a la premisa de que todas las solicitudes con una marca de tiempo anterior a 5 minutos se rechazan. Soy un poco indulgente al verificar las marcas de tiempo, deben ser UTC y no deben tener más de 5 minutos, y no deben adelantarse a la hora del servidor más de un minuto.