作者回复: user-agent一般指浏览器，client是客户应用，比方授权码模式中客户应用一般是一个服务器端应用（如java web app），资源拥有者通过这个应用(间接也通过浏览器)去访问他在其它服务器上的资源。简化模式中，客户应用常是住在浏览器中的JS单页面应用。建议细看前面课程oauth2最简向导

作者回复: refresh token主要用途是在授权码模式中，access token到期方便换新，否则要走一个完整oauth2授权码流程，它不是主要用来解决安全问题，安全由oauth2流程+规范本身部分解决。

作者回复: 你好，OAuth2授权码流程中，第一次(浏览器->oauth2服务器)传递redirect url是客户应用(client app)回调地址，oauth2服务器返回code时会通过重定向调用这个地址，相当于向客户应用传递code。第二次(客户应用->oauth2服务器)传递redirect url是给oauth2服务器进行校验用，确保过来请求token的是之前请求code的那个客户应用。第一次redirect url可选，因为向oauth2服务器注册客户应用时可以直接提供，也就是说oauth2服务器已经知道要重定向到哪里，参考https://stackoverflow.com/questions/47050255/when-oauth2-authoration-code-grant-flow-redirect-uri-parameter-is-really-option

作者回复: accesstoken过期时间一般在oauth2服务器上设置，在注册client的时候设。在授权码模式中，token一般不会流到用户流览器中，要存的话也是存web服务器上。在简化模式和单页应用中，accesstoken可存localstorage或cookie中，但仅限安全不严格场景。

作者回复: 你可以再看下rfc6749的官方文档，URI fragment里头就是access token，一般也不加密，用URI fragment而不是query string，是为安全，浏览器接收到授权服务器的重定向指令向Web-Host Client Resource所在服务器发起请求时，会剥离URI fragment（但浏览器会保留），这样access token就没机会通过网络被发到Web-Host Client Resource所在服务器上，这样更安全，当Web-Host Client Resource服务器上js脚本返回到浏览器，js脚本仍可解析出URI fragment中的access token，因为浏览器有保留

作者回复: https + 合理设置token过期时间，另外如果涉及交易，可以在交易发生时再加双因素(手机验证码)校验。 对于安全更严格的场景，也可以考虑更安全的Proof of Possession(PoP) token，它需要验证令牌拥有者身份，参考： https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08

作者回复: 对，如果没有采用网关集中令牌校验方式，那么可以让resource owner分别拿access token去认证服务器认证。如果用jwt自包含令牌的话，则可以实现resource owner自校验，不一定需要去认证服务器集中校验。

作者回复: 做好生产环境隔离的话，一般内部服务之间调用也不走oauth，可以直接调。安全要求严格时可以考虑采用客户端凭证模式(Client Credential Grant)。oauth主要场景是开放api第三方调用，无线或H5 app调用。

作者回复: 全流程的授权码flow最安全， 1）,第二步拿到auth code后，client需要提供client id/secret + authcode去换token，相当于授权服务器需要校验client是不是那个发起授权请求的client，因为第一步浏览器发起的授权请求是不提供client secret的。2)，token只在client端，不会流到user agent去，client secret也不能流到user agent去

作者回复: 认证鉴权是微服务重要环节，oauth2则是服务授权的业界标准协议。一般中大型的互联网公司都有独立的认证鉴权中心，大都支持oauth2协议。另外，后续企业的服务如果要开放出来(比如建开放平台)，一般都需要支持oauth2协议。 当然，对于一些小规模的企业场景，oauth2会显得比较重。如果暂时不感兴趣，可以先跳过第一章，等后面有需要再回头看。