spring security实战 4-使用隐式模式(implicit grant type)保护资源

写在开篇

本改编课程基于《OAuth 2.0 Cookbook_Protect Your Web Applications using Spring Security-Packt Publishing(2017)》。这本书侧重经过一个个精简的小例子来学习，如何使用spring security和oauth2.0来保护你的资源，。

课程从第二章开始，在Chaptor2，咱们将学习如下内容：

1. 使用受权码模式(Authorization Code grant)保护资源

2. 支持隐式受权模式(Implicit grant)
3. 使用密码模式(Resource Owner Password Credentials grant type )
4. 配置客户端证书受权模式(Client Credentials grant)
5. 支持refresh tokens
6. 使用一个关系数据库来保存tokens和客户信息
7. 使用redis保存token
8. 实现客户端注册过程
9. 中途破坏Oauth 2.0 Provider
10. 使用Gatling,经过共享数据库测试token的验证过程

本节为隐式模式的用例，该模式直接运行在浏览器上（例如Javascript 应用）。本例将容许客户端以资源全部者的名义经过OAuth2.0保护的api。

Getting ready

Java 8+maven
源码可从如下连接获取https://github.com/PacktPubli...

How to do it…

接下来的步骤将指导你使用Spring Security OAuth2 搭建一个受权中心和一个资源服务器：

1.使用Spring Initializr 新建一个Springboot工程，加入web,security依赖，本例使用的springboot版本为“1.5.4.RELEASE”。

2.打开pom.xml，加入如下依赖：

<dependency>
 <groupId>org.springframework.security.oauth</groupId>
 <artifactId>spring-security-oauth2</artifactId> 
</dependency>

3.打开application.properties文件，输入：

security.user.name=adolfo
security.user.password=123

4.新建UserProfile类与UserController类，内容与《学习3》中一致，这个是获取资源的接口。

5.新建OAuth2ResourceServer类，内容与《学习3》中一致，这个是资源管理器配置。

6.新建OAuth2AuthorizationServer类，即配置受权中心，注意其中的不一样之处：

@Configuration
@EnableAuthorizationServer
public class OAuth2AuthorizationServer extends AuthorizationServerConfigurerAdapter{
  @Override
  public void configure(ClientDetailsServiceConfigurer clients)throws Exception{
    clients.inMemory()
      .withClient("clientapp")
      .secret("123456")
      .redirectUris("http://localhost:9000/callback")
      .authorizedGrantTypes("implicit")
      .accessTokenValiditySeconds(120)
      .scopes("read_profile","read_contacts");
    }
}

7.至此，咱们已经完成了全部步骤，能够看出，在spring security框架中，受权码模式和隐式模式的构建模式很类似，仅仅在于配置受权中心时，设置不一样的authorizedGrantTypes。

How it works…

当咱们使用@EnableAuthorizationServer 和@EnableResourceServer 这两个标签时，意味着，咱们将Oauth 2.0的 endpoint加入到咱们的项目中，与上一节的不一样之处在于，咱们使用了不一样的受权模式，所以验证流程有一点点不一样。此外，咱们还必须知道的是，咱们无需再往/oauth/token 发请求，由于咱们如今是隐式模式。

接下来，咱们来运行这个项目

1.首先，咱们往受权中心发送以下请求：

http://localhost:8080/oauth/authorize?client_id=clientapp&redirect_uri=http://localhost:9000/callback&response_type=token&scope=read_profile&state=xyz

注意，此时response_type 的参数值为token ，而不是以前的code。而且，咱们的url没有使用编码，此处是做为教学用例因此省略，但在实际生产项目中，请记住要对全部参数进行编码。

当请求到达受权中心的endPoint后，受权中心将会要求资源全部者作身份验证

输入用户名密码后，将会跳到受权页面：

2.选择所需的scope ,点击Authorize ，你将跳回到以前设置的redirect uri,正如你所见，回调路径携带了咱们须要的access token和以前输入的state

http://localhost:9000/callback#access_token=a68fce80-522f-43ee-85d4-6705c34 e555c&token_type=bearer&state=xyz&expires_in=119

除了access token和state，咱们还获得了两个参数：token_type和expires_in。在上一节，使用受权码模式时，也得到了这些返回参数。重要的是要记住，隐式受权类型不容许按照OAuth2规范发布刷新令牌（refresh token）。这种行为是有必要的，它要求在使用运行在浏览器中的程序时，用户必须在场，这样能够在任何须要的时候，给第三方应用受权。

除此以外，受权中心有充分的能力来识别用户的session，避免重复要求资源中心来对客户端进行验证和受权。

隐式模式不容许发布refresh token的另外一个理由是，隐式模式是应用在那些没法保护机密数据的公共应用，而这是refresh token要作的。

3.如今咱们能够从api/profile 这个endpoint取回用户资料了，就像咱们在上一节所作的，记住需携带access token，具体参见上一节。

There's more…

当使用隐式模式时，第三方应用始终须要经过重定向URI来注册，这样能确保不会将access token传给不须要验证的客户端。若是不这样作，一些心怀不轨的用户可能先注册一个应用，而后试图让其余的应用来顶替，接收这个access token，这样可能致使灾难性的结果。