¶ 凭证管理
¶ 用户标识凭证（ID token）
通过 Guard 完成认证后，默认返回的 token 叫做 ID token，即 用户标识凭证。对用户信息的各种操作都需要校验 ID token。虽然业务后台也可以用 ID token 作为资源管理凭证，但更为普遍的做法是引入另外两个凭证：访问凭证（Access token） 和 刷新凭证（Refresh token）
¶ 访问凭证（Access token）
一般使用访问凭证来控制资源访问。
Access token 和 ID token 一样，一般都以 JWT 的形式出现，但其 encode 的内容有所不同。根据授权 scope，ID token 可以包含很多个人信息以及扩展信息。而 access token 只应该包含极少的关键信息，不应该包含任何个人信息。
另外，access token 的有效期一般都非常短，通常为数小时，敏感系统的有效期甚至只有数十分钟。这是因为从业务角度看，访问凭证和个人凭证确实应该有不同的有效期。对于业务操作，如转账，需要及时闭环。而更新个人头像却不用太着急。
实际上，我们甚至可以创造更多的凭证，每个凭证都有自己的业务含义，后台系统可以要求前端应用传入准确的凭证。只不过，对于大多数业务系统来说，统一的访问凭证就已经可以满足业务诉求了。
¶ 刷新凭证（Refresh token）
由于访问凭证时效性很短，一旦过期，就需要用户重新登录。这在一些场景下用户是可以接受的，如银行类 App，但大多数场景，这样的设计会严重影响用户体验。于是就有了 刷新凭证
当访问凭证过期后，App 可以通过刷新凭证来获取新的 用户标识凭证 和 访问凭证。
¶ 获取刷新凭证
根据 OIDC 协议规范，获取刷新凭证必须在授权请求的 scope 里面包含 offline_access。
若 App 通过 WebView 进行登录，推荐使用 Guard 提供的 WebView 来接入，请参考：WebView
Guard 默认的 scope 里面会包含 offline_access，同时在登录 URL 上会拼接：prompt=consent 因为我们认为获取刷新凭证是移动 App 的默认行为
若 App 通过原生方式进行认证，首先参考这里唤起认证界面： 托管页
然后将示例中的：
AuthFlow().start { [weak self] code, message, userInfo in
if code == 200 {
// userInfo 为用户信息
}
}
替换为：
Authing.start(<#Authing_APPID#>)
let flow = AuthFlow()
flow.authProtocol = .EOIDC
flow.start() { [weak self] code, message, userInfo in
if code == 200 {
// userInfo 为用户信息
}
}
在认证回调的 UserInfo 对象里面，可以通过下面代码获取 Refresh token：
let refreshToken = userInfo?.refreshToken
¶ 通过刷新凭证换取新的访问凭证和用户标识凭证
无论是采用 WebView 还是原生的方式，都可以通过以下 API 来刷新访问凭证和用户标识凭证