单点登录-OAuth2

单点登录的实现原理

单点登录在现在的系统架构中广泛存在，他将多个子系统的认证体系打通，实现了一个入口多处使用，而在架构单点登录时，也会遇到一些小问题，在不同的应用环境中可以采用不同的单点登录实现方案来满足需求。 我将以我所遇到的应用环境以及在其中所经历的各个阶段与大家分享，若有不足，希望各位不吝赐教。

一、共享Session

共享Session可谓是实现单点登录最直接、最简单的方式。将用户认证信息保存于Session中，即以Session内存储的值为用户凭证，这在单个站点内使用是很正常也很容易实现的，而在用户验证、用户信息管理与业务应用分离的场景下即会遇到单点登录的问题，在应用体系简单，子系统很少的情况下，可以考虑采用Session共享的方法来处理这个问题。

　　这个架构我使用了基于Redis的Session共享方案。 将Session存储于Redis上，然后将整个系统的全局Cookie Domain设置于顶级域名上，这样SessionID就能在各个子系统间共享。

　　这个方案存在着严重的扩展性问题，首先，ASP.NET的Session存储必须为SessionStateItemCollection对象，而存储的结构是经过序列化后经过加密存储的。 并且当用户访问应用时，他首先做的就是将存储容器里的所有内容全部取出，并且反序列化为SessionStateItemCollection对象。 这就决定了他具有以下约束：

　 　1、 Session中所涉及的类型必须是子系统中共同拥有的（即程序集、类型都需要一致），这导致Session的使用受到诸多限制；

　　2、 跨顶级域名的情况完全无法处理；

二、基于OpenId的单点登录

　　这种单点登录将用户的身份标识信息简化为OpenId存放于客户端，当用户登录某个子系统时，将OpenId传送到服务端，服务端根据OpenId构造用户验证信息，多用于C/S与B/S相结合的系统，流程如下：

　　由上图可以看到，这套单点登录依赖于OpenId的传递，其验证的基础在于OpenId的存储以及发送。

　　　1、当用户第一次登录时，将用户名密码发送给验证服务；

　　　2、验证服务将用户标识OpenId返回到客户端；

　　   3、客户端进行存储；

　　　4、访问子系统时，将OpenId发送到子系统；

　　　5、子系统将OpenId转发到验证服务；

　　　6、验证服务将用户认证信息返回给子系统；

　　　7、子系统构建用户验证信息后将授权后的内容返回给客户端。

　　这套单点登录验证机制的主要问题在于他基于C/S架构下将用户的OpenId存储于客户端，在子系统之间发送OpenId，而B/S模式下要做到这一点就显得较为困难。为了处理这个问题我们将引出下一种方式，这种方式将解决B/S模式下的OpenId的存储、传递问题。

三、基于Cookie的OpenId存储方案

　　我们知道，Cookie的作用在于充当一个信息载体在Server端和Browser端进行信息传递，而Cookie一般是以域名为分割的，例如a.xxx.com与b.xxx.com的Cookie是不能互相访问的，但是子域名是可以访问上级域名的Cookie的。即a.xxx.com和b.xxx.com是可以访问xxx.com下的Cookie的，于是就能将顶级域名的Cookie作为OpenId的载体。

　　

　　验证步骤和上第二个方法非常相似：

　　1、 在提供验证服务的站点里登录；

　　2、 将OpenId写入顶级域名Cookie里；

　　3、 访问子系统（Cookie里带有OpenId）

　　4、 子系统取出OpenId通过并向验证服务发送OpenId

　　5、 返回用户认证信息

　　6、 返回授权后的内容

　　在以上两种方法中我们都可以看到通过OpenId解耦了Session共享方案中的类型等问题，并且构造用户验证信息将更灵活，子系统间的验证是相互独立的，但是在第三种方案里，我们基于所有子系统都是同一个顶级域名的假设，而在实际生产环境里有多个域名是很正常的事情，那么就不得不考虑跨域问题究竟如何解决。

四、B/S多域名环境下的单点登录处理

　　　在多个顶级域名的情况下，我们将无法让各个子系统的OpenId共享。 处理B/S环境下的跨域问题，我们首先就应该想到JSONP的方案。

　　验证步骤如下：

　　1、 用户通过登录子系统进行用户登录；

　　2、 用户登录子系统记录了用户的登录状态、OpenId等信息；

　　3、 用户使用业务子系统；

　　4、 若用户未登录业务子系统则将用户跳转至用户登录子系统；

　　5、 用户子系统通过JSONP接口将用户OpenId传给业务子系统；

　　6、 业务子系统通过OpenId调用验证服务；

　　7、 验证服务返回认证信息、业务子系统构造用户登录凭证； （此时用户客户端已经与子业务系统的验证信息已经一一对应）

　　8、 将用户登录结果返回用户登录子系统，若成功登录则将用户跳转回业务子系统；

　　9、 将授权后的内容返回客户端；

五、安全问题

　　经过以上步骤，跨域情况下的单点登录问题已经可以得到解决。 而在整个开发过程初期，我们采用用户表中纪录一个OpenId字段来保存用户OpenId，而这个机制下很明显存在一些安全性、扩展性问题。 这个扩展性问题主要体现在一个方面： OpenId的安全性和用户体验的矛盾。

　　整个单点登录的机制决定了OpenId是会出现在客户端的，所以OpenId需要有过期机制，假如用户在一个终端登录的话可以选择在用户每次登录或者每次退出时刷新OpenId，而在多终端登录的情况下就会出现矛盾： 当一个终端刷新了OpenId之后其他终端将无法正常授权。 而最终，我采用了单用户多OpenId的解决方案。 每次用户通过用户名/密码登录时，产生一个OpenId保存在Redis里，并且设定过期时间，这样多个终端登录就会有多个OpenId与之对应，不再会存在一个OpenId失效所有终端验证都失效的情况。

 

单点登录是多域名企业站点流行的登录方式。本文以现实生活场景辅助理解，力争彻底理清 OAuth2.0 实现单点登录的原理流程。同时总结了权限控制的实现方案，及其在微服务架构中的应用。

1 什么是单点登录

1.1 多点登录

传统的多点登录系统中，每个站点都实现了本站专用的帐号数据库和登录模块。各站点的登录状态相互不认可，各站点需要逐一手工登录。如下图，有两个术语含义如下：

• 认证(authentication): 验证用户的身份；

• 授权(authorization): 验证用户的访问权限。

1.2 单点登录

单点登录，英文是 Single Sign On，缩写为 SSO。多个站点(192.168.1.20X)共用一台认证授权服务器(192.168.1.110，用户数据库和认证授权模块共用)。用户经由其中任何一个站点(比如 192.168.1.201)登录后，可以免登录访问其他所有站点。而且，各站点间可以通过该登录状态直接交互。

2 OAuth2 认证授权的原理流程

2.1 生活实例【★★重点★★】

为了直观的理解 OAuth2.0 原理流程，我们假设这样一个生活场景：

(1)档案局A(客户端 / Client)：以“档案局ID/密码”标识，是掌握档案资源的机构。并列还有很多档案局B/C/…，每个档案局存储的档案内容(资源 / Resource)不一样，比如政治、经济、军事、文化等；

(2)公民张三(资源所有者 / Resource Owner)：以“用户名/密码”标识，需要到各个档案局查档案；

(3)派出所(授权服务器 / Authentication Server)：可以是单个巨大的派出所，也可以是数据共享的派出所集群，掌管的信息、提供的对外接口功能有：

• 档案局信息：所有档案局的“档案局ID/密码”，证明档案局的身份；

• 公民信息：所有公民的“用户名/密码”，能提供张三是张三的用户身份证明(认证 / Authentication)

• 公民对于档案局的权限：有张公民和档案局的权限的映射表，可查得各公民对各档案局是否有操作权限(授权 / Authorization)。通常，设计中会增加官职(角色 / Role)一层，各公民属于哪个官职(角色)，哪个官职(角色)对于特定档案局有操作权限。

2.1.1 张三首次访问档案局A

张三之前从未到访档案局，第一次来档案局。对照下图序号理解：

(1)张三来到“档案局A”的“档案处”，该处要求实名登记后才能查询，被指示到“用户登记处”办理(HTTP重定向)；

(2)张三来到“档案局A”的“用户登记处”，既不能证明身份(认证)，又不能证明自己有查档案A的权限(授权)。张三携带档案局A的标识(client-id)，被重定向至“授权信开具处”；

(3)张三来到“派出所”的“授权信开具处”，出示档案局A的标识，希望开具授权信(授权)。该处要求首先证明身份(认证)，被重定向至“用户身份验证处”；

(4)张三来到“派出所”的“用户身份验证处”，领取了用户身份表(网页登录表单 Form)；

(5)张三填上自己的用户名和密码，交给(提交 / Submit)“用户身份验证处”，该处从私用数据库中查得用户名密码匹配，确定此人是张三，开具身份证明信，完成 认证。张三带上身份证明信和档案局A的标识，被重定向至“授权信开具处”；

(6)张三再次来到“授权信开具处”，出示身份证明信和档案局A的标识，该处从私用数据库中查得，张三的官职是市长级别(角色)，该官职具有档案局A的查询权限，就开具“允许张三查询档案局A”的授权信(授权码 / code)，张三带上授权信被重定向至“档案局”的“用户登录处”；

(7)张三到了“档案局”的“用户登录处”，该处私下拿出档案局A的标识(client-id)和密码，再附上张三出示的授权信(code)，向“派出所”的“腰牌发放处”为张三申请的“腰牌”(token)，将来张三可以带着这个腰牌表明身份和权限。又被重定向到“档案处”；

(8)张三的会话(Session)已经关联上了腰牌(token)，可以直接通过“档案处”查档案。

2.1.2 张三首次访问档案局B

张三已经成功访问了档案局A，现在他要访问档案局B。对照下图序号理解：

(1)/(2) 同上；

(3)张三已经有“身份证明信”，直接在“派出所”的“授权信开具处”成功开具“访问档案局B”的授权信；

(4)/(5)/(6) 免了；

(7)“档案局B”的“用户登记处”完成登记；

(8)“档案局B”的“档案处”查得档案。

2.1.3 张三再次访问档案局A

张三已经成功访问了档案局A，现在他要访问档案局A。对照下图序号理解：

(1)直接成功查到了档案；

(2~8)都免了。

2.2 HTTP 重定向原理

HTTP 协议中，浏览器的 REQUEST 发给服务器之后，服务器如果发现该业务不属于自己管辖，会把你支派到自身服务器或其他服务器(host)的某个接口(uri)。正如我们去政府部门办事，每到一个窗口，工作人员会说“你带上材料A，到本所的X窗口，或者其他Y所的Z窗口”进行下一个手续。

2.3 SSO 工作流程

至此，就不难理解 OAuth 2.0 的认证/授权流程，此处不再赘述。请拿下图对照“2.1 生活实例”一节来理解。

2.4 OAuth2.0 进阶

• https://tools.ietf.org/html/rfc6749

• https://tools.ietf.org/html/rfc6750

• https://blog.csdn.net/seccloud/article/details/8192707

根据官方标准，OAuth 2.0 共用四种授权模式：

• Authorization Code: 用在服务端应用之间，这种最复杂，也是本文采用的模式；

• Implicit: 用在移动app或者web app(这些app是在用户的设备上的，如在手机上调起微信来进行认证授权)

• Resource Owner Password Credentials(password): 应用直接都是受信任的(都是由一家公司开发的，本例子使用)

• Client Credentials: 用在应用API访问。

3 基于 SpringBoot 实现认证/授权

3.1 授权服务器(Authorization Server)

(1) pom.xml

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-oauth2</artifactId>
</dependency>

(2) application.properties

server.port=8110 ## 监听端口

(3) AuthorizationServerApplication.java

(4) 配置授权服务的参数

@EnableResourceServer // 启用资源服务器
public class AuthorizationServerApplication {
// ...
}

@Configuration
@EnableAuthorizationServer
public class Oauth2AuthorizationServerConfigurer extends AuthorizationServerConfigurerAdapter {
    @Override
    public void configure(final ClientDetailsServiceConfigurer clients) throws Exception {
        clients.inMemory()
                .withClient("webapp").secret("secret") //客户端 id/secret
                .authorizedGrantTypes("authorization code") //授权妈模式
                .scopes("user_info")
                .autoApprove(true) //自动审批
                .accessTokenValiditySeconds(3600); //有效期1hour
    }
}

@Configuration
public class Oauth2WebSecurityConfigurer extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.requestMatchers()
                .antMatchers("/login", "/oauth/authorize/oauth/logout")
                .and().authorizeRequests().anyRequest().authenticated()
                .and().formLogin().permitAll();
    }

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.inMemoryAuthentication().withUser("admin").password("admin123").roles("ADMIN");
    }
 }

3.2 客户端(Client, 业务网站)

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-oauth2</artifactId>
</dependency>

　　

(1) pom.xml

(2) application.properties

server port=8080
security.oauth2.client.client-id=webapp
security.oauth2.client.client-secret=secret
security.oauth2.client.access-token-uri=http://localhost:8110/oauth/token
security.oauth2.client.user-authorization-uri=http://localhost:8110/oauth/authorize
security.oauth2.resource.user-info-uri=http://localhost:8110/oauth/user

(3) 配置 WEB 安全

@Configuration
@EnableOAuth2Sso
public class Oauth2WebsecurityConfigurer extends WebSecurityConfigurerAdapter {
    @Override
    public void configure(HttpSecurity http) throws Exception {
        http.antMatcher("/**").authorizeRequests()
                .antMatchers("/", "/login").permitAll()
                .anyRequest().authenticated();
    }
}

@RestController
public class Oauth2ClientController {
    @GetMapping("/")
    public ModelAndView index() {
        return new ModelAndView("index");
    }

    @GetMapping("/welcome")
    public ModelAndView welcome() {
        return new ModelAndView("welcome");
    }
}

3.3 用户权限控制(基于角色)

• 授权服务器中，定义各用户拥有的角色: user=USER, admin=ADMIN/USER, root=ROOT/ADMIN/USER

• 业务网站中(client)，注解标明哪些角色可

@RestController
public class Oauth2ClientController {
    @GetMapping("/welcome")
    public ModelAndView welcome() {
        return new ModelAndView("welcome");
    }

    @GetMapping("/api/user")
    @PreAuthorize("hasAuthority('USER')")
    public Map<String, Object> apiUser() {
    }

    @GetMapping("/api/admin")
    @PreAuthorize("hasAuthority('ADMIN')")
    public Map<String, Object> apiAdmin() {
    }

    @GetMapping("/api/root")
    @PreAuthorize("hasAuthority('ROOT')")
    public Map<String, Object> apiRoot() {
    }
}

4 综合运用

4.1 权限控制方案

下图是基本的认证/授权控制方案，主要设计了认证授权服务器上相关数据表的基本定义。可对照本文“2.1 生活实例”一节来理解。

4.2 在微服务架构中的应用

与常规服务架构不同，在微服务架构中，Authorization Server/Resource Server 是作为微服务存在的，用户的登录可以通过API网关一次性完成，无需与无法跳转至内网的 Authorization Server 来完成。