oauth2身份验证数据blob持久性方法的正当性和缺点

时间:2015-07-24 13:58:42

标签: spring oauth spring-security

我打算使用“Spring Security OAuth”框架作为OAUTH2授权服务器的基础,该服务器具有访问令牌,刷新令牌和代码功能。

默认情况下,框架使用java序列化在数据库表oauth_code,oauth_access_token和oauth_refresh_token中存储其他身份验证数据(列'authentication')。

我想开始讨论,找出这种方法的优点和缺点,我很想知道是否有计划改变这种方法。

缺点:

  • 如果新版本无法反序列化先前版本的数据,则无法进行框架版本升级
  • 不需要的数据:blob可能包含根本不需要的数据(例如原始请求)
  • 敏感数据:blob可能包含敏感数据,如用户凭据
  • 数据冗余:对于上面列出的表格,数据存储了3次
  • 数据分析:无法通过纯SQL语句选择身份验证数据

的优点:

  • 扩展:数据可以在没有模式迁移的情况下以简单的方式扩展(很好地从头开始)

'blob'方法的替代方案:

  • 将身份验证数据存储在单独的表(例如oauth_authentication)中,其中包含实际需要的每条信息的数据列(例如用户ID,客户端ID,范围等)以及来自oauth_code,oauth_access_token和oauth_refresh_token的外键

替代方案的负面后果可能是什么?

非常感谢!

1 个答案:

答案 0 :(得分:1)

@Dennis:我完全同意你的看法。目前我正在经历这个blob持久性问题。由于Spring已升级安全版本,因此导致了许多问题。您的第一点:如果新版本无法对先前版本的数据进行反序列化,则无法进行框架版本升级。我认为这应该在OAuth2 Framework中优雅地处理。