Oauth2的理解

具体可以参考网站：

Authorization Code Flow

里边介绍的非常详细。

个人理解：

1. Oauth2支持多种授权流程，其中的一种是Authorization code Flow，具体见图：

 

2. Oauth2 的参与方，以及什么时候Client与Resource Owner是同一个对象。

具体说一下Resource Server，一直以为Resource Server是那种第三方提供的，可以用于下载用户头像等基础信息的，实际上远不止于此。如果我们开发自己的API应用的话。但是对于前后端分离的项目，前端是SPA或手机应用，后端是用java或者其他语言开发的API服务，这是，API服务就属于Resource Server。我们在Resource Server上不需要提供login接口，login操作是在前端做的，前端直接访问Authorization server完成注册、登陆操作，同时从前端获取access token。然后前端拿着access token就可以访问我们的API application的end points了。我们API application收到前端发过来的携带者access token（JWT）的请求，只需要验证该token的签名部分是正确的，就可以认为该用户是在第三方（Authorization Server）登陆过的，然后进行下一步操作，比如放行，或者进一步检查token中的claim中的scope是否包含了访问该API所需要的权限信息等。

如果系统是这种前后端分离的架构，因为SPA和手机应用都是对外暴露的（手机应用可以被反编译），所以相比较于传统的web applicaiton（运行于server end），不适合保存Authorization server分配给该Client的secret，因为很容易暴露。这时可以采用Authorization Code Flow with Proof Key for Code Exchange (PKCE)认证流程。

但是上边的auth0.com网站在后边的Architecture Senarios中，给出的推荐解决方案却是使用Implitcit Flow的Oauth2授权流程。

Solution Overview (SPAs + API)

 

当然，以上这些只是auth0.com给出的解决方案，虽然他严格遵循了相关Oauth2相关的RFC标准，相信在具体实现时，其他厂家还有其他的解决方案，流程可能会有较大差异。

写在最后：

Oauth2与OIDC的区别与联系：

OIDC基于Oauth2, OIDC关注于用户认证，比如你自己开发的应用没有认证模块，而是依赖于公共的可信第三方完成用户登陆认证，这个是OIDC关注的。而Oauth2更关注于用户授权。就是你的应用将用户重定向到第三方网站时，用户完成了登陆，这时，一般第三方平台会提示是否允许你的应用访问用户在第三方平台的头像等信息，然后用户可以选择允许还是不允许，这个授权的过程是Oauth2关注的。当然这些第三方平台充当了Authorization server（甚至resource server）的功能，但是这些Authorization server也可以由你自己的组织来搭建，而不是依赖于外部平台。