OAuth Provider的推荐数据库结构 [英] Recommended database structure for OAuth Provider

问题描述

我正在使用DevDefined库实现OAuth Provider。

I am implementing an OAuth Provider using DevDefined library.

我想知道是否存在用于在服务器端存储使用者和令牌数据的推荐数据库结构。

I wonder if there is any recommended database structure for storing consumer and token data on the server side.

对此有任何建议。

推荐答案

NB ：以下答案主要适用于OAuth 1.0

我对DevDefined库一无所知。但这是我在最近的项目中使用SQL数据库进行的数据库设计的非技术性描述。

I don't really know anything about the DevDefined library. But here is a non-technical description of the database design I ended up working with in my latest project, using an SQL database.

它应涵盖遵循本文的所有内容。基本规格。我试图将其降低到绝对最小值。

It should cover everything needed to follow the basic specification. I've tried to keep it down to an absolute minimum.

RequestTokens

• 令牌（我在这里使用MD5，主键）


• consumerKey（消费者的唯一标识符）


• 秘密（SHA1）


• createTime（时间戳）


• 回调

• token (I use an MD5 here, primary key)
• consumerKey (the unique identifier for the consumer)
• secret (SHA1)
• createTime (timestamp)
• callback

AccessTokens

• 令牌（MD5，主键）


• 秘密（SHA1）


• consumerKey


• 用户ID（指资源所有者）


• createTime

• token (MD5, primary key)
• secret (SHA1)
• consumerKey
• userID (refers to the resource owner)
• createTime

消费者（已注册的第三方应用程序）

Consumers (registered third party applications)

• consumerKey（MD5，主键）


• consumerSecret（SHA1）


• userID（指注册了应用程序，不是唯一的）


• 说明（用于描述应用程序的文本）


• name（应用程序的名称）


• 回调

• consumerKey (MD5, primary key)
• consumerSecret (SHA1)
• userID (refers to the developer who registered the application, not unique)
• description (a text to describe the application)
• name (the name of the application)
• callback

UsedNonces

• nonce


• 时间戳

处理随机数对我来说确实是最大的设计问题。 OAuth告诉您永远不要再将同一随机数与同一时间戳一起使用。但这将建立一个无限大的数据库。我认为大多数提供程序至少每隔一段时间会批处理一次旧的随机数。

The handling of nonces was really the biggest design question for me. OAuth tells you to never allow the same nonce to be used with the same timestamp ever again. But that would make for an infinitely huge database. I think most providers batch away old nonces at least once in a while.

我通常会清除5分钟以上的随机数，前提是所有请求都带有时间戳记超过5分钟的内容将被拒绝。在检查时间戳时，我有点宽容，它们需要是UTC，并且不得早于5分钟，并且不能比我的服务器时间早1分钟以上。

I routinely clear away nonces older than 5 minutes, based on the premise that all requests with a timestamp older than 5 minutes are rejected. I am slightly forgiving when checking timestamps, they need to be UTC and either not older than 5 minutes, and not ahead of my server time more than one minute.

这篇关于OAuth Provider的推荐数据库结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！