Asp.net 的Security框架除了提供Cookies,OAuth,ActiveDirectory等多个用户认证实现，基本上已经满足业务项目的开发需要了。

当需要实现OAuth2.0服务器端实现的时候第一想法可能是使用IdentityServer3或者4，其实在Security框架中也提供了这样一个简易实现，可以满足我们的需求了，而且代码更加的简洁。在web项目中引入相关nuget包并运行起来，一台OAuth2.0 Server就跑起来了。

核心类就是OAuthAuthorizationServerHandler，总体设计思路就是在该类型中会先判定请求是希望获取AuthorizationCode（这里只讨论授权码模式）还是AccessToken从而执行不同的流程，如果是获取AccessToken的话会判定client_id和redirect_uri正确时候就会返回相应的结果。框架为我们提供了OAuthAuthorizationServerOptions选项参数来配置OAuth2.0.后面所有提到的Options都指该类型。

OAuth2.0在各种操作中会需要传递相应的参数，比如client_id,redirect_uri,response_type之类，框架为我们提供了AuthorizeEndpointRequest类型方便我们根据IOwinRequest提取保存在QueryString里的临时码接口参数，TokenEndpointRequest类型方便我们提取保存在请求Body里的AccessToken接口参数，一切都显得简洁紧凑，避免了一锅粥似得凌乱代码。

1.在请求到来的时候会首先判断请求是否希望获取AuthorizationCode或者AccessToken，如果都不是的话Request请求就不会执行OAuth2.0的代码逻辑。我们可以在OAuthAuthorizationServerOptions配置项的如下两个属性中设置相应的属性。同时框架也为我们提供了一个扩展--Options的MatchesTokenEndpoint来自定义逻辑判断当前请求是否符合OAuth2.0 api接口路径。（我们还可以配置是否只接受https安全连接）

2.如果判断是AuthorizationCode请求的话（默认就是/authorize请求路径），接着确定请求Uri为合法的请求路径，同样的Options参数中也可以设置一些自定义的验证代码，如果一切执行ok，此时我们就需要为Options的Provider属性的OnAuthorizeEndpoint提供如下的一个委托函数，如果我来实现这个OAuth2.0 Server的话，我会在下图的这个委托方法中生成一个随机的code字符串，连同请求Request的state参数（如果有的话）以QueryString参数的形式设置到redirect_uri上，并执行该redirect_uri。这样就能将临时code传递给Application 服务器了。Application服务器获取到该临时code连同其他OAuth2.0规范的参数就可以访问我们的OAuth2.0 Server的AccessToken请求接口了。该AccessToken的Api接口如步骤3。

3.AccessToken接口通常是Application Server在获取到临时Code，带上符合OAuth2.0规范的参数然后发起调用的。如果判断是AccessToken请求的话（默认就是/token请求路径），或许我们需要判定一下请求所携带的client_id和Client_secret是否正确，为了做到这一点，我们需要配置Options的Provider.OnValidateClientAuthentication来进行验证。

如果一切顺利，下面就要生成AccessToken了，框架中生成的AccessToken其实就一个身份信息AuthenticationTicket处理之后生成的一个字符串。如下图所示的Options.AuthorizationCodeProvider.ReceiveAsync(authorizationCodeContext)代码中产生

另外需要注意的是默认产生的AccessToken只有20分钟左右的有效期，这个有效期是必须存在的，我们可以通过配置Options.AccessTokenExpireTimeSpan来配置的长久一些，为了能刷新这个AccessToken必须在其过期之前调用刷新接口。

如果一切执行顺利将会返回如下所示的一个Json字符串

 （纯粹是为了下个月找工作而准备的一系列博文，每一篇都尽量精简，并非给初学者看的?）

Asp.net Security框架（2）