细说API – 认证、授权和凭证
|
某些授权模式下 access token 需要暴露给浏览器，充当一个资源服务器和浏览器之间的临时会话，浏览器和资源服务器之间不存在签名机制，access token 成为唯一凭证，因此 access token 的过期时间(TTL)应该尽量短，从而避免用户的 access token 被嗅探攻击。 由于要求 access token 时间很短，refresh token 可以帮助用户维护一个较长时间的状态，避免频繁重新授权。大家会觉得让 access token 保持一个长的过期时间不就可以了吗?实际上 refresh token 和 access token 的不同之处在于即使 refresh token 被截获，系统依然是安全的，客户端拿着 refresh token 去获取 access token 时同时需要预先配置的 secure key，客户端和授权服务器之前始终存在安全的认证。 OAuth、Open ID、OpenID Connect 认证方面的术语实在太多，我在搭建自己的认证服务器或接入第三方认证平台时，有时候到完成开发工作的最后一刻都无法理解这些术语。 OAuth 负责解决分布式系统之间的授权问题，即使有时候客户端和资源服务器或者认证服务器存在同一台机器上。OAuth 没有解决认证的问题，但提供了良好的设计利于和现有的认证系统对接。 Open ID 解决的问题是分布式系统之间身份认证问题，使用Open ID token 能在多个系统之间验证用户，以及返回用户信息，可以独立使用，与 OAuth 没有关联。 OpenID Connect 解决的是在 OAuth 这套体系下的用户认证问题，实现的基本原理是将用户的认证信息(ID token)当做资源处理。在 OAuth 框架下完成授权后，再通过 access token 获取用户的身份。 这三个概念之间的关系有点难以理解，用现实场景来说，如果系统中需要一套独立的认证系统，并不需要多系统之间的授权可以直接采用 Open ID。如果使用了 OAuth 作为授权标准，可以再通过 OpenID Connect 来完成用户的认证。 JWT 在 OAuth 等分布式的认证、授权体系下，对凭证技术有了更多的要求，比如包含用户 ID、过期等信息，不需要再外部存储中关联。因此业界对 token 做了进一步优化，设计了一种自包含令牌，令牌签发后无需从服务器存储中检查是否合法，通过解析令牌就能获取令牌的过期、有效等信息，这就是JWT (JSON Web Token)。 JWT 是一种包含令牌(self-contained token)，或者叫值令牌 (value token)，我们以前使用关联到 session 上的 hash 值被叫做引用令牌(reference token)。 简而言之，一个基本的JWT令牌为一段点分3段式结构。 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ 生成JWT 令牌的流程为
因此只需要签名的 secret key 就能校验 JWT 令牌，如果在消息体中加入用户 ID、过期信息就可以实现验证令牌是否有效、过期了，无需从数据库/缓存中读取信息。因为使用了加密算法，所以第一、二部分即使被修改(包括过期信息)也无法通过验证。JWT 优点是不仅可以作为 token 使用，同时也可以承载一些必要信息，省去多次查询。 注意：
JWT token 在微服务的系统中优势特别突出。多层调用的 API 中可以直接传递 JWT token，利用自包含的能力，可以减少用户信息查询次数;更重要的是，使用非对称的加密方式可以通过在系统中分发密匙的方式验证 JWT token。 当然 OAuth 对 access token 等凭证所选用的技术并没有做出限制，OAuth 并不强制使用 JWT，在使用 JWT 自包含特性的优势时，必须考虑到 JWT 撤回困难的问题。在一些对撤回 token 要求很高的项目中不适合使用JWT，即使采用了一些方案实现(whitelist 和 blacklist)也违背了设计 JWT 的初衷。 Cookie 、Token in Cookie、Session Token 依然被使用 在构建 API 时，开发者会发现我们的认证方式和网页应用有一些不同，除了像 ajax 这种典型的 web 技术外，如果我们希望 API 是无状态的，不推荐使用 Cookie。 使用 Cookie 的本质是用户第一次访问时服务器会分配一个 Session ID，后面的请求中客户端都会带上这个 ID 作为当前用户的标志，因为 HTTP 本身是无状态的，Cookie 属于一种内建于浏览器中实现状态的方式。如果我们的 API 是用来给客户端使用的，强行要求 API 的调用者管理Cookie 也可以完成任务。 在一些遗留或者不是标准的认证实现的项目中，我们依然可以看到这些做法，快速地实现认证。 使用 cookie，例如 web 项目中 ajax 的方式 使用 session ID 或 hash 作为 token，但将 token 放入 header 中传递 将生成的 token (可能是JWT)放入 cookie 传递，利用 HTTPonly 和 Secure 标签保护 token 选择合适的认证方式 随着微服务的发展，API 的设计不仅仅是面向 WEB 或者 Mobile APP，还有BFF(Backend for Frontend)和 Domain API 的认证，以及第三方服务的集成。 客户端到服务器之间认证和服务器到服务器之间认证是不同的。 我们把终端用户(Human)参与的通信，叫做 Human-to-machine (H2M)，服务器与服务器之间的通信叫做 Machine-to-machine (M2M)。 H2M 的通信需要更高的安全性，M2M 的通信天然比 H2M 安全，因此更多的强调性能，在不同的场合下选择合适的认证技术就显得特别重要。例如 HTTP Basic Authentication 用来作为 H2M 认证显得有些落后，但是在 M2M 中被大量使用。 另外值得一提的是，H2M 这种通信方式下，客户端不受控制，由于无法自主分发密匙，认证通信的安全高度依赖 HTTPS。 （编辑：PHP编程网 - 襄阳站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
