OAuth Provider的推荐数据库结构是什么？ [英] what is the recommended database structure for OAuth Provider

问题描述

我正在使用DevDefined库实现OAuth提供程序。我想知道是否有任何推荐的数据库结构，用于在服务器端存储用户和令牌数据。请注意：以下答案主要适用于OAuth 1.0 >

我真的不了解DevDefined库的任何内容。但是这里是我最近在使用SQL数据库的最新项目中使用的数据库设计的非技术描述。

它应该涵盖所有需要遵循的一切基本规格。我试图保持最低限度。

RequestTokens

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


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


• 秘密（SHA1）


• createTime（timestamp）


• 回调

AccessTokens

• 令牌（MD5，主键）


• secret（SHA1）


• consumerKey


• userID（指资源所有者）


• createTime

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

• consumerKey（MD5，主键）


• consumerSecret（SHA1）


• userID（指开发者注册应用程序，不唯一）


• 描述（用于描述应用程序的文字）


• 名称（应用程序的名称）


• 回调

UsedNonces

• nonce


• timestamp

真是我最大的设计问题。 OAuth告诉您永远不要再使用相同的时间戳使用相同的随机数。但是这将使得无限巨大的数据库。我认为大多数提供商至少在一段时间内批量删除旧的随机数。

根据所有具有时间戳的请求的前提，我通常清除5分钟以内的随机数超过5分钟被拒绝。检查时间戳时，我稍微宽恕，他们需要是UTC，不要超过5分钟，而不是服务器时间超过一分钟。

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. Any advice on this would be appreciated!

解决方案

NB: The answer below is applicable mostly to OAuth 1.0

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

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

AccessTokens

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

Consumers (registered third party applications)

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

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.

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