OAuth Provider 的推荐数据库结构 [英] Recommended database structure for OAuth Provider
问题描述
我正在使用 DevDefined 库实现 OAuth 提供程序.
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.
推荐答案
注意:下面的答案主要适用于 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.
请求令牌
- 令牌(我在这里使用 MD5，主键)
- consumerKey(消费者的唯一标识符)
- 秘密 (SHA1)
- createTime(时间戳)
- 回调
访问令牌
- 令牌(MD5，主键)
- 秘密 (SHA1)
- 消费者密钥
- userID(指资源所有者)
- 创建时间
消费者(注册的第三方应用程序)
Consumers (registered third party applications)
- consumerKey(MD5，主键)
- 消费者秘密 (SHA1)
- userID(指注册应用的开发者，非唯一)
- 描述(描述应用程序的文本)
- 名称(应用程序的名称)
- 回调
使用的Nonce
- 随机数
- 时间戳
随机数的处理对我来说真的是最大的设计问题.OAuth 告诉您永远不要允许相同的随机数再次与相同的时间戳一起使用.但这将形成一个无限大的数据库.我认为大多数提供商至少偶尔会批量处理旧的 nonce.
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屋！
