细说API – 认证、授权和凭证
这种基于 AK/SK 的认证方式主要是利用散列的消息认证码 (Hash-based MessageAuthentication Code) 来实现的,因此有很多地方叫 HMAC 认证,实际上不是非常准确。HMAC 只是利用带有 key 值的哈希算法生成消息摘要,在设计 API 时有具体不同的实现。 HMAC 在作为网络通信的认证设计中作为凭证生成算法使用,避免了口令等敏感信息在网络中传输。基本过程如下:
为了让每一次请求的签名变得独一无二,从而实现重放攻击,我们需要在签名时放入一些干扰信息。 在业界标准中有两种典型的做法,质疑/应答算法(OCRA: OATH Challenge-Response Algorithm)、基于时间的一次性密码算法(TOTP:Time-based One-time Password Algorithm)。 质疑/应答算法 质疑/应答算法需要客户端先请求一次服务器,获得一个 401 未认证的返回,并得到一个随机字符串(nonce)。将 nonce 附加到按照上面说到的方法进行 HMAC 签名,服务器使用预先分配的 nonce 同样进行签名校验,这个 nonce 在服务器只会被使用一次,因此可以提供唯一的摘要。 基于时间的一次性密码认证 为了避免额外的请求来获取 nonce,还有一种算法是使用时间戳,并且通过同步时间的方式协商到一致,在一定的时间窗口内有效(1分钟左右)。 这里的只是利用时间戳作为验证的时间窗口,并不能严格的算作基于时间的一次性密码算法。标准的基于时间的一次性密码算法在两步验证中被大量使用,例如 Google 身份验证器不需要网络通信也能实现验证(但依赖准确的授时服务)。原理是客户端服务器共享密钥然后根据时间窗口能通过 HMAC 算法计算出一个相同的验证码。 TOTP 基本原理和常见厂商 OAuth2 和 Open ID OAuth(开放授权)是一个开放标准,允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息,而不需要将用户名和密码提供给第三方网站或分享他们数据的所有内容。 OAuth 是一个授权标准,而不是认证标准。提供资源的服务器不需要知道确切的用户身份(session),只需要验证授权服务器授予的权限(token)即可。 上图只是 OAuth 的一个简化流程,OAuth 的基本思路就是通过授权服务器获取 access token 和 refresh token(refresh token 用于重新刷新access token),然后通过 access token 从资源服务器获取数据 。在特定的场景下还有下面几种模式:
如果需要获取用户的认证信息,OAuth 本身没有定义这部分内容,如果需要识别用户信息,则需要借助另外的认证层,例如 OpenID Connect。 验证 access token 在一些介绍OAuth 的博客中很少讲到资源服务器是怎么验证 access token 的。OAuth core 标准并没有定义这部分,不过在 OAuth 其他标准文件中提到两种验证 access token的方式。 在完成授权流程后,资源服务器可以使用 OAuth 服务器提供的 Introspection 接口来验证access token,OAuth服务器会返回 access token 的状态以及过期时间。在OAuth标准中验证 token 的术语是 Introspection。同时也需要注意 access token 是用户和资源服务器之间的凭证,不是资源服务器和授权服务器之间的凭证。资源服务器和授权服务器之间应该使用额外的认证(例如 Basic 认证)。 使用 JWT 验证。授权服务器使用私钥签发 JWT 形式的 access token,资源服务器需要使用预先配置的公钥校验 JWT token,并得到 token 状态和一些被包含在 access token 中信息。因此在 JWT 的方案下,资源服务器和授权服务器不再需要通信,在一些场景下带来巨大的优势。同时 JWT 也有一些弱点,我会在JWT 的部分解释。 refresh token 和 access token 几乎所有人刚开始了解 OAuth 时都有一个一疑问,为什么已经有了 access token 还需要 refresh token 呢? (编辑:西安站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |