类型初始值设定项引发异常的解决方案 _shfongfeng的专栏-CSDN博客_类型初始值设定项引发异常

mikel阅读(6253)

来源: 类型初始值设定项引发异常的解决方案 _shfongfeng的专栏-CSDN博客_类型初始值设定项引发异常

 

上午打开VS编译程序的时候,突然出现了这个运行时错误“类型初始值设定项引发异常”。昨天还没有这个错误呢,今天就突然出现,搞得我一头雾水。上网搜了一下,发现有很多人遇到了这个问题。经过一番折腾解决了这个问题后,发现很多人都没有意识到其症结所在,于是写这个随笔,给大家点启发,也给自己做个备忘。

      症状描述:
我的程序需要连接一台MQ服务器(其实就是个台式机,每天下班关机),如果服务器没有开,程序就会抛出异常。以前编译时老是忘开服务器,经常会出现MQ访问失败的异常。这次我原本以为也是这个异常,没想到出来的是“类型初始值设定项引发异常”。
今天的错误为什么会和以往不一样呢?昨天临下班时,把一个类的单件模式做了重构,使用了静态初始化方法。代码如下:

private static readonly WorkerManager instance = new WorkerManager();
static WorkerManager() { }
private WorkerManager()
{
Initialize();
}
public static WorkerManager Instance
{
get

{ return instance; }
}

访问MQ的语句在Initialize方法里,问题就应该出现在这里了。
      解决方法:
当然,把MQ服务器打开问题就解决了,但是究竟为什么会出现“类型初始值设定项引发异常”呢?原来类的静态成员在初始化时如果出现异常,访问类的其它静态成员或对该类进行初始化都会抛出这个异常。请看下面的代码:

 public class Test
{
public static Foo Test1 = new Foo();
public static string Test2 = “Test2”;
public string Test3 = “Test3”;
public Test() { }
}

 public class Foo
{
public Foo()
{
throw new Exception();
}
}

在访问Test.Test2以及new Test()时都会抛出这个异常。我的代码中,由于Initialize()出现异常,instance实例化失败,所以访问Instance时就抛出了这个异常。
      总结:

TypeInitializationExeption在MSND中的描述为:当类初始值设定项不能初始化类型时,将创建 TypeInitializationException 并向其传递由该类型的类初始值设定项引发的异常引用。

我们知道,类型初始化或者访问类型的静态成员时,都会对类中的其他静态成员进行初始化,并执行静态构造函数(如果有的话)。在这些过程中如果任一环节出现例如下面的代码:

class ClassHelper

{

public static string Field = Do(“Initial the static field”);
public static string StaticString = “Initaial static string”;
public string NonStaticString = “Initial non static string”;
public ClassHelper()
{
NonStaticString = “Change non static string in instance constructor”;
StaticString = “Change static string in instance constructor”;
}
public static string Do(string field)
{
Console.WriteLine(field);
throw new Exception();
return field;
}

}

那么产生TypeInitializationException的情况就包含以下几种:

1. 访问类的某一静态成员,而其他静态成员的初始化(或静态构造函数中)产生异常。例如访问ClassHelper.StaticString,由于静态成员Field的初始化产生异常,因此调用ClassHelper.StaticString会抛出TypeInitializationException。

2. 访问类的某一静态成员,该静态成员的初始化(或静态构造函数中)产生异常。例如访问ClassHelper.Field。

3. 对该类进行初始化,而类中的某个静态成员初始化(或静态构造函数中)产生异常。例如ClassHelper helper = new ClassHelper()。

byte[] to int64_new_smile的专栏-CSDN博客

mikel阅读(756)

来源: byte[] to int64_new_smile的专栏-CSDN博客

private Int64 BytesToInt64 (byte[] sourceBytes)

{

if (null==sourceBytes)

{

throw new ArgumentNullException();

}

Int64 temp = new Int64();

byte tempByte;

for (int i = 0; i < 8; i++)

{

tempByte = sourceBytes[i];

temp += (tempByte & 0xFFFFFFFFFFFF) << (8 * i);

}

return temp;

}

字节数组转换为int64,
————————————————
版权声明:本文为CSDN博主「new_smile」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/new_smile/article/details/19194505

SQL Server 跨网段(跨机房)复制 - 听风吹雨 - 博客园

mikel阅读(720)

来源: SQL Server 跨网段(跨机房)复制 – 听风吹雨 – 博客园

一.本文所涉及的内容(Contents)

  1. 本文所涉及的内容(Contents)
  2. 背景(Contexts)
  3. 解决方案(Solution)
  4. 搭建过程(Process)
  5. 注意事项(Attention)
  6. 参考文献(References)

二.背景(Contexts)

搭建SQL Server复制的时候,如果网络环境是局域网内,通过主机名就可以实现了,但是如果是跨网段、跨机房异地搭建复制的时候就需要注意了,因为SQL Server复制不支持通过IP连接分发服务器,那有什么办法解决跨网段、跨机房的问题呢?

三.解决方案(Solution)

在跨网段、跨机房进行SQL Server复制的时候需要区分两种情况:一种是外网IP的1433端口对应了这台机器SQL Server的数据库端口;另外一种情况是外网IP对应SQLServer机器的端口不是1433;下面是几种解决方案:

A. 如果外网IP端口是1433,可以在Windows的host文件中指定IP地址与主机名的对应关系,主机名必须跟真实的主机名一样?

B. 因为你的外网IP端口不是1433,所以你无法在host文件中跟IP地址一起指定端口;这种情况下,如果条件允许(安全性和端口数),你可以在防火墙中开放外网IP的1433端口对应这个发布服务器的1433端口,并且限制某个IP可以访问这个端口,程序等访问发布数据库就使用另外的21433端口,保证了1433端口的安全;又可以解决端口映射问题,可以画张图解释;

wps_clip_image-16794

(Figure1:逻辑结构图)

C. 另外一种方案是在SQL Server配置管理器里建立一个SQL Server别名,这个别名需要跟主机名一样,不需要启用SQL Server Browser服务;

四.搭建过程(Process)

(一) 环境信息

系统环境:Windows Server 2008 + SQL Server 2008

发布服务器:192.168.1.101,1924,192.168.1.101,1433,服务器名称:USER-H2B2A89PEK

分发服务器:与发布服务器同一台机器

订阅服务器:192.168.1.102,1433,服务器名称:QuZhoushiwei105

发布数据库:Task

订阅数据库:TaskSubscribe

数据库帐号:ReplicationUser/ ReplicationPassword

 

(二) 搭建步骤

上面的发布服务器的外网IP开通了两个端口,一个是默认的1433,一个是1924,如果是默认的1433,可以通过host文件,而如果只有端口1924的话就只能通过SQL Server别名方式实现,这里为了做测试就一起开通了这2个端口了。

A. 下面是通过host文件的形式创建订阅的具体步骤:

1) 在发布服务器上创建发布,具体操作可以参考:SQL Server 复制事务发布,只有搭建成功之后下面的步骤才能进行;

2) 设置订阅服务器C:\Windows\System32\drivers\etc目录的host文件,添加分发服务器(我的环境是发布服务器与分发服务器是一起的,所以这里指定的是发布服务器的地址)信息:192.168.1.101 USER-H2B2A89PEK

3) 设置分发服务器C:\Windows\System32\drivers\etc目录的host文件,添加订阅服务器信息:192.168.1.102 QuZhoushiwei105

4) 在订阅服务器上创建订阅,具体步骤如下:

wps_clip_image-17997

(Figure2:连接发布服务器)

wps_clip_image-22114

(Figure3:成功连接发布服务器)

wps_clip_image-18311

(Figure4:选择推送订阅)

wps_clip_image-23578

(Figure5:选择订阅数据库)

wps_clip_image-16849

(Figure6:推送订阅帐号密码)

wps_clip_image-21517

(Figure7:代理计划)

wps_clip_image-2598

(Figure8:初始化)

wps_clip_image-15522

(Figure9:成功后的订阅信息与作业)

wps_clip_image-5443

(Figure10:新建订阅的状态信息)

 

B. 下面是通过SQL Server别名的形式创建订阅的具体步骤:

1) 在发布服务器上创建发布,具体操作可以参考:SQL Server 复制事务发布,只有搭建成功之后下面的步骤才能进行;

2) 在订阅服务器上创建分发服务器(我的环境是发布服务器与分发服务器是一起的,所以这里指定的是发布服务器的地址)的别名;

wps_clip_image-12241

(Figure11:订阅服务器上的别名)

在分发服务器上,如果别名的设置包括:SQL Native Client 10.0 配置(32位)和SQL Native Client 10.0 配置,需要都设置订阅服务器的别名,如果没有像Figure13那样进行设置,

wps_clip_image-21703

(Figure12:分发服务器上的别名)

wps_clip_image-8754

(Figure13:分发服务器上的别名)

3) 接下来的步骤按照Figure2到Figure8进行就可以了,同样,最后一样可以达到Figure9、Figure10的效果;

五.注意事项(Attention)

1. 使用请求订阅,分发作业是在订阅服务器上创建的;使用推送订阅,分发作业是在分发服务器上创建;

2. 在发布服务器上创建发布的时候,如果SQL Server数据库实例名与服务器名不一致,将会出现下面的错误:

wps_clip_image-30328

(Figure14:发布错误)

在订阅服务器上创建订阅的时候,如果SQL Server数据库实例名与服务器名不一致,将会出现下面的错误:

wps_clip_image-12226

(Figure15:订阅错误)

3. 可以通过下面的SQL脚本修改不一致的问题,修改之后记得重启SQL Server服务才能生效;

复制代码
/*
SQL Server数据库实例名与服务器名不一致的解决办法
*/
IF SERVERPROPERTY('SERVERNAME')<>@@SERVERNAME  
BEGIN
    DECLARE @server SYSNAME
    SET @server=@@SERVERNAME
    EXEC sp_dropserver @server=@server  
    SET @server=CAST(SERVERPROPERTY('SERVERNAME') AS SYSNAME)
    EXEC sp_addserver @server=@server,@local='LOCAL'
END
复制代码

4. 分发服务器上的快照文件会给删除?

CareySon:After the snapshot is applied at all Subscribers, replication cleanup deletes the associated .bcp file for the initial snapshots automatically.

5. 如果通过修改host文件部署发布订阅,你必须使用推送订阅模式,如果你使用请求订阅模式,因为你无法读取快照文件,将会报下面的错误:

wps_clip_image-24196

(Figure16:请求订阅无法读取快照文件错误信息)

使用别名的形式部署发布订阅,同样会存在相同的问题,CareySon在Azure上通过开通相关权限的方式可以使用请求订阅方式,但是过程比较复杂,这里就不做讨论了;

6. 如果只在订阅服务器的host文件上指定了分发服务器(这里指定是发布服务器,因为我的发布服务器与分发服务器是一起的),没有在分发服务器的host文件上指定订阅服务器地址,将会发生下面的错误:

wps_clip_image-2957

(Figure17:发布服务器连接不上订阅服务器)

7. 如果服务器同时存在“SQL Native Client 10.0 配置(32位)”和“SQL Native Client 10.0 配置”,测试发现“SQL Native Client 10.0 配置(32位)”设置的别名是提供给:查找SQL Server发布服务器使用的,错误信息类似Figure19所示;“SQL Native Client 10.0 配置”设置的别名是提供给:分发服务器作业推送到订阅服务器使用的,错误信息类似Figure17所示;具体原因不清楚,求科普;

wps_clip_image-15608

(Figure18:别名)

8. 在分发服务器和订阅服务器上设置别名的时候,别名应该跟服务器的实例名要一致,不然会报下面的错误:

wps_clip_image-4568

(Figure19:错误信息)

六.参考文献(References)

SqlServer数据库同步方案详解(包括跨网段)

sqlserver读写分离--事务发布_GM的博客-CSDN博客_sqlserver 读写分离

mikel阅读(576)

来源: sqlserver读写分离–事务发布_GM的博客-CSDN博客_sqlserver 读写分离

一、背景

在复制的运用场景中,事务发布是使用最为广泛的,我遇到这样一个场景:在YangJiaLeClub数据库中有表、存储过程、视图、用户定义函数,需要提供给其它程序读取放入缓存,程序需要比较及时的获取到这些数据,需要从权限和性能控制的角度出发,我采用了SQL Server的事务复制技术和timestamp,下面只讲述事务复制的搭建过程;

 

二、实现过程

(一) 环境信息

操作系统 IP 服务器名称 数据库版本 数据库名称 数据库帐号信息
发布服务器 Windows 10 企业版 192.168.2.100 DESKTOP-SDIK64J SQL Server 2008 R2 YangJiaLeClub sa/bwl

reg/bwl

分发服务器 与发布服务器同一台机器
订阅服务器1 Windows Server 2008r2 Enterprise 192.168.2.117 Win-DB-Slave1 SQL Server 2008 R2 YangJiaLeClub sa/bwl
订阅服务器2 Windows Server 2008r2 Enterprise 192.168.2.118 Win-DB-Slave2 SQL Server 2008 R2 YangJiaLeClub sa/bwl

1.发布服务器:

1.1 在防火墙中设置入栈规则,开放1433和1434端口

 

2.订阅服务器:

2.1.Sql Native Client 10配置(32位)新建别名:

 

2.Host 服务器名与IP映射(由于发布订阅服务器名称必须是:服务器+“\”+实例名访问)

目录: C:\Windows\System32\drivers\etc

3.控制面板\用户帐户\凭据管理器

创建凭据

 

 

(二) 搭建步骤

A. 发布服务器配置

首先在发布数据库和订阅数据库上创建相同的帐号和密码(reg/bwl),并且设置YangJiaLeClub数据库的安全对象,设置这样的帐号的目的就是为了和程序连接到数据库的帐号区分开,可以做权限上的控制,方便问题的排查;

–更改安全对象的所有权

ALTER AUTHORIZATION ON DATABASE::[YangJiaLeClub] TO [reg]

在F盘目录下创建文件夹:F:\DB\Net\ReplData,并设置这个文件夹为共享目录,共享用户为biwl

 

(Figure1_1:文件夹权限)

这里需要设置SQL Server Agent登陆帐号为上面文件夹访问用户biwl(发布服务器和订阅服务器都需要建立biwl相同帐号和密码设置SQLServer代理服务)

 

(Figure1_2:SQL Server Agent登陆帐号)

 

(Figure2:配置分发-分发服务器)

如果你设置快照文件夹路径为:F:\DB\Net\ReplData,即使你的发布服务器本身就是分发服务器,如果订阅服务器是另外一台机器,那么在请求(Pull)订阅(如果是推送(Push)订阅就没有这个限制)模式下订阅代理是无法访问到这个快照文件的;除非你发布服务器、分发服务器和订阅服务器都是同一台机器;你应该设置快照文件夹路径为:\\DESKTOP-SDIK64J\ReplData;

 

(Figure3:快照文件夹)

(Figure4:数据库)

  • 快照发布:隔一段时间会覆盖订阅服务器的数据库,在订阅服务器上做的修改同样被覆盖;
  • 事务发布:是一种接近实时地从源到目标分发数据的方法;
  • 具有可更新订阅的事务发布:订阅服务器可更新发布服务器的数据;
  • 合并发布:发布服务器和订阅服务器的更新都会同步到对方,注意ID在合并发布上的冲突

image

(Figure5:事务发布)

注意表必须有主键才能进行复制,选择你必要的字段,这样可以减轻快照文件的大小和传输时间,而且在业务逻辑上更加安全,如果有需要,你还可以对记录进行过滤;

(Figure6_1:表字段)

 

(Figure6_2:存储过程)

 

(Figure6_3:视图)

 

(Figure6_4:用户定义函数)

image

(Figure7:快照代理)

image

(Figure8:安全设置)

使用上面创建好的ReplicationUser帐号作为连接到发布服务器的帐号和密码;

(Figure9:使用刚刚创建的帐号密码)

image

(Figure10:创建发布)

(Figure11:发布名称)

 

(Figure12:查看复制情况)

 

B. 订阅服务器配置

创建完发布服务器(分发服务器也一起创建了),接下来就可以创建订阅服务器了,下面是具体的步骤:

 

(Figure13:查找发布服务器)

(Figure14:查找发布服务器)

(Figure15:选择发布)

(Figure16:请求订阅)

(Figure17:订阅数据库)

(Figure18:订阅连接)

(Figure19:帐号密码)

(Figure20:代理计划)

(Figure21:初始化订阅)

image

(Figure22:创建订阅)

(Figure23:订阅)

(Figure24:发布服务器上的订阅)

(Figure25:复制监视器)

(Figure26:订阅数据库新增的表)

(Figure27:表数据)

 

三、注意事项

1. 在SQL SERVER下实现发布服务器和订阅服务器的通信正常(即可以互访),打开1433端口,在防火墙中设置入站规则;

2. 发布服务器与订阅服务器的SQL Server Agent代理帐号必须设置的一样,否则不能互访;

3. 如果你希望在复制的过程中一并复制非聚集索引,可以对发布属性-项目进行如下设置,修改完之后需要重新生成快照;

image

(Figure28:非聚集索引复制)

4. 复制代理:快照代理(snapshot agent) 分布式代理(Distribution agent)日志读代理(log Reader agent) 合并代理(Merge agent) 队列读代理(Queue Reader Agent)

5. 适合使用复制的一些场景包括:

1) 负载均衡:通过将数据复制到其它数据库服务器来减少当前服务器的负载,比如说最典型的应用就是分发数据来分离OLTP和OLAP环境;

2) 分区:将经常使用的数据和历史数据隔离,将历史数据复制到其它数据库中;

3) 授权:将一部分数据提供给需要使用数据的人,以供其使用;

4) 数据合并:每个区域都有其各自的数据,将其数据进行合并。比如一个大公司,每个地区都有其各自的销售数据,总部需要汇总这些数据;

5) 故障转移:复制所有数据,以便故障时进行转移;

6. 快照复制或事务复制生成快照文件的类型有:

架构 (.sch)、数据 (.bcp)、约束和索引 (.dri)、约束 (.idx)、触发器 (.trg)(只用于更新订阅服务器)、压缩的快照文件 (.cab)。

 

四、疑问

1. SQL Server 只有在完整日志模式下才能使用复制嘛?

解惑:在简单模式下一样可以使用复制;

2. 如果是跨网段(跨机房)的发布与订阅,有没办法实现?需要注意什么?

解惑:可以通过修改host文件的方式搭建复制,请参考:SQL Server跨网段(跨机房)复制

3. 如果说上面的情况可以在host设置,但是如果有端口映射的,host也无法设置吧?

解惑:在SQL Server配置管理器里建立别名,同样可参考:SQL Server跨网段(跨机房)复制

4. 订阅的形式可以选择推送订阅或者请求订阅,请求订阅降低分发服务器处理工作的开销,这个开销有多大呢?怎么计算影响?

解惑:只有在有很多订阅服务器的时候才比较明显,推送订阅与请求订阅更大的区别是在管理方面的不同;

ASP.NET OWIN OAuth:refresh token的持久化 - dudu - 博客园

mikel阅读(447)

来源: ASP.NET OWIN OAuth:refresh token的持久化 – dudu – 博客园

前一篇博文中,我们初步地了解了refresh token的用途——它是用于刷新access token的一种token,并且用简单的示例代码体验了一下获取refresh token并且用它刷新access token。在这篇博文中,我们来进一步探索refresh token。

之前只知道refresh token是用于刷新access token的,却不知道refresh token凭什么可以刷新access token?知其然,却不知其所以然。

这是由于之前没有发现refresh token与access token有1个非常重要的区别——Refresh token只是一种标识,不包含任何信息;而access token是经过序列化并加密的授权信息,发送到服务器时,会被解密并从中读取授权信息。正是因为access token包含的是信息,信息是易变的,所以它的过期时间很短;正是因为refresh token只是一种标识,不易变,所以生命周期可以很长。这才是既生access token,何生refresh token背后的真正原因。

在前一篇博文中,我们将refresh token存储在ConcurrentDictionary类型的静态变量中,只要程序重启,refresh token及相关信息就会丢失。为了给refresh token的生命周期保驾护航,我们不得不干一件经常干的事情——持久化,这篇博文也是因此而生。

要持久化,首先想到的就是Entity Framework与数据库,但我们目前的Web API只有2个客户端,一个是iOS App,一个是单元测试代码,用EF+数据库有如杀鸡用牛刀。何不换一种简单的方式?直接序列化为josn格式,然后保存在文件中。这么想,也这么干了。

下面就来分享一下我们如何用文件存储实现refresh token的持久化。

首先定义一个RefreshToken实体:

复制代码
public class RefreshToken
{
    public string Id { get; set; }

    public string UserName { get; set; }

    public Guid ClientId { get; set; }

    public DateTime IssuedUtc { get; set; }

    public DateTime ExpiresUtc { get; set; }

    public string ProtectedTicket { get; set; }
}
复制代码

这个RefreshToken实体不仅仅包含refresh token(对应于这里的Id属性),而且包含refresh token所关联的信息。因为refresh token是用于刷新accesss token的,如果没有这些关联信息,就无法生成access token。

接下来,我们在Application层定义一个与RefreshToken相关的服务接口IRefreshTokenService。虽然只是一个很简单的程序,我们还是使用n层架构来做,不管多小的项目,分离关注、减少依赖总是有帮助的,最起码可以增添写代码的乐趣。

复制代码
namespace CNBlogs.OpenAPI.Application.Interfaces
{
    public interface IRefreshTokenService
    {
        Task<RefreshToken> Get(string Id);
        Task<bool> Save(RefreshToken refreshToken);
        Task<bool> Remove(string Id);
    }
}
复制代码

IRefreshTokenService接口定义了3个方法:Get()用于在刷新access token时获取RefreshToken,Save()与Remove()用于在生成refresh token时将新RefreshToken保存并将旧RefreshToken删除。

定义好IRefreshTokenService接口之后,就可以专注OAuth部分的实现,持久化的实现部分暂且丢在一边(分离关注[注意力]的好处在这里就体现啦)。

OAuth部分的实现主要在CNBlogsRefreshTokenProvider(继承自AuthenticationTokenProvider),实现代码如下:

复制代码
public class CNBlogsRefreshTokenProvider : AuthenticationTokenProvider
{
    private IRefreshTokenService _refreshTokenService;

    public CNBlogsRefreshTokenProvider(IRefreshTokenService refreshTokenService)
    {
        _refreshTokenService = refreshTokenService;
    }

    public override async Task CreateAsync(AuthenticationTokenCreateContext context)
    {
        var clietId = context.OwinContext.Get<string>("as:client_id");
        if (string.IsNullOrEmpty(clietId)) return;

        var refreshTokenLifeTime = context.OwinContext.Get<string>("as:clientRefreshTokenLifeTime");
        if (string.IsNullOrEmpty(refreshTokenLifeTime)) return;

        //generate access token
        RandomNumberGenerator cryptoRandomDataGenerator = new RNGCryptoServiceProvider();
        byte[] buffer = new byte[50];
        cryptoRandomDataGenerator.GetBytes(buffer);
        var refreshTokenId = Convert.ToBase64String(buffer).TrimEnd('=').Replace('+', '-').Replace('/', '_');        

        var refreshToken = new RefreshToken()
        {
            Id = refreshTokenId,
            ClientId = new Guid(clietId),
            UserName = context.Ticket.Identity.Name,
            IssuedUtc = DateTime.UtcNow,
            ExpiresUtc = DateTime.UtcNow.AddSeconds(Convert.ToDouble(refreshTokenLifeTime)),
            ProtectedTicket = context.SerializeTicket()
        };

        context.Ticket.Properties.IssuedUtc = refreshToken.IssuedUtc;
        context.Ticket.Properties.ExpiresUtc = refreshToken.ExpiresUtc;

        if (await _refreshTokenService.Save(refreshToken))
        {
            context.SetToken(refreshTokenId);
        }
    }

    public override async Task ReceiveAsync(AuthenticationTokenReceiveContext context)
    {
        var refreshToken = await _refreshTokenService.Get(context.Token);

        if (refreshToken != null)
        {
            context.DeserializeTicket(refreshToken.ProtectedTicket);
            var result = await _refreshTokenService.Remove(context.Token);
        }
    }
}
复制代码

代码解读:

  • 为了调用IRefreshTokenService,我们将之通过CNBlogsRefreshTokenProvider的构造函数注入。
  • CreateAsync() 中用RNGCryptoServiceProvider生成refresh token,并获取相关信息(比如clientId, refreshTokenLifeTime, ProtectedTicket),创建RefreshToken,调用 IRefreshTokenService.Save() 进行持久化保存。
  • ReceiveAsync() 中调用 IRefreshTokenService.Get() 获取 RefreshToken,用它反序列出生成access token所需的ticket,从持久化中删除旧的refresh token(刷新access token时,refresh token也会重新生成)。

由于在CNBlogsRefreshTokenProvider中需要获取Client的clientId与refreshTokenLifeTime信息,所以我们需要在CNBlogsAuthorizationServerProvider中提供这个信息,在ValidateClientAuthentication重载方法中添加如下的代码:

context.OwinContext.Set<string>("as:client_id", clientId);
context.OwinContext.Set<string>("as:clientRefreshTokenLifeTime", client.RefreshTokenLifeTime.ToString());

以下是精简过的CNBlogsAuthorizationServerProvider完整实现代码(我们对client也用文件存储进行了持久化):

复制代码
public class CNBlogsAuthorizationServerProvider : OAuthAuthorizationServerProvider
{
    private IClientService _clientService;
 
    public CNBlogsAuthorizationServerProvider(IClientService clientService)
    {
        _clientService = clientService;
    }

    public override async Task ValidateClientAuthentication(OAuthValidateClientAuthenticationContext context)
    {
        string clientId;
        string clientSecret;
        
        //省略了return之前context.SetError的代码
        if (!context.TryGetBasicCredentials(out clientId, out clientSecret)) { return; }

        var client = await _clientService.Get(clientId);
        if (client == null) { return; }
        if (client.Secret != clientSecret) { return;}

        context.OwinContext.Set<string>("as:client_id", clientId);
        context.OwinContext.Set<string>("as:clientRefreshTokenLifeTime", client.RefreshTokenLifeTime.ToString());

        context.Validated(clientId);
    }

    public override async Task GrantClientCredentials(OAuthGrantClientCredentialsContext context)
    {
        var oAuthIdentity = new ClaimsIdentity(context.Options.AuthenticationType);

        context.Validated(oAuthIdentity);
    }

    public override async Task GrantResourceOwnerCredentials(
        OAuthGrantResourceOwnerCredentialsContext context)
    {
        //验证context.UserName与context.Password 
        var oAuthIdentity = new ClaimsIdentity(context.Options.AuthenticationType);
        oAuthIdentity.AddClaim(new Claim(ClaimTypes.Name, context.UserName));
        context.Validated(oAuthIdentity);
    }

    public override async Task GrantRefreshToken(OAuthGrantRefreshTokenContext context)
    {
        var newId = new ClaimsIdentity(context.Ticket.Identity);
        newId.AddClaim(new Claim("newClaim", "refreshToken"));
        var newTicket = new AuthenticationTicket(newId, context.Ticket.Properties);
        context.Validated(newTicket);
    }
}
复制代码

OAuth部分的主要代码完成后,接下来丢开OAuth,专心实现持久化部分的代码(分层带来的关注分离的好处再次体现)。

先实现Repository层的代码(Application层的接口已完成),定义IRefreshTokenRepository接口:

复制代码
namespace CNBlogs.OpenAPI.Repository.Interfaces
{
    public interface IRefreshTokenRepository
    {
        Task<RefreshToken> FindById(string Id);

        Task<bool> Insert(RefreshToken refreshToken);

        Task<bool> Delete(string Id);
    }
}
复制代码

然后以RefreshTokenRepository实现IRefreshTokenRepository接口,用文件存储进行持久化的实现代码都在这里(就是json的序列化与反序列化):

复制代码
namespace CNBlogs.OpenAPI.Repository.FileStorage
{
    public class RefreshTokenRepository : IRefreshTokenRepository
    {
        private string _jsonFilePath;
        private List<RefreshToken> _refreshTokens;

        public RefreshTokenRepository()
        {
            _jsonFilePath = HostingEnvironment.MapPath("~/App_Data/RefreshToken.json");
            if (File.Exists(_jsonFilePath))
            {
                var json = File.ReadAllText(_jsonFilePath);
                _refreshTokens = JsonConvert.DeserializeObject<List<RefreshToken>>(json);
                
            }
            if(_refreshTokens == null) _refreshTokens = new List<RefreshToken>();
        }

        public async Task<RefreshToken> FindById(string Id)
        {
            return _refreshTokens.Where(x => x.Id == Id).FirstOrDefault();
        }

        public async Task<bool> Insert(RefreshToken refreshToken)
        {
            _refreshTokens.Add(refreshToken);
            await WriteJsonToFile();
            return true;
        }

        public async Task<bool> Delete(string Id)
        {
            _refreshTokens.RemoveAll(x => x.Id == Id);
            await WriteJsonToFile();
            return true;
        }

        private async Task WriteJsonToFile()
        {
            using (var tw = TextWriter.Synchronized(new StreamWriter(_jsonFilePath, false)))
            {
                await tw.WriteAsync(JsonConvert.SerializeObject(_refreshTokens, Formatting.Indented));
            }
        }
    }
}
复制代码

接着就是Application层接口IRefreshTokenService的实现(调用Repository层的接口):

复制代码
namespace CNBlogs.OpenAPI.Application.Services
{
    public class RefreshTokenService : IRefreshTokenService
    {
        private IRefreshTokenRepository _refreshTokenRepository;

        public RefreshTokenService(IRefreshTokenRepository refreshTokenRepository)
        {
            _refreshTokenRepository = refreshTokenRepository;
        }

        public async Task<RefreshToken> Get(string Id)
        {
            return await _refreshTokenRepository.FindById(Id);
        }

        public async Task<bool> Save(RefreshToken refreshToken)
        {
            return await _refreshTokenRepository.Insert(refreshToken);
        }

        public async Task<bool> Remove(string Id)
        {
            return await _refreshTokenRepository.Delete(Id);
        }
    }
}
复制代码

好了,主要工作都已完成:

1)Web层的CNBlogsAuthorizationServerProvider与CNBlogsRefreshTokenProvider

2)Domain层的实体RefreshToken

3)Application层的IRefreshTokenService与RefreshTokenService.cs

4)Repository层的IRefreshTokenRepository与RefreshTokenRepository

麻雀虽小,五脏俱全。

最后就剩下一些收尾工作了。

由于调用的接口都是通过构造函数注入的,需要做一些依赖注入的工作,实现DependencyInjectionConfig:

复制代码
namespace OpenAPI.App_Start
{
    public static class DependencyInjectionConfig
    {
        public static void Register()
        {
            var containter = IocContainer.Default = new IocUnityContainer();
            containter.RegisterType<IRefreshTokenService, RefreshTokenService>();
            containter.RegisterType<IRefreshTokenRepository, RefreshTokenRepository>();
        }
    }
}
复制代码

(注:IocContainer是我们内部用的组件,封装了Unity)

然后在Application_Start中调用它。

到这里就万事俱备,只欠东风了。

只要在Startup.Auth.cs中通过IOC容器解析出CNBlogsAuthorizationServerProvider与CNBlogsRefreshTokenProvider的实例,东风就来了。

复制代码
public partial class Startup
{
    public static OAuthAuthorizationServerOptions OAuthOptions { get; private set; }

    public void ConfigureAuth(IAppBuilder app)
    {
        OAuthOptions = new OAuthAuthorizationServerOptions
        {
            TokenEndpointPath = new PathString("/token"),
            Provider = IocContainer.Resolver.Resolve<CNBlogsAuthorizationServerProvider>(),
            AccessTokenExpireTimeSpan = TimeSpan.FromDays(1),
            AllowInsecureHttp = true,
            RefreshTokenProvider = IocContainer.Resolver.Resolve<CNBlogsRefreshTokenProvider>()
        };

        app.UseOAuthBearerTokens(OAuthOptions);
    }
}
复制代码

至此,开发第一版给iOS App用的Web API所面临的OAuth问题基本解决了。这些博文只是解决实际问题之后的一点记载,希望能让想基于ASP.NET OWIN OAuth开发Web API的朋友少走一些弯路。

【参考资料】

Enable OAuth Refresh Tokens in AngularJS App using ASP .NET Web API 2, and Owin

HttpClient + ASP.NET Web API, WCF之外的另一个选择 - dudu - 博客园

mikel阅读(546)

来源: HttpClient + ASP.NET Web API, WCF之外的另一个选择 – dudu – 博客园

WCF的野心造成了它的庞大复杂,HTTP的单纯造就了它的简单优美。为了实现分布式Web应用,我们不得不将两者凑合在一起 —— WCF服务以HTTP绑定宿主于IIS。

于是有了让人晕头转向的配置、让人郁闷不已的调试,还有那ServiceContract, DataContract, EnumMember…还有还有,不要在using语句中调用WCF服务

于是经常自问:拿着牛刀削苹果有必要吗?废话,当然没有必要,水果刀在哪里?

微软看着这么多人拿着牛刀削苹果,自己也看不下去了,于是,一种水果刀横空出世 —— ASP.NET Web API。

最近我们在实际开发中有个地方用WCF太麻烦,就小试了一下水果刀,感觉还不错。

下面用一个简单的示例分享一下ASP.NET Web API水果刀的用法。

服务端ASP.NET Web API的实现

需要准备的工具:Visual Studio 2010, NuGet

1. 新建一个空的ASP.NET Web Application项目。

2. 通过NuGet添加ASP.NET Web API的引用,在NuGet中搜索时要用“AspNetWebApi”(用“ASP.NET Web API”是搜索不到的),然后选择ASP.NET Web API(Beta)进行安装。

3. 添加Global.asax,在Application_Start中注册Web API的路由,在Global.asax.cs中添加如下代码:

protected void Application_Start(object sender, EventArgs e)
{
    RouteTable.Routes.MapHttpRoute("WebApi", "api/{controller}/{action}/{id}", 
        new { id = RouteParameter.Optional });
}

4. 添加Controllers文件夹,在其中添加类文件DemoController.cs,并让DemoController继承自ApiController。代码如下:

复制代码
namespace CNBlogsWebApiDemo.Controllers
{
    public class DemoController : ApiController
    {
    }
}
复制代码

5. 添加ViewModels文件夹,在其中添加Site.cs,并定义Site。

复制代码
namespace CNBlogsWebApiDemo.ViewModels
{
    public class Site
    {
        public int SiteId { get; set; }
        public string Title { get; set; }
        public string Uri { get; set; }
    }
}
复制代码

6. 给DemoController添加一个方法SiteList,并写上我们的示例代码。代码如下:

复制代码
public class DemoController : ApiController
{
    public IList<Site> SiteList(int startId, int itemcount)
    {
        var sites = new List<Site>();
        sites.Add(new Site { SiteId = 1, Title = "test", Uri = "www.cnblogs.cc" });
        sites.Add(new Site { SiteId = 2, Title = "博客园首页", Uri = "www.cnblogs.com" });
        sites.Add(new Site { SiteId = 3, Title = "博问", Uri = "q.cnblogs.com" });
        sites.Add(new Site { SiteId = 4, Title = "新闻", Uri = "news.cnblogs.com" });
        sites.Add(new Site { SiteId = 5, Title = "招聘", Uri = "job.cnblogs.com" });

        var result = (from Site site in sites
                        where site.SiteId > startId
                        select site)
                        .Take(itemcount)
                        .ToList();
        return result;
    }
}
复制代码

7. 配置一下Web项目的启动设置Specific Page与Specific port

8. Ctrl+F5运行项目,结果如下:

结果是我们期望的,用浏览器直接可以查看Web API的运行结果,测试时会很方便。

好了,服务端Web API就这么轻松搞定了!

客户端通过HttpClient调用服务端Web API

1. 新建一个WebApiTest的类库项目。

2. 在NuGet中添加System.Net.Http(HttpClient就在这里), Json.NET, xUnit.net。

3. 添加类文件WebApiClientTest.cs,添加测试方法WebApi_SiteList_Test:

复制代码
namespace WebApiClientTest
{
    public class WebApiClientTest
    {
        [Fact]
        public void WebApi_SiteList_Test()
        {

        }
    }
}
复制代码

4. WebApi_SiteList_Test() 的代码实现

4.1 首先,要确定三个东西:

a) 客户端调用WebAPI的方式是Http Get,还Http Post,我们这里选用Http Post;

b) 客户端调用WebAPI时传递的参数格式,我们这里选用的是Json。

c) WebAPI返回的数据格式,我们这里选用的也是Json(这也是之前添加Json.NET引用的原因)。

4.2 用到的类

  • System.Net.Http.HttpClient
  • System.Net.Http.httpContent
  • System.Net.Http.StringContent
  • System.Net.Http.Headers.MediaTypeHeaderValue
  • Newtonsoft.Json.JsonConvert

4.3 准备需要传递给WebAPI的参数

需要传递的两个参数是startId ,itemcount,传递的格式是Json。这里可没有JavaScript中的JSON.stringify(),但我们有Json.NET,再加上匿名类型,有点用js的感觉,代码如下:

var requestJson = JsonConvert.SerializeObject(new { startId = 1, itemcount = 3 });

代码的运行结果:{“startId”:1,”itemcount”:3}

然后用System.Net.Http.StringContent把它打个包:

HttpContent httpContent = new StringContent(requestJson);

然后设置一下ContentType:

httpContent.Headers.ContentType = new MediaTypeHeaderValue("application/json");

4.4 通过Http Post调用WebAPI得到返回结果

HttpClient闪亮登场,调用它的PostAsync()方法轻松搞定:

var httpClient = new HttpClient();
var responseJson = httpClient.PostAsync("http://localhost:9000/api/demo/sitelist", httpContent)
    .Result.Content.ReadAsStringAsync().Result;

看一下responseJson的结果:

[{"SiteId":2,"Title":"博客园首页","Uri":"www.cnblogs.com"},{"SiteId":3,"Title":"博问","Uri":"q.cnblogs.com"},{"SiteId":4,"Title":"新闻","Uri":"news.cnblogs.com"}]

正宗的Json!你注意到没有,服务端WebAPI的代码未作任何修改,我们只是在Http Headers中将ContentType设置为了application/json,返回的就是Json格式的数据。而我们通过浏览器访问,得到的还是标准的XML。这里就是ASP.NET Web API的魅力之一 —— 一次实现,按需服务。

4.5 将Json格式返回的结果反序列化为强类型

Json.NET又登场:

var sites = JsonConvert.DeserializeObject<IList<Site>>(responseJson);

展示一下返回结果:

代码

sites.ToList().ForEach(x => Console.WriteLine(x.Title + ":" + x.Uri));

结果

  博客园首页:www.cnblogs.com
  博问:q.cnblogs.com
  新闻:news.cnblogs.com

4.6 WebApi_SiteList_Test() 完整实现代码

复制代码
public class WebApiClientTest
{
    [Fact]
    public void WebApi_SiteList_Test()
    {            
        var requestJson = JsonConvert.SerializeObject(new { startId = 1, itemcount = 3 });

        HttpContent httpContent = new StringContent(requestJson);
        httpContent.Headers.ContentType = new MediaTypeHeaderValue("application/json");

        var httpClient = new HttpClient();
        var responseJson = httpClient.PostAsync("http://localhost:9000/api/demo/sitelist", httpContent)
            .Result.Content.ReadAsStringAsync().Result;

        var sites = JsonConvert.DeserializeObject<IList<Site>>(responseJson);

        sites.ToList().ForEach(x => Console.WriteLine(x.Title + ":" + x.Uri));
    }
}
复制代码

注:运行这里的代码之前,要先运行WebAPI项目,先把服务跑起来,客户端才能享受到服务。

JQuery ajax调用代码比较一下:

复制代码
var requestJson = JSON.stringify({ startId: 1, itemcount: 3 });
$.ajax({
    url: '/api/demo/sitelist',
    data: requestJson,
    type: "post",
    dataType: "json",
    contentType: "application/json; charset=utf8",
    success: function (data) {
        jQuery.each(data, function (i, val) {
            $("#result").append(val.Title + ': ' + val.Uri +'<br/>');
        });
    }
});
复制代码

注:上面的代码是可真实运行的哦,代码在示例代码WebApiDemo项目的AjaxWebApi.htm文件中。这也是ASP.NET Web API “一次实现,按需服务”的体现。

小结 

水果刀(ASP.NET Web API)用下来感觉还不错,不仅可以削苹果,还可以削梨子,切西瓜也不在话下。用不用牛刀(WCF),还得多考虑考虑。

示例代码下载

http://files.cnblogs.com/dudu/CNBlogsWebApiDemo.rar

更新

娃哈哈ABC提了一个很好的问题

WebApiTest引用了WebApiDemo。实现了强类型,这样还算分布式应用吗?

强大的Json.NET可以轻松解决这个问题,代码修改为:

//原先的代码:var sites = JsonConvert.DeserializeObject<IList<Site>>(responseJson);
var sites = JArray.Parse(responseJson);
sites.ToList().ForEach(x => Console.WriteLine(x["Title"] + ":" + x["Uri"]));

什么是 JWT -- JSON WEB TOKEN - 简书

mikel阅读(508)

来源: 什么是 JWT — JSON WEB TOKEN – 简书

什么是JWT

Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准((RFC 7519).该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务逻辑所必须的声明信息,该token也可直接被用于认证,也可被加密。

起源

说起JWT,我们应该来谈一谈基于token的认证和传统的session认证的区别。

传统的session认证

我们知道,http协议本身是一种无状态的协议,而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证,那么下一次请求时,用户还要再一次进行用户认证才行,因为根据http协议,我们并不能知道是哪个用户发出的请求,所以为了让我们的应用能识别是哪个用户发出的请求,我们只能在服务器存储一份用户登录的信息,这份登录信息会在响应时传递给浏览器,告诉其保存为cookie,以便下次请求时发送给我们的应用,这样我们的应用就能识别请求来自哪个用户了,这就是传统的基于session认证。

但是这种基于session的认证使应用本身很难得到扩展,随着不同客户端用户的增加,独立的服务器已无法承载更多的用户,而这时候基于session认证应用的问题就会暴露出来.

基于session认证所显露的问题

Session: 每个用户经过我们的应用认证之后,我们的应用都要在服务端做一次记录,以方便用户下次请求的鉴别,通常而言session都是保存在内存中,而随着认证用户的增多,服务端的开销会明显增大。

扩展性: 用户认证之后,服务端做认证记录,如果认证的记录被保存在内存中的话,这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源,这样在分布式的应用上,相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。

CSRF: 因为是基于cookie来进行用户识别的, cookie如果被截获,用户就会很容易受到跨站请求伪造的攻击。

基于token的鉴权机制

基于token的鉴权机制类似于http协议也是无状态的,它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了,这就为应用的扩展提供了便利。

流程上是这样的:

  • 用户使用用户名密码来请求服务器
  • 服务器进行验证用户的信息
  • 服务器通过验证发送给用户一个token
  • 客户端存储token,并在每次请求时附送上这个token值
  • 服务端验证token值,并返回数据

这个token必须要在每次请求时传递给服务端,它应该保存在请求头里, 另外,服务端要支持CORS(跨来源资源共享)策略,一般我们在服务端这么做就可以了Access-Control-Allow-Origin: *

那么我们现在回到JWT的主题上。

JWT长什么样?

JWT是由三段信息构成的,将这三段信息文本用.链接一起就构成了Jwt字符串。就像这样:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

JWT的构成

第一部分我们称它为头部(header),第二部分我们称其为载荷(payload, 类似于飞机上承载的物品),第三部分是签证(signature).

header

jwt的头部承载两部分信息:

  • 声明类型,这里是jwt
  • 声明加密的算法 通常直接使用 HMAC SHA256

完整的头部就像下面这样的JSON:

{
  'typ': 'JWT',
  'alg': 'HS256'
}

然后将头部进行base64加密(该加密是可以对称解密的),构成了第一部分.

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

playload

载荷就是存放有效信息的地方。这个名字像是特指飞机上承载的货品,这些有效信息包含三个部分

  • 标准中注册的声明
  • 公共的声明
  • 私有的声明

标准中注册的声明 (建议但不强制使用) :

  • iss: jwt签发者
  • sub: jwt所面向的用户
  • aud: 接收jwt的一方
  • exp: jwt的过期时间,这个过期时间必须要大于签发时间
  • nbf: 定义在什么时间之前,该jwt都是不可用的.
  • iat: jwt的签发时间
  • jti: jwt的唯一身份标识,主要用来作为一次性token,从而回避重放攻击。

公共的声明
公共的声明可以添加任何的信息,一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息,因为该部分在客户端可解密.

私有的声明
私有声明是提供者和消费者所共同定义的声明,一般不建议存放敏感信息,因为base64是对称解密的,意味着该部分信息可以归类为明文信息。

定义一个payload:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

然后将其进行base64加密,得到Jwt的第二部分。

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

signature

jwt的第三部分是一个签证信息,这个签证信息由三部分组成:

  • header (base64后的)
  • payload (base64后的)
  • secret

这个部分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串,然后通过header中声明的加密方式进行加盐secret组合加密,然后就构成了jwt的第三部分。

// javascript
var encodedString = base64UrlEncode(header) + '.' + base64UrlEncode(payload);

var signature = HMACSHA256(encodedString, 'secret'); // TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

将这三部分用.连接成一个完整的字符串,构成了最终的jwt:

  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

注意:secret是保存在服务器端的,jwt的签发生成也是在服务器端的,secret就是用来进行jwt的签发和jwt的验证,所以,它就是你服务端的私钥,在任何场景都不应该流露出去。一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了。

如何应用

一般是在请求头里加入Authorization,并加上Bearer标注:

fetch('api/user/1', {
  headers: {
    'Authorization': 'Bearer ' + token
  }
})

服务端会验证token,如果验证通过就会返回相应的资源。整个流程就是这样的:

jwt-diagram

总结

优点

  • 因为json的通用性,所以JWT是可以进行跨语言支持的,像JAVA,JavaScript,NodeJS,PHP等很多语言都可以使用。
  • 因为有了payload部分,所以JWT可以在自身存储一些其他业务逻辑所必要的非敏感信息。
  • 便于传输,jwt的构成非常简单,字节占用很小,所以它是非常便于传输的。
  • 它不需要在服务端保存会话信息, 所以它易于应用的扩展

安全相关

  • 不应该在jwt的payload部分存放敏感信息,因为该部分是客户端可解密的部分。
  • 保护好secret私钥,该私钥非常重要。
  • 如果可以,请使用https协议

作者:Dearmadman
链接:https://www.jianshu.com/p/576dbf44b2ae
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

Web API与OAuth:既生access token,何生refresh token - dudu - 博客园

mikel阅读(639)

来源: Web API与OAuth:既生access token,何生refresh token – dudu – 博客园

在前一篇博文中,我们基于 ASP.NET Web API 与 OWIN OAuth 以 Resource Owner Password Credentials Grant 的授权方式( grant_type=password )获取到了 access token,并以这个 token 成功调用了与当前用户(resource owner)关联的 Web API。

本以为搞定了 access token 就搞定了 Web API 的验证与授权问题,可是发现 OAuth 中还有一种 token,叫 refresh token。开始的时候很是纳闷,access token 已经能解决问题,为什么要搞定两套 token,refresh token 有啥用?在纳闷之下,发出了这样的感慨:既生 access token,何生 refresh token?

后来看了一些资料,有点明白了。refresh token 是专用于刷新 access token 的 token。

为什么要刷新 access token 呢?一是因为 access token 是有过期时间的,到了过期时间这个 access token 就失效,需要刷新;二是因为一个 access token 会关联一定的用户权限,如果用户授权更改了,这个 access token 需要被刷新以关联新的权限。

为什么要专门用一个 token 去更新 access token 呢?如果没有 refresh token,也可以刷新 access token,但每次刷新都要用户输入登录用户名与密码,多麻烦。有了 refresh token,可以减少这个麻烦,客户端直接用 refresh token 去更新 access token,无需用户进行额外的操作。

两个为什么也许没有解释清楚 refresh token 的用途,下面我们用示例代码在 ASP.NET Web API 与 OWIN OAuth 中实际体验一下,或许有更直观的认识。

(一)Refresh token 的生成、发放、保存

实现一个 RefreshTokenProvider ,比如 CNBlogsRefreshTokenProvider。

需要重载 Microsoft.Owin.Security.Infrastructure.AuthenticationTokenProvider 中的 Create() 与 Receive() 方法(或者直接实现 IAuthenticationTokenProvider 接口),示例代码如下:

复制代码
public class CNBlogsRefreshTokenProvider : AuthenticationTokenProvider
{
    private static ConcurrentDictionary<string, string> _refreshTokens = new ConcurrentDictionary<string, string>();

    public override void Create(AuthenticationTokenCreateContext context)
    {
        string tokenValue = Guid.NewGuid().ToString("n");

        context.Ticket.Properties.IssuedUtc = DateTime.UtcNow;        
        context.Ticket.Properties.ExpiresUtc = DateTime.UtcNow.AddDays(60);

        _refreshTokens[tokenValue] = context.SerializeTicket();

        context.SetToken(tokenValue);
    }

    public override void Receive(AuthenticationTokenReceiveContext context)
    {
        string value;
        if (_refreshTokens.TryRemove(context.Token, out value))
        {
            context.DeserializeTicket(value);
        }
    }
}
复制代码

(注:后来采用的是重载CreateAsync()方法)

然后应用这个 CNBlogsRefreshTokenProvider:

复制代码
public void ConfigureAuth(IAppBuilder app)
{
    OAuthOptions = new OAuthAuthorizationServerOptions
    {
        TokenEndpointPath = new PathString("/token"),
        Provider = new CNBlogsAuthorizationServerProvider(),
        AccessTokenExpireTimeSpan = TimeSpan.FromDays(1),
        AllowInsecureHttp = true,
        RefreshTokenProvider = new CNBlogsRefreshTokenProvider()
    };

    app.UseOAuthBearerTokens(OAuthOptions);
}
复制代码

(二)验证持有 refresh token 的客户端

重载 OAuthAuthorizationServerProvider.GrantRefreshToken() 方法,示例代码如下:

复制代码
using Microsoft.Owin.Security.OAuth;

namespace OpenAPI.Providers
{
    public class CNBlogsAuthorizationServerProvider : OAuthAuthorizationServerProvider
    {
        public override async Task GrantRefreshToken(OAuthGrantRefreshTokenContext context)
        {
            var originalClient = context.Ticket.Properties.Dictionary["as:client_id"];
            var currentClient = context.ClientId;

            if (originalClient != currentClient)
            {
                context.Rejected();
                return;
            }

            var newId = new ClaimsIdentity(context.Ticket.Identity);
            newId.AddClaim(new Claim("newClaim", "refreshToken"));

            var newTicket = new AuthenticationTicket(newId, context.Ticket.Properties);
            context.Validated(newTicket);

            await base.GrantRefreshToken(context);
        }
    }
}
复制代码

为了验证client_id,需要在 GrantClientCredentials() 重载方法中保存client_id至context.Ticket:

复制代码
namespace OpenAPI.Providers
{
    public class CNBlogsAuthorizationServerProvider : OAuthAuthorizationServerProvider
    {
        public override async Task GrantClientCredentials(OAuthGrantClientCredentialsContext context)
        {
            var oAuthIdentity = new ClaimsIdentity(context.Options.AuthenticationType);

            var props = new AuthenticationProperties(new Dictionary<string, string>
                {
                    { "as:client_id", context.ClientId }
                });
            var ticket = new AuthenticationTicket(oAuthIdentity, props);

            context.Validated(ticket);
        }    
    }
}
复制代码

只需实现上面这些代码,其他的都由 Microsoft.Owin.Security.OAuth 帮你代劳了。

(三)测试客户端获取 refresh token

客户端获取 access token 与 refresh token 是一起的,示例代码如下:

复制代码
[Fact]
public async Task GetAccessTokenTest()
{
    var clientId = "[clientId]";
    var clientSecret = "[clientSecret]";

    var parameters = new Dictionary<string, string>();
    parameters.Add("grant_type", "password");            
    parameters.Add("username", "[username]");
    parameters.Add("password", "[password]");

    _httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue(
        "Basic",
        Convert.ToBase64String(Encoding.ASCII.GetBytes(clientId + ":" + clientSecret)));

    var response = await _httpClient.PostAsync("/token", new FormUrlEncodedContent(parameters));
    var responseValue = await response.Content.ReadAsStringAsync();

    Console.WriteLine(responseValue);
}
复制代码

运行结果:

复制代码
{ 
    "access_token": "D3VjxsFvr...",
    "token_type": "bearer",
    "expires_in": 86399,
    "refresh_token": "7f7edd15cba043c29d487235c2276eb1"
}
复制代码

成功拿到了 access token。

(四)测试客户端用 refresh token 刷新 access token

客户端测试代码如下:

复制代码
public async Task GetAccessTokenByRefreshTokenTest()
{
    var clientId = "[clientId]";
    var clientSecret = "[clientSecret]";

    var parameters = new Dictionary<string, string>();
    parameters.Add("grant_type", "refresh_token");
    parameters.Add("refresh_token", "7f7edd15cba043c29d487235c2276eb1");

    _httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue(
        "Basic",
        Convert.ToBase64String(Encoding.ASCII.GetBytes(clientId + ":" + clientSecret)));

    var response = await _httpClient.PostAsync("/token", new FormUrlEncodedContent(parameters));
    var responseValue = await response.Content.ReadAsStringAsync();

    Console.WriteLine(responseValue);
}
复制代码

注:这段客户端代码与前一步中客户端代码的主要区别是少了下面传递 resource owner 用户名与密码的代码,这就是 refresh token 的用途所在 —— 不需要用户名与密码就可以刷新 access token。

parameters.Add("username", "[username]");
parameters.Add("password", "[password]");

运行结果:

复制代码
{
    "access_token": "[new access token]",
    "token_type": "bearer",
    "expires_in": 86399,
    "refresh_token": "[new refresh token]"
}
复制代码

搞定!

看起来挺简单,却折腾了一天。 希望在你折腾OAuth的时候,这篇博文能够帮你减少折腾的时间。

【参考资料】

Adding Refresh Tokens to a Web API v2 Authorization Server

EmbeddedResourceOwnerFlowWithRefreshTokens

Katana source code

Enable OAuth Refresh Tokens in AngularJS App using ASP .NET Web API 2, and Owin

基于token的登陆验证机制 - 程序员自由之路 - 博客园

mikel阅读(620)

来源: 基于token的登陆验证机制 – 程序员自由之路 – 博客园

session简介

做过Web开发的程序员应该对Session都比较熟悉,Session是一块保存在服务器端的内存空间,一般用于保存用户的会话信息。

用户通过用户名和密码登陆成功之后,服务器端程序会在服务器端开辟一块Session内存空间并将用户的信息存入这块空间,同时服务器会
在cookie中写入一个Session_id的值,这个值用于标识这个内存空间。

下次用户再来访问的话会带着这个cookie中的session_id,服务器拿着这个id去寻找对应的session,如果session中已经有了这个用户的
登陆信息,则说明用户已经登陆过了。

使用Session保持会话信息使用起来非常简单,技术也非常成熟。但是也存在下面的几个问题:

  • 服务器压力大:通常Session是存储在内存中的,每个用户通过认证之后都会将session数据保存在服务器的内存中,而当用户量增大时,服务器的压力增大。
  • Session共享:现在很多应用都是分布式集群,需要我们做额外的操作进行Session共享;
  • CSRF跨站伪造请求攻击:Session机制是基于浏览器端的cookie的,cookie如果被截获,用户就会很容易受到跨站请求伪造的攻击。

基于token的认证

基于token的认证机制将认证信息返回给客户端并存储。下次访问其他页面,需要从客户端传递认证信息回服务端。简单的流程如下:

  • 客户端使用用户名跟密码请求登录;
  • 服务端收到请求,去验证用户名与密码;
  • 验证成功后,服务端会签发一个 Token,再把这个 Token 发送给客户端;
  • 客户端收到 Token 以后可以把它存储起来,比如放在 Cookie 里或者 Local Storage 里;
  • 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token;
  • 服务端收到请求,然后去验证客户端请求里面带着的 Token,如果验证成功,就向客户端返回请求的数据;

基于token的验证机制,有以下的优点:

  • 支持跨域访问,将token置于请求头中,而cookie是不支持跨域访问的;
  • 无状态化,服务端无需存储token,只需要验证token信息是否正确即可,而session需要在服务端存储,一般是通过cookie中的sessionID在服务端查找对应的session;
  • 无需绑定到一个特殊的身份验证方案(传统的用户名密码登陆),只需要生成的token是符合我们预期设定的即可;
  • 更适用于移动端(Android,iOS,小程序等等),像这种原生平台不支持cookie,比如说微信小程序,每一次请求都是一次会话,当然我们可以每次去手动为他添加cookie,详情请查看博主另一篇博客;
  • 避免CSRF跨站伪造攻击,还是因为不依赖cookie;

缺点的话一个就是相比较于传统的session登陆机制实现起来略微复杂一点,另外一个比较大的缺点是由于服务器不保存 token,因此无法在使用过程中废止某个 token,或者更改 token 的权限。也就是说,一旦 token 签发了,在到期之前就会始终有效,除非服务器部署额外的逻辑。

退出登陆的话,只要前端清除token信息即可。

基于JWT的token认证实现

JWT(JSON Web Token)就是基于token认证的代表,这边就用JWT为列来介绍基于token的认证机制。

需要引入JWT的依赖

<dependency>
  <groupId>com.auth0</groupId>
  <artifactId>java-jwt</artifactId>
  <version>3.8.2</version>
</dependency>

生成token和验证token的工具类如下:

public class JWTTokenUtil {
    //设置过期时间
    private static final long EXPIRE_DATE=30*60*100000;
    //token秘钥
    private static final String TOKEN_SECRET = "ZCfasfhuaUUHufguGuwu2020BQWE";

    public static String token (String username,String password){

        String token = "";
        try {
            //过期时间
            Date date = new Date(System.currentTimeMillis()+EXPIRE_DATE);
            //秘钥及加密算法
            Algorithm algorithm = Algorithm.HMAC256(TOKEN_SECRET);
            //设置头部信息
            Map<String,Object> header = new HashMap<>();
            header.put("typ","JWT");
            header.put("alg","HS256");
            //携带username,password信息,生成签名
            token = JWT.create()
                    .withHeader(header)
                    .withClaim("username",username)
                    .withClaim("password",password).withExpiresAt(date)
                    .sign(algorithm);
        }catch (Exception e){
            e.printStackTrace();
            return  null;
        }
        return token;
    }

    public static boolean verify(String token){
        /**
         * @desc   验证token,通过返回true
         * @params [token]需要校验的串
         **/
        try {
            Algorithm algorithm = Algorithm.HMAC256(TOKEN_SECRET);
            JWTVerifier verifier = JWT.require(algorithm).build();
            DecodedJWT jwt = verifier.verify(token);
            return true;
        }catch (Exception e){
            e.printStackTrace();
            return  false;
        }
    }
    public static void main(String[] args) {
        String username ="name1";
        String password = "pw1";
        //注意,一般不会把密码等私密信息放在payload中,这边只是举个列子
        String token = token(username,password);
        System.out.println(token);
        boolean b = verify(token);
        System.out.println(b);
    }
}

执行结果如下:

Connected to the target VM, address: '127.0.0.1:11838', transport: 'socket'
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJwYXNzd29yZCI6IjEyMyIsImV4cCI6MTU5NzM5Nzc0OCwidXNlcm5hbWUiOiJ6aGFuZ3NhbiJ9.LI5S_nX-YcqtExI9UtKiP8FPqpQW_ccaws2coLzyOS0
true

关于DecodedJWT这个类,大家可以重点看下,里面包含了解码后的用户信息。

JWT的使用说明

客户端收到服务器返回的 JWT,可以储存在 Cookie 里面,也可以储存在 localStorage。

此后,客户端每次与服务器通信,都要带上这个 JWT。你可以把它放在 Cookie 里面自动发送,但是这样不能跨域,所以更好的做法是放在 HTTP 请求的头信息Authorization字段里面。

Authorization: Bearer <token>

另一种做法是,跨域的时候,JWT 就放在 POST 请求的数据体里面。

JWT 本身包含了认证信息,一旦泄露,任何人都可以获得该令牌的所有权限。为了减少盗用,JWT 的有效期应该设置得比较短。对于一些比较重要的权限,使用时应该再次对用户进行认证。

为了减少盗用,JWT 不应该使用 HTTP 协议明码传输,要使用 HTTPS 协议传输。(或者是对JWT在前后端之间进行加密之后在传输)

关于JWT的一个问题

上面生成JWT token的过程关键点就是密钥,假如这个密钥泄露了,那是不是就可以伪造token了。

还有就是生产环境的密钥值,开发的程序员大概率是知道的,怎么防止程序要监守自盗,伪造token值呢?希望有经验的大佬指教下。

//token秘钥
private static final String TOKEN_SECRET = "ZCfasfhuaUUHufguGuwu2020BQWE";

关于上面的问题,@仙湖码农 给出了一个简单易懂的方案~

jwt 来生成token,还有一个玩法,用户登录时,生成token的 SecretKey 是一个随机数,也就是说每个用户,每次登录时jwt SecretKey 是随机数,并保存到缓存,key是登录账户,(当然了,分布式缓存的话,就用Redis,SQLServer缓存等等),总之,客户端访问接口是,header 要带登录账户,和token,服务端拿到登录账号,到缓存去捞相应的SecretKey ,然后再进行token校验。可以防伪造token了(这个方案在一定程度上能防止伪造,但是不能防止token泄露被劫持)。

获取refresh token的方法

参考

基于jwt的token验证 - 奕锋博客 - 博客园

mikel阅读(663)

来源: 基于jwt的token验证 – 奕锋博客 – 博客园

一、什么是JWT

Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准((RFC 7519).
该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景。
JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务逻辑所必须的声明信息,该token也可直接被用于认证,也可被加密。

二、JWT的组成

1、JWT生成编码后的样子

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.UQmqAUhUrpDVV2ST7mZKyLTomVfg7sYkEjmdDI5XF8Q

2、JWT由三部分构成

第一部分我们称它为头部(header),第二部分我们称其为载荷(payload, 类似于飞机上承载的物品),第三部分是签证(signature).

 header

jwt的头部承载两部分信息:

  • 声明类型,这里是jwt
  • 声明加密的算法 通常直接使用 HMAC SHA256

完整的头部就像下面这样的JSON:

{
  'typ': 'JWT',
  'alg': 'HS256'
}

然后将头部进行base64加密(该加密是可以对称解密的),构成了第一部分

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

playload

载荷就是存放有效信息的地方。这个名字像是特指飞机上承载的货品,这些有效信息包含三个部分

  • 标准中注册的声明
  • 公共的声明
  • 私有的声明

标准中注册的声明 (建议但不强制使用) :

  • iss: jwt签发者
  • sub: jwt所面向的用户
  • aud: 接收jwt的一方
  • exp: jwt的过期时间,这个过期时间必须要大于签发时间
  • nbf: 定义在什么时间之前,该jwt都是不可用的.
  • iat: jwt的签发时间
  • jti: jwt的唯一身份标识,主要用来作为一次性token,从而回避重放攻击。

公共的声明 :
公共的声明可以添加任何的信息,一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息,因为该部分在客户端可解密.

 私有的声明 :

私有声明是提供者和消费者所共同定义的声明,一般不建议存放敏感信息,因为base64是对称解密的,意味着该部分信息可以归类为明文信息。

定义一个payload:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

然后将其进行base64加密,得到Jwt的第二部分

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

signature

jwt的第三部分是一个签证信息,这个签证信息由三部分组成:

  • header (base64后的)
  • payload (base64后的)
  • secret

这个部分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串(头部在前),然后通过header中声明的加密方式进行加盐secret组合加密,然后就构成了jwt的第三部分。

UQmqAUhUrpDVV2ST7mZKyLTomVfg7sYkEjmdDI5XF8Q

密钥secret是保存在服务端的,服务端会根据这个密钥进行生成token和验证,所以需要保护好。

3、签名的目的

最后一步签名的过程,实际上是对头部以及载荷内容进行签名。一般而言,加密算法对于不同的输入产生的输出总是不一样的。对于两个不同的输入,产生同样的输出的概率极其地小(有可能比我成世界首富的概率还小)。所以,我们就把“不一样的输入产生不一样的输出”当做必然事件来看待吧。

所以,如果有人对头部以及载荷的内容解码之后进行修改,再进行编码的话,那么新的头部和载荷的签名和之前的签名就将是不一样的。而且,如果不知道服务器加密的时候用的密钥的话,得出来的签名也一定会是不一样的。

服务器应用在接受到JWT后,会首先对头部和载荷的内容用同一算法再次签名。那么服务器应用是怎么知道我们用的是哪一种算法呢?别忘了,我们在JWT的头部中已经用alg字段指明了我们的加密算法了。

如果服务器应用对头部和载荷再次以同样方法签名之后发现,自己计算出来的签名和接受到的签名不一样,那么就说明这个Token的内容被别人动过的,我们应该拒绝这个Token,返回一个HTTP 401 Unauthorized响应。

注意:在JWT中,不应该在载荷里面加入任何敏感的数据,比如用户的密码。

4、如何应用

一般是在请求头里加入Authorization,并加上Bearer标注:

fetch('api/user/1', {
  headers: {
    'Authorization': 'Bearer ' + token
  }
})

服务端会验证token,如果验证通过就会返回相应的资源。

5、安全相关

  • 不应该在jwt的payload部分存放敏感信息,因为该部分是客户端可解密的部分。
  • 保护好secret私钥,该私钥非常重要。
  • 如果可以,请使用https协议

6、对Token认证的五点认识

  • 一个Token就是一些信息的集合;
  • 在Token中包含足够多的信息,以便在后续请求中减少查询数据库的几率;
  • 服务端需要对cookie和HTTP Authrorization Header进行Token信息的检查;
  • 基于上一点,你可以用一套token认证代码来面对浏览器类客户端和非浏览器类客户端;
  • 因为token是被签名的,所以我们可以认为一个可以解码认证通过的token是由我们系统发放的,其中带的信息是合法有效的;

三、传统的session认证

我们知道,http协议本身是一种无状态的协议,而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证,那么下一次请求时,用户还要再一次进行用户认证才行,因为根据http协议,我们并不能知道是哪个用户发出的请求,所以为了让我们的应用能识别是哪个用户发出的请求,我们只能在服务器存储一份用户登录的信息,这份登录信息会在响应时传递给浏览器,告诉其保存为cookie,以便下次请求时发送给我们的应用,这样我们的应用就能识别请求来自哪个用户了,这就是传统的基于session认证。

但是这种基于session的认证使应用本身很难得到扩展,随着不同客户端用户的增加,独立的服务器已无法承载更多的用户,而这时候基于session认证应用的问题就会暴露出来。

基于session认证所显露的问题

Session: 每个用户经过我们的应用认证之后,我们的应用都要在服务端做一次记录,以方便用户下次请求的鉴别,通常而言session都是保存在内存中,而随着认证用户的增多,服务端的开销会明显增大。

扩展性: 用户认证之后,服务端做认证记录,如果认证的记录被保存在内存中的话,这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源,这样在分布式的应用上,相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。

CSRF: 因为是基于cookie来进行用户识别的, cookie如果被截获,用户就会很容易受到跨站请求伪造的攻击。

基于token的鉴权机制

基于token的鉴权机制类似于http协议也是无状态的,它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了,这就为应用的扩展提供了便利。

流程上是这样的:

  • 用户使用用户名密码来请求服务器
  • 服务器进行验证用户的信息
  • 服务器通过验证发送给用户一个token
  • 客户端存储token,并在每次请求时附送上这个token值
  • 服务端验证token值,并返回数据

这个token必须要在每次请求时传递给服务端,它应该保存在请求头里, 另外,服务端要支持CORS(跨来源资源共享)策略,一般我们在服务端这么做就可以了 Access-Control-Allow-Origin:*。

四、token的优点

  • 支持跨域访问: Cookie是不允许垮域访问的,这一点对Token机制是不存在的,前提是传输的用户认证信息通过HTTP头传输。
  • 无状态(也称:服务端可扩展行):Token机制在服务端不需要存储session信息,因为Token 自身包含了所有登录用户的信息,只需要在客户端的cookie或本地介质存储状态信息。
  • 更适用CDN: 可以通过内容分发网络请求你服务端的所有资料(如:JavaScript,HTML,图片等),而你的服务端只要提供API即可。
  • 去耦: 不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成,只要在你的API被调用的时候,你可以进行Token生成调用即可。
  • 更适用于移动应用: 当你的客户端是一个原生平台(iOS, Android,Windows 8等)时,Cookie是不被支持的(你需要通过Cookie容器进行处理),这时采用Token认证机制就会简单得多。
  • CSRF:因为不再依赖于Cookie,所以你就不需要考虑对CSRF(跨站请求伪造)的防范。
  • 性能: 一次网络往返时间(通过数据库查询session信息)总比做一次HMACSHA256计算 的Token验证和解析要费时得多。
  • 不需要为登录页面做特殊处理: 如果你使用Protractor 做功能测试的时候,不再需要为登录页面做特殊处理。
  • 基于标准化:你的API可以采用标准化的 JSON Web Token (JWT). 这个标准已经存在多个后端库(.NET, Ruby, Java,Python, PHP)和多家公司的支持(如:Firebase,Google, Microsoft)。
  • 因为json的通用性,所以JWT是可以进行跨语言支持的,像JAVA,JavaScript,NodeJS,PHP等很多语言都可以使用。
  • 因为有了payload部分,所以JWT可以在自身存储一些其他业务逻辑所必要的非敏感信息。
  • 便于传输,jwt的构成非常简单,字节占用很小,所以它是非常便于传输的。
  • 它不需要在服务端保存会话信息, 所以它易于应用的扩展。

五、JWT的JAVA实现

Java中对JWT的支持可以考虑使用JJWT开源库;JJWT实现了JWT, JWS, JWE 和 JWA RFC规范;下面将简单举例说明其使用:

1、生成Token码

import javax.crypto.spec.SecretKeySpec;
import javax.xml.bind.DatatypeConverter;
import java.security.Key;
import io.jsonwebtoken.*;
import java.util.Date;    
 
//Sample method to construct a JWT
 
private String createJWT(String id, String issuer, String subject, long ttlMillis) {
 
//The JWT signature algorithm we will be using to sign the token
SignatureAlgorithm signatureAlgorithm = SignatureAlgorithm.HS256;
 
long nowMillis = System.currentTimeMillis();
Date now = new Date(nowMillis);
 
//We will sign our JWT with our ApiKey secret
byte[] apiKeySecretBytes = DatatypeConverter.parseBase64Binary(apiKey.getSecret());
Key signingKey = new SecretKeySpec(apiKeySecretBytes, signatureAlgorithm.getJcaName());
 
  //Let's set the JWT Claims
JwtBuilder builder = Jwts.builder().setId(id)
                                .setIssuedAt(now)
                                .setSubject(subject)
                                .setIssuer(issuer)
                                .signWith(signatureAlgorithm, signingKey);
 
//if it has been specified, let's add the expiration
if (ttlMillis >= 0) {
    long expMillis = nowMillis + ttlMillis;
    Date exp = new Date(expMillis);
    builder.setExpiration(exp);
}
 
//Builds the JWT and serializes it to a compact, URL-safe string
return builder.compact();
}

2、解码和验证Token码

import javax.xml.bind.DatatypeConverter;
import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.Claims;
 
//Sample method to validate and read the JWT
private void parseJWT(String jwt) {
//This line will throw an exception if it is not a signed JWS (as expected)
Claims claims = Jwts.parser()        
   .setSigningKey(DatatypeConverter.parseBase64Binary(apiKey.getSecret()))
   .parseClaimsJws(jwt).getBody();
System.out.println("ID: " + claims.getId());
System.out.println("Subject: " + claims.getSubject());
System.out.println("Issuer: " + claims.getIssuer());
System.out.println("Expiration: " + claims.getExpiration());
}

 

文章整理自:

https://blog.csdn.net/buyaoshuohua1/article/details/73739419

https://www.cnblogs.com/xiekeli/p/5607107.html#top

https://blog.csdn.net/SoftwareOscar/article/details/78538346

https://blog.csdn.net/Jack__Frost/article/details/64964208

http://blog.leapoahead.com/2015/09/06/understanding-jwt/