本发明涉及授权服务器、非暂时性计算机可读介质以及权限委托系统。
背景技术：
近年来，已普遍使用在互联网上部署的所谓云服务。云服务单独公开Web服务API(Application Programming Interface，应用程序接口)，并且可以经由来自其他应用和云服务的API来使用服务所提供的功能。对用于通过Web服务API实现称为OAuth 2.0的授权协作的标准协议的采用正在发展中。在日本特开2015-095056号公报中，公开了使用Web服务API(使用OAuth2.0)的方法的技术。
根据OAuth 2.0，服务B可以例如以由服务A管理的用户所允许的限度，来访问用于获得该用户的数据的API。此时，服务A在明确了服务B的访问限度之后，获得关于服务B访问API的明确的用户授权。用户进行明确授权被称为“授权操作”。此外，在OAuth 2.0中，访问限度被称为“范围(scope)”，并且根据范围决定是否许可访问数据。
当用户进行授权操作时，服务B接收用于证明允许在服务A中的用户许可的限度内对数据的访问的令牌(以下称为“授权令牌”)。在服务B中，可以使用授权令牌来实现此后对服务A的API的访问。通过用户授权操作来授权服务B访问用户资源，被称为“权限委托”。注意，在OAuth2.0中，基于用户授权操作来发布授权令牌的服务器，被称为“授权服务器”。另外，公开API的服务器被称为“资源服务器”，并且调用API的代理(agent)称为“客户端”。
在OAuth 2.0中，授权服务器和资源服务器可以被构造在同一台服务器上，但是在有多个资源服务器的大型系统中，授权服务器通常被构造为独立的服务器。在这种情况下，服务A向授权服务器发出请求，以验证每当从服务B使用API时获得的授权令牌。然后，基于验证结果，决定是否许可使用API。这里存在的问题在于，在大型系统中，负荷集中在授权服务器上。对于这个问题，已经研究了使用署名授权令牌作为验证授权令牌自身的手段，而无需服务A向授权服务器发出验证请求。服务A通过验证接收到的署名授权令牌的署名，可以确定授权令牌是否有效，而无需利用授权服务器进行确认。
在使能权限委托的协议中，存在如下可能性：缺乏与改变服务中的资源和改变用户的权限相对应的灵活性。例如，OAuth 2.0授权令牌假定仅针对当用户进行授权操作时确认的范围作出权限委托。因此，在用户可以进行权限委托的范围被改变的情况下，以及当API使用的范围有所增大/减小/改变时，存在为了使用API，用户将被迫再次进行授权操作的可能性，因此便利性可能变差。
技术实现要素：
鉴于上述问题构思了本发明，并且本发明提供了可以改变用户权限或范围限定而不损害用户便利性的权限委托系统。
根据本发明的一个方面，提供了一种授权服务器，所述授权服务器包括：接收单元，其被构造为从客户端接收授权请求，在所述授权请求中指定有范围组，限定使用Web服务的限度的一个或多个范围与所述范围组相关联；呈现单元，其被构造为，在与范围组相关联的所述一个或多个范围当中的一个或更多个范围包括在用户具有的权限的限度内的情况下，向用户呈现用于接受与授权请求相对应的授权操作的画面；第一发布单元，其被构造为，根据经由所述画面接受与授权请求相对应的用户的授权操作，向客户端发布与范围组相关的授权信息；以及第二发布单元，其被构造为，根据基于由第一发布单元发布的授权信息接受授权令牌请求，发布与范围组相对应的授权令牌。
根据本发明的另一方面，提供了一种权限委托系统，所述权限委托系统包用于提供Web服务的资源服务器以及授权服务器，其中所述授权服务器包括：接收单元，其被构造为从客户端接收授权请求，在所述授权请求中指定有范围组，限定使用Web服务的限度的一个或多个范围与所述范围组相关联；呈现单元，其被构造为，在与范围组相关联的所述一个或多个范围当中的一个或更多个范围包括在用户具有的权限的限度内的情况下，向用户呈现用于接受与授权请求相对应的授权操作的画面；第一发布单元，其被构造为，根据经由所述画面接受与授权请求相对应的用户的授权操作，向客户端发布与范围组相关的授权信息；以及第二发布单元，其被构造为，根据基于由第一发布单元发布的授权信息接受授权令牌请求，发布与范围组相对应的授权令牌，并且所述资源服务器包括：接受单元，其被构造为接受使用授权令牌作出的Web服务使用请求；授权令牌验证单元，其被构造为进行授权令牌的验证；以及提供单元，其被构造为，基于授权令牌验证单元的验证结果来提供Web服务。
根据本发明的另一方面，提供了一种非暂时性计算机可读介质，所述非暂时性计算机可读介质存储用于使计算机用作如下单元的程序：接收单元，其被构造为从客户端接收授权请求，在所述授权请求中指定有范围组，限定使用Web服务的限度的一个或多个范围与所述范围组相关联；呈现单元，其被构造为，在与范围组相关联的所述一个或多个范围当中的一个或更多个范围包括在用户具有的权限的限度内的情况下，向用户呈现用于接受与授权请求相对应的授权操作的画面；第一发布单元，其被构造为，根据经由所述画面接受与授权请求相对应的用户的授权操作，向客户端发布与范围组相关的授权信息；以及第二发布单元，其被构造为，根据基于由第一发布单元发布的授权信息接受授权令牌请求，发布与范围组相对应的授权令牌。
通过本发明，在用户权限在范围组的限度内变化的情况下，用户可以继续使用API而不被强制再次进行授权操作。
从以下(参考附图)对示例性实施例的描述，本发明的其它特征将变得清楚。
附图说明
图1是例示根据本发明的权限委托系统的构造的示例的图。
图2是例示根据本发明的硬件构造的示例的图。
图3A和图3B是例示根据本发明的软件构造的示例的图。
图4是例示OAuth 2.0序列的示例的图。
图5是例示根据本发明的登录画面的构造的示例的图。
图6A、图6B和图6C是例示根据本发明的各种表的构造的示例的图。
图7A和图7B是例示根据本发明的各种表的构造的示例的图。
图8是例示OAuth 2.0刷新序列的示例的图。
图9是根据本发明的范围验证处理的流程图。
图10A和图10B是例示根据本发明的授权确认画面的构造的示例的图。
图11是例示署名授权令牌的示例的图。
图12是根据本发明的授权令牌验证处理的流程图。
图13是根据本发明的权限验证处理的流程图。
图14A和图14B是例示根据本发明的权限和范围改变的时间序列的图。
具体实施方式
如上所述，由于从终端访问的资源的限度(具体地，限定了服务使用的限度的范围)和用户权限改变，所以要求诸如OAuth 2.0的权限委托协议的灵活性。首先，将描述改变范围和用户权限。在企业领域，用户所具有的权限根据用户的职位而不同。例如，根据用户是否处于可以访问包括公司的特定级别的保密性的信息的职位，用户所具有的权限存在差异。换句话说，可以设想，针对指示服务中的资源的限度的范围来限定用于使能访问的权限，并且操作使得为特定用户添加权限。注意，由于各种原因，用户权限将酌情改变，这是因为用户的职位将根据其在公司中的角色改变或服务的改变而改变。换句话说，特定时间点的用户权限以及之后的时间点的用户权限将变化，并且用户可以对服务进行权限委托的范围的限度也将改变。
同时，在云服务中，称为持续集成、持续交付和持续部署的方法和架构已经受到关注，其中，在短的时间间隔内发布(realease)新功能。此外，由于提供了各种工具、开发处理和设计方法，预计在短的时间间隔内发布新功能将变得更加普遍。在短时间间隔内发布意味着在短的时间间隔内进行增加Web服务API的数量、扩展这些API处理的数据的限度或改变限度。
换句话说，可以设想，将进行由于用户的权限的改变，可以由用户权限委托的范围的改变、根据短周期发布的范围的增大/减小以及范围的限定的改变。在出现所述情况并且进行权限委托并且已经发布授权令牌的情况下，需要通过使用户再次进行授权操作来发布与用户权限的改变和/或范围的改变相对应的授权令牌。
本发明省却了授权操作的努力，并且增加了方便性，并且使能与用户权限改变和/或范围改变相对应的授权令牌操作。在本发明中，使用署名授权令牌作为授权令牌。另外，使用JWT(JSON Web Token)和JWS(JSON Web Signature)作为其方案。
在下面描述的实施例中，服务是指根据来自客户端的请求，由正在执行的服务器上激活的软件提供给客户端的功能。注意，存在作为软件的Web应用也称为服务的情况。在实施例中，该描述假定存在资源服务器所提供的服务作为云服务，并且用户经由终端使用资源服务器提供的服务。此外，客户端是在终端上激活的软件。客户端被构造为能够经由终端包括的Web浏览器访问服务，或者被构造为使得可以激活/控制包括Web浏览器功能的软件。此外，该描述假定资源服务器将API公开为Web服务，并且通过使用这些API的客户端向用户提供服务。
注意，不对上述假定做出限制，并且客户端可以被构造为与资源服务器协作的另一服务。此外，资源服务器和终端不需要限于单个构造。例如，由多个设备构造的一组服务器可以提供服务。因此，本发明中对服务器的提及包括由一个或多个设备构造的一组服务器的情况。
为了客户端使用资源服务器API，需要后面将描述的、伴随通过OAuth 2.0Authorization Code Grant(授权代码授权)的用户授权操作的权限委托。换句话说，接收到来自用户的权限委托的客户端被使得能够使用资源服务器的API。
接下来，描述在本发明的实施例中使用的资源服务器提供的服务的示例。资源服务器包括根据来自未示出的多功能外围设备或打印机(以下称为设备)的请求，分发要被分发到设备的各种数据的功能。换句话说，资源服务器提供分发设备设置值的服务。这里，各种数据可以是用于决定设备如何操作的设置值、要安装在设备上的固件或应用信息或者可以在设备上设置的可选功能。此外，可以包括指示应该按什么顺序设置各种数据的控制信息、用于安装应用的许可证信息等。在实施例中，这些设置值、设置值控制信息和许可证被限定为资源。
此外，在实施例中，将包括以下的某物描述为客户端应用功能的示例。客户端应用包括用于生成要分发到设备的各种数据并将其作为各个设备的数据上传到资源服务器的功能。
下面，使用附图描述本发明的实施例。
[系统构造]
在图1所示的构造的网络上实现根据本实施例的权限委托系统。WAN(Wide Area Network，广域网)100是外部网络，在本发明中构造了WWW(World Wide Web，万维网)系统。LAN(Local Area Network，局域网)101是内部网络，并且多个LAN 101经由WAN 100连接。在图1的构造示例中，授权服务器200和资源服务器300位于同一LAN 101中，并且经由WAN 100连接到终端400所位于的LAN 101。
授权服务器200是用于实现OAuth 2.0的服务器，并且其中安装了授权服务器模块。在资源服务器300中，安装有包括公开为Web服务的API的资源服务器模块。终端400包括Web浏览器410和客户端应用420。终端400例如对应于PC(Personal Computer，个人计算机)或被称为智能电话的移动终端。客户端应用420通过使用资源服务器300所包括的资源服务器模块公开的API，向用户提供与其本身提供的功能一起的服务。终端400使用Web浏览器410与授权服务器200进行通信。
授权服务器200和资源服务器300经由LAN 101连接。注意，构造可以使得授权服务器200和资源服务器300经由WAN 100而不是LAN 101连接。另外，授权服务器200、资源服务器300和终端400各自被连接以能够经由WAN 100进行通信。此外，可以采取这样的构造：使得授权服务器200经由LAN 101与数据库服务器(未示出)连接，并且使得授权服务器模块使用的数据被存储在授权服务器中。此外，资源服务器300和授权服务器200可以被构造为在物理上处于同一服务器上。
例如，在如图2所示的构造的信息处理装置中实现根据本实施例的权限委托系统的构造要素。图2例示了授权服务器200、资源服务器300和终端400的硬件构造的示例。注意，针对实施例的服务器和终端，不对图2的构造做出限制。例如，可以应用信息处理装置的典型硬件构造和提供为IaaS(Infrastructure as a Service，基础架构即服务)的信息处理装置的虚拟硬件构造。
CPU 2001执行诸如OS(Operating System，操作系统)或应用的程序来控制连接到系统总线2004的各个块。各种程序存储在ROM 2003的程序ROM和诸如硬盘(HD)的外部存储器2011中，并且这些程序被加载到RAM 2002中并被执行。通过执行各种程序来实现稍后描述的处理序列中的各个。
RAM 2002用作CPU 2001的主存储器和工作区域等。键盘控制器(KBC)2005控制来自键盘2009和指示设备(未示出)的键输入。CRT控制器(CRTC)2006控制CRT显示器2010的显示。磁盘控制器(DKC)2007控制诸如存储各种数据的硬盘(HD)的外部存储器2011中的数据访问。网络控制器(NC)2008执行用于控制与经由WAN 100和LAN 101连接的其他设备的通信的处理。注意，在提供为IaaS的虚拟信息处理装置的情况下，不包括KBC 2005和CRTC 2006，并且构造使得从包括在经由NC 2008连接的终端中的键盘2009和CRT显示器2010进行操作。
注意，在整个以下描述中，除非另有指定，否则服务器和终端中的执行的硬件代理是CPU 2001，并且软件代理是安装在外部存储器2011中的应用程序。
图3A和图3B是分别例示根据本实施例的授权服务器200和资源服务器300的模块构造的示例的图。通过执行模块提供服务。注意，仅例示了根据本实施例的模块，并且省略了其他模块。权限委托系统中的各个装置所具有的软件模块通过各装置中的CPU 2001执行加载到RAM 2002上的程序来实现。
如图3A所示，授权服务器200包括授权服务器模块210和HTTP服务器模块220。HTTP服务器模块220是用于与安装在经由WAN连接的终端400中的Web浏览器410和客户端应用420进行HTTP通信的模块。此外，HTTP服务器模块220被构造为使得可以通过SSL/TLS进行通信，并且包括证书存储区(未示出)。此外，在本实施例中，在稍后描述的授权请求被接受的情况下，通过认证信息(用户ID和密码)向请求源发出用户认证请求。
授权服务器模块210是在HTTP服务器模块220之上操作或与之协作的Web应用。授权服务器模块210经由HTTP服务器模块220接受来自Web浏览器410的请求，执行与该请求对应的处理，并对其做出响应。在本实施例中，在HTTP服务器模块220中接受用户认证。然后，构造使得在请求源认证成功的情况下，授权服务器模块210生成认证用户信息与之相关联的授权令牌，并且向授权服务器模块210通知授权令牌。授权令牌是指示用户被认证并且用户登录的令牌，或者是用于验证用户是否被认证的令牌。可以通过使用授权令牌来识别用户。稍后描述的授权代码是指示通过使用用户成为用户的权限，客户端(通过认证用户的授权操作对其进行权限委托)被许可访问的信息。因此，授权令牌和授权代码的预期用途是不同的。特别地，在授权令牌的情况下，目的是确认用户，而在授权代码的情况下，目的是确认权限。
此外，授权令牌是由客户端使用授权代码获得并且指示客户端具有使用API的权限的令牌。授权服务器模块210具有用于署名授权令牌的私有密钥。可以使用私有密钥署名授权令牌，然后发布署名授权令牌。此外，刷新令牌是使用授权代码类似地获得并且指示可以再发布授权令牌的令牌。稍后将描述HTTP服务器模块220和授权服务器模块210中的处理细节。
授权服务器模块210经由LAN 101从资源服务器模块310接收对授权令牌的权限验证处理请求。授权服务器模块210被构造为然后根据该请求进行处理，并且作出与是否许可由客户端访问资源服务器300有关的响应。该授权令牌权限验证处理可以被构造为RPC(Remote Procedure Call，远程过程调用)，并且可以被构造为可以经由HTTP服务器模块220经由LAN 101或WAN 100进行通信的Web服务的API。
如图3B所示，资源服务器300包括资源服务器模块310。资源服务器模块310可以被构造为在HTTP服务器模块(未示出)上操作。资源服务器模块310包括作为Web服务公开的API，并且其具体示例如前所述。资源服务器模块310接受来自客户端应用420的资源请求(使用请求)，根据该请求进行处理，对其进行响应。
此外，资源服务器模块310保持在验证授权服务器模块210中发布的署名授权令牌的署名时使用的公开密钥。替代性地，资源服务器模块310可以被构造为经由由授权服务器模块210公开并且用于在验证署名时获得要使用的公开密钥的API来获得公开密钥。资源服务器模块310在接收到的授权令牌是署名授权令牌的情况下，通过使用该公开密钥验证署名来确认授权令牌的有效性。此外，根据情况，资源服务器模块310可以向授权服务器模块210发出对稍后描述的授权令牌权限验证处理的请求。
[处理序列]
接下来，使用图4-图7B，描述直到客户端应用420使用资源服务器模块310公开的API的本实施例的序列。注意，在序列图中，“Ref”指示参考，并且将用另一个图来说明其细节。此外，“Alt”指示分支，并根据先前序列的结果来指示分支处理。此外，“Opt”指示在先前处理的结果满足条件的情况下执行的处理。
首先，图6A和图6B中例示了根据本实施例的授权服务器模块210的用户表和客户端表的数据示例。
在本实施例中，如图6A所示，“admin@xx.com”和“user@xx.com”在用户表中登记为用户，并分别设置所详述的权限。
在本实施例中，如图6B所示，客户端ID为“c001@xx.com”的客户端登记在客户端表中。下面将描述如何使用各个参数。
另外，在图6C中例示根据本实施例的授权服务器模块210的范围限定表的数据示例。
在本实施例中，作为用户权限，限定了管理员权限、设置值编辑者权限、设置值参照者权限和设备设置者权限。管理员权限是可以进行与设置值相关的所有前述操作的权限。设置值编辑者权限是可以编辑设置值的权限。设置值参照者权限是可以参照设置值的权限。设备设置者权限是用于指定向其反映设置值的、诸如多功能外围设备或打印机的设备的信息被设置为设置值的权限。通常，权限和范围被相关联地限定，并且可以根据范围决定数据能够被访问的限度。范围限定资源服务器模块310提供的服务被使用的限度，并且由此决定是否许可访问数据。
例如，在限定了与设置值参照者权限对应的“读取”范围的情况下，客户端应用420可以通过使用“读取”范围来执行权限委托协议，从而获得对应于“读取”范围的授权令牌。然后，通过使用授权令牌，可以使用API来参照资源服务器模块310的各种设置值。但是，用该授权令牌，不能使用API来编辑设置值。为了使客户端应用420编辑设置值，需要通过指定与设置值编辑者权限对应的“编辑”范围来获得授权令牌。这里，可以考虑在执行权限委托协议时，将“读取”和“编辑”范围指定给客户端应用420。然而，在没有为用户自己添加设置值编辑者权限的情况下，授权确认处理导致错误，并且不能获得授权令牌。
因此，在本实施例中，在多个范围分组在一起的情况下，许可在授权确认处理中授权令牌发布的范围组的限定，并且在与组中的范围对应的权限当中的至少一个权限被保持。更具体地，例如，如图6C的第一行所示，限定了将范围“管理”，“编辑”，“读取”和“设备”分组在一起的、称为“组”的范围组。因为“组”与图6C所指示的所有范围相关联，被提供组权限的用户可以使用资源服务器模块310在当前时刻提供的所有功能。然后，通过指定“组”范围并执行权限委托协议，可以使仅保持设置值参照者权限的用户获得授权令牌。
然而，由于用户未保持设置值编辑权限，即使使用通过指定“组”获得的授权令牌，用户也不能够使用用于编辑资源服务器模块310的设置值的API。因此，授权服务器模块210针对授权令牌，署名仅记载在用户当前保持的权限的限度内的范围。此外，授权服务器模块210每次接收到授权令牌刷新时，都署名仅记载用户在该时间点保持的权限的限度内的范围。通过该范围组处理，即使用户自己的权限做出改变，如果通过指定“组”来获得授权令牌，则可以使用伴随刷新的用户的权限相对应的API。
此外，考虑到如下情况：在资源服务器模块310中新添加例如用于改变设置值控制顺序的、要求范围“顺序”的API，并且在资源服务器模块210中添加范围限定“顺序”。通常，需要再次执行指定“顺序”范围的权限委托协议。与此相对照，“顺序”范围与范围组“组”相关联地限定。通过该构造，只要向用户添加权限，将可以通过刷新通过指定“组”获得的授权令牌，来使用令牌使用用于改变设置值控制顺序的API。
注意，根据接收请求，授权服务器模块210在范围限定表中限定新的范围。这里，为了结合调用添加到资源服务器300的新功能的API的实现，限定与API相对应的新范围，发送请求。此时，可以将新范围与“组”相关联，并且根据情况，可以不将新范围与“组“相关联。可以从具有与终端400相同构造的计算机(未示出)发送限定新范围的请求。下面将详细描述这些处理。
如图6A所示，在本实施例的序列中描述的用户被描述为使用用户ID“user@xx.com”及其密码。
此外，如图6B所示的序列中描述的客户端应用420具有客户端ID“c001@xx.com”的各种数据：秘密和重定向URI。重定向URI是客户端应用420接受授权响应的URI(Uniform Resource Identifier，统一资源标识符)。这些数据必须预先登记在授权服务器模块210中，但是，作为登记手段，可以考虑使用画面(未示出)的方法和用于由授权服务器模块210公开的API执行的手段。如图6B所示，这些手段的结果是登录客户端ID为“c001@xx.com”的客户端。
在步骤S1.1中，用户在Web浏览器410上执行协作开始操作(未示出)。该协作开始操作例如可以经由配设在客户端应用420中的各种操作画面(未示出)来进行。
在步骤S1.2中，在Web浏览器410中，向客户端应用420通知协作开始。注意，在步骤S1.1和步骤S1.2的处理中，可以采取构造，使得用户从客户端应用420进行操作，并且客户端应用420调用Web浏览器410。
在步骤S1.3中，客户端应用420在接收到协作开始请求之后，经由Web浏览器410和HTTP服务器模块220向授权服务器模块210发出授权请求。在本实施例中，将基于在OAuth 2.0中限定的授权代码授权(Authorization Code Grant)流程作为权限委托协议来描述本发明的构造。注意，在授权请求中，至少包括先前描述的客户端应用420保持的客户端ID“c001@xx.com”和重定向URI“https：//localhost：xx”。具体地，在授权请求中包括指示针对客户端应用420做出的、来自用户的权限委托的资源的限度的范围。这里，分别说明指定范围“读取”的情况和指定范围组“组”的情况。注意，重定向URI是用于接受在授权服务器200处发布的授权代码的客户端应用420的URL。
在步骤S1.4中，HTTP服务器模块220在从Web浏览器410接受授权请求之后，验证在来自Web浏览器410的通知中是否包括作为HTTP Cookie的有效授权令牌。如果包括有效授权令牌，HTTP服务器模块220向授权服务器模块210通知授权令牌，并转移到步骤S1.9。如果不包括有效授权令牌，则执行步骤S1.5至S1.8的处理。
在步骤S1.5中，HTTP服务器模块220向Web浏览器410响应用于用户认证的登录画面500。图5例示了HTTP服务器模块220响应的登录画面500的构造的示例。在本实施例中，构造被使得用户输入用户ID和密码，并且在用户ID和密码集合与登记在授权服务器模块210的用户表中的信息的集合匹配的情况下被认证。注意，例如可以构造用于认证用户的其他手段，诸如X.509证书、或者多次输入密码的多级认证，并没有特别的限制。
图5中所示的登录画面500被构造为包括输入用户ID的用户ID输入字段501、输入密码的密码输入字段502和用于执行登录操作的登录按钮503。
在步骤S1.6中，用户将必要的信息输入到在Web浏览器410上显示的登录画面500中，并按下登录按钮503。这里，该描述假定用户ID“user@xx.com”和密码“user”被输入。
在步骤S1.7中，Web浏览器410将输入的信息(用户ID和密码)作为登录请求发送到HTTP服务器模块220。
在步骤S1.8中，HTTP服务器模块220获得用户ID和密码，与用户表的用户ID和密码信息的集合进行比较(图6A)，并且通过验证上述内容是否匹配来认证用户。注意，如果HTTP服务器模块220在用户认证时失败，换句话说，输入的信息没有被登记在用户表中，则HTTP服务器模块220向Web浏览器410响应认证错误画面(未示出)。这里，与认证错误画面一起，再次显示登录画面500。在用户认证成功的情况下，HTTP服务器模块220生成授权令牌。该授权令牌被与授权服务器200的非易失性存储器上的用户ID相对应的UUID(Universal Unique Identifier，通用唯一标识符)相关联地保存。UUID是不重复的唯一ID(识别信息)。这里，与用户ID“user@xx.com”对应的UUID“10000001”被与该用户ID相关联地保存。
在步骤S1.9中，HTTP服务器模块220向授权服务器模块210通知生成的授权令牌，并进一步进行授权请求。注意，该授权令牌被设置为HTTP Cookie，在从HTTP服务器模块220对Web浏览器410的响应中设置，并由此通知。在下文中，当从Web浏览器410访问授权服务器模块210时，执行通过上述HTTP服务器模块220的授权令牌验证、授权处理和授权令牌通知，因此省略其说明。
在步骤S1.10中，授权服务器模块210在接收到包括授权令牌的授权请求之后，验证所接收到的授权请求中设置的客户端ID和重定向URI是否正确。具体地，授权服务器模块210验证所接收到的授权请求的信息是否与登记在客户端表中的一对客户端ID和重定向URI匹配(图6B)。在没有匹配的情况下，授权服务器模块210经由HTTP服务器模块220向Web浏览器410响应错误画面(未示出)。在匹配的情况下，授权服务器模块210在步骤S2.1中执行范围验证处理。稍后将使用图9描述范围验证处理的细节。
授权服务器模块210在范围验证处理(步骤S2.1)的结果为“具有权限”响应的情况下，在步骤S1.11中执行授权确认处理。作为授权确认处理，授权服务器模块210向Web浏览器410响应授权确认画面。
图10A是在指定不是范围组的范围的情况下，由授权服务器模块210的响应做出的授权确认画面1000的构造的示例。另外，图10B是在指定范围组的情况下作为由授权服务器模块210的响应而做出的授权确认画面1100的构造的示例。相同的附图标记被添加到这些画面之间共有的部分。授权确认画面1000和1100包括访问源显示区域1001，该访问源显示区域1001是显示从客户端表获得的客户端名称的区域，在该客户端表中，包括在授权请求中的客户端ID是密钥。此外，授权确认画面1000和1100包括委托权限显示区域1002，该委托权限显示区域1002是显示与在授权请求中获得的范围相对应的描述的区域。
在实施例的情况下，如图6C所示，对应于由资源服务器模块310提供的服务中的所有功能的范围与指示范围组的“组”相关联。因此，在授权确认画面1100中，描述了与所有范围相对应的权限当中、用户所保持的权限在权限委托的限度内。注意，不一定需要在授权确认画面上显示与所有范围相对应的权限当中、用户所保持的权限在权限委托的限度内。然而，在不显示的情况下，需要显示存在下述可能性：客户端应用420将在与范围组相关联的一个或多个范围的限度内(管理、编辑、读取或设备的限度)使用资源服务器模块310提供的Web服务。此外，授权确认画面1000和1100包括用户执行用于授权上述信息中描述的内容的操作的许可按钮1003和用于执行拒绝上述内容的操作的拒绝按钮1004。此外，如图10B所示，授权确认画面1100包括范围组描述区域1101。范围组描述区域1101是用于描述在指定范围组的情况下，在委托权限显示区域1002中指示的被委托的权限的限度根据用户的权限的改变而动态地改变的区域。
根据来自授权服务器模块210的响应，Web浏览器410向用户呈现获得的授权确认画面1000或授权确认画面1100。此外，在用户按下许可按钮1003或拒绝按钮1004的情况下，Web浏览器410获得授权确认结果并通知授权服务器模块210。
授权服务器模块210从Web浏览器410获得授权确认结果。此外，在所获得的授权确认结果为“许可”的情况下，授权服务器模块210以“许可响应”的授权确认处理结果结束授权确认处理(步骤S1.11)。同时，在授权确认结果为“拒绝”的情况下，授权服务器模块210以“拒绝响应”的授权确认处理结果结束授权确认处理(步骤S1.11)。
接下来，在授权服务器模块210中，授权确认处理的结果(步骤S1.11)为“许可响应”的情况的序列将被描述。具体地，图4的步骤S3.1至步骤S3.15的处理被执行。
在步骤S3.1中，授权服务器模块210发布授权代码。具体地，授权服务器模块210发布令牌标识符“cd_000001”或“cd_000002”。此外，授权服务器模块210登记授权请求中包括的客户端ID“c001@xx.com”和重定向URI“https：//xx/res”、范围和与令牌表中的认证用户的用户ID对应的UUID“10000001”(图7A)。此时，授权服务器模块210将令牌类型视为授权代码，并将授权代码直到其有效的到期日期和时间记录为有效期。
在图7A中，例示了授权服务器模块210的令牌表的示例。在图7A中，指示令牌是否有效的状态被登记为“有效”，但是可以采取每次通过验证有效期来确认有效性的构造。作为范围，设置“读取”或作为范围组的“组”。
在步骤S3.2和步骤S3.3中，授权服务器模块210通过添加令牌标识符“cd_000001”或“cd_000002”(其是发布的授权代码)，经由Web浏览器410向客户端应用420响应授权。具体地，授权服务器模块210响应于Web浏览器410，使得Web浏览器410被重定向到在授权请求时获得的重定向URI“https：//localhost：xx”。
在步骤S3.4中，客户端应用420在从Web浏览器410接收到授权响应之后，向授权服务器模块210发出授权令牌的请求。至少在授权请求时发送的所获得的授权代码“cd_000001”或“cd_000002”、客户端ID“c001@xx.com”、秘密“xxxxxxxxxx”以及重定向URI“https：//localhost：xx”被包括在授权令牌请求中。
在步骤S3.5中，授权服务器模块210利用所获得的客户端ID“c001@xx.com”和秘密“xxxxxxxxxx”的集合来认证客户端。具体地，授权服务器模块210通过验证所获得的信息是否与客户端表中的集合相匹配来进行认证(图6B)。这里，如果客户端认证失败，则授权服务器模块210向客户端应用420响应认证错误。
如果客户端认证成功，则在步骤S3.6中，授权服务器模块210验证获得的授权代码“cd_000001”或“cd_000002”。作为授权代码的验证，授权服务器模块210确认所获得的授权代码是否被登记在令牌表(图7A)中，并且如果授权代码被登记，则进一步验证授权代码是否有效。此外，授权服务器模块210验证在授权令牌请求中获得的客户端ID“c001@xx.com”和重定向URI“https：//localhost：xx”是否与令牌表(图7A)中的客户端ID和重定向URI相匹配。在授权代码验证的结果为“无效”的情况下，授权服务器模块210向客户端应用420做出不合适令牌错误的响应。同时，在授权代码验证的结果为“有效”的情况下，授权服务器模块210针对与授权代码相关联的范围执行步骤S2.1的范围验证处理。稍后将使用图9描述范围验证处理的细节。
在范围验证处理(步骤S2.1)的结果为“具有权限”的情况下，则在步骤S3.7中，授权服务器模块210发布授权令牌。具体地，授权服务器模块210发布令牌标识符“at_000001”或“at_000002”，并登记与授权代码相关联的用户UUID“10000001”，范围“读取”或“组”以及令牌表中的认证客户端ID“c001@xx.com”。此时，授权服务器模块210将令牌类型视为“授权令牌”，并将授权令牌直到其有效的到期日期和时间登记为有效期。
接下来，授权服务器模块210从该信息生成JWT，并计算署名值。图11是作为令牌标识符“at_000002”的授权令牌生成的JWT的示例。在示例中，图示中包括新的行和缩进，以便更容易看到。在有效载荷中，将登记在令牌表中的令牌标识符设置为“jti”，将用户的UUID设置为“sub”，将客户端ID设置为“azp”，并将有效期设置为“exp”。此外，将用户具有在先前的处理中获得的权限的一个或多个范围设置为“范围”中的“拥有者”。在令牌表中登记的范围是范围组的情况下，可以额外地在“范围”中的“组”下设置该范围。此外，针对所生成的JWT，授权服务器模块210通过使用其保存的私有密钥来生成并添加根据JWS的署名值(署名信息)。
在图11中的编码(Encoded)下，例示了实际生成的署名授权令牌的示例。但是，署名值被省略。注意，在JWT中设置的各项目不限于所记载的项目，并且例如，令牌变为有效的日期和时间可以被设置为“nbf”，并且发布令牌的时间可以被设置为“iat”。
在步骤S3.8中，授权服务器模块210发布刷新令牌。具体地，授权服务器模块210发布令牌标识符“rt_000001”或“rt_000002”。此外，授权服务器模块210在令牌表中登记与各个授权令牌相关联的用户的UUID“10000001”、范围和认证的客户端ID。此时，令牌类型为“刷新令牌”，并且将刷新令牌直到其有效的日期和时间登记为有效期。注意，在OAuth2.0的情况下，由于建议控制使得授权代码只能使用一次，因此令牌标识符“cd_000001”和“cd_000002”的授权代码的状态为“无效”。作为使代码无效的处理，代替改变状态的值，可以采取通过将有效期更新为过去的日期和时间来将代码视为无效的构造，并且可以采取通过删除表记录本身来使代码无效的构造。
在图7B中，例示了授权服务器模块210的令牌表的示例。在该示例中，示出了相对于图7A所示的授权服务器模块210的令牌表添加和改变数据的状态。
在步骤S3.9中，授权服务器模块210以署名授权令牌来响应于客户端应用420，其中，针对该署名授权令牌，署名被添加到授权令牌的发布的令牌标识符“at_000001”或“at_000002”以及刷新令牌的令牌标识符“rt_000001”或“rt_000002”。
在步骤S3.10中，客户端应用420在获得授权令牌之后，对资源服务器模块310所公开的API发出资源请求。这里，描述假定调用用于使用相应的署名授权令牌参照设置值的API。
在步骤S3.11中，资源服务器模块310在接收资源请求之后，进行授权令牌验证处理。图12是资源服务器模块310中的授权令牌验证处理。
在步骤S1201中，资源服务器模块310确定对其发出资源请求的资源是对其进行授权验证的资源本身，还是应当向授权服务器模块210发出验证请求的资源。在确定应当向授权服务器模块210请求验证的情况下(步骤S1201为“否”)，进行步骤S3.12的授权验证请求处理。在确定要进行授权验证本身的情况下(步骤S1201中为“是”)，则进行到步骤S1202。
在该确定中，例如，要求管理员权限的资源是应当确认在该时间点是否存在权限的资源。另一方面，对于署名授权令牌，如果在发布时有在所设置的有效期内的权限，则即使权限在资源请求时已经丢失，也存在将许可访问资源的风险。因此，根据为署名授权令牌设置的有效期以及如何严格地管理资源访问所需的权限做出步骤S1201中的确定。
例如，考虑权限本身花钱的情况，对可以添加的权限的数量存在限制。在这种情况下，当署名授权令牌的有效期足够长时，通过重复在署名授权令牌发布之后移除权限，然后在向另一个用户添加权限之后发布署名授权令牌的处理，对可以添加的权限的数量低的限制变得毫无意义。关于这样的问题，切换是对本身进行验证，还是向授权服务器模块210发出验证请求。作为这里的确定标准，在预定Web服务使用需要安全性和严格性的情况下，可以考虑向授权服务器模块210发出请求。
在步骤S1202中，资源服务器模块310确认在发出资源请求时添加的授权令牌是否是署名授权令牌。在不是署名授权令牌的情况下(步骤S1202中为“否”)，执行步骤S3.12的权限验证请求处理。在是署名授权令牌的情况下(步骤S1202中为“是”)，则进行到步骤S1203。注意，在授权服务器模块210仅发布署名授权令牌的情况下，可以省略该处理。
在步骤S1203中，资源服务器模块310使用其保持的公开密钥或其从授权服务器模块210获得的公开密钥来验证接收到的署名授权令牌的署名。
在步骤S1204中，资源服务器模块310确定署名是否正确，以及其授权令牌是否在有效期内。在条件不满足的情况下(步骤S1204中为“否”)，做出步骤S3.15的错误响应。同时，在满足条件的情况下(步骤S1204中为“是”)，则进行到步骤S1205。
在步骤S1205中，资源服务器模块310确定所请求的资源是否在令牌中记载的范围的限度内。此时，资源服务器模块310基于被缩小到被保持的权限而不是范围组的范围做出确定。具体地，使用图11中的JWT的示例，使用“范围”的“所有者”中所记载的范围做出确定。在确定资源在范围的限度内的情况下(步骤S1205中为“是”)，转移到步骤S3.14的资源获得。在确定不在限度内的情况下(步骤S1205中为“否”)，做出步骤S3.15的错误响应。
接下来，描述在资源服务器模块310的授权令牌验证处理(步骤S3.11)中确定要在授权服务器模块210中进行授权验证的情况的处理。
在步骤S3.12中，资源服务器模块310向授权服务器模块210发出授权验证的请求。此时，资源服务器模块310将获得的授权令牌“at_000001”或“at_000002”以及作为验证目标的所请求资源的范围的“读取”传递给授权服务器模块210。
在步骤S4.1中，授权服务器模块210进行权限验证处理。稍后将使用图13描述根据授权服务器模块210的权限验证处理的细节。
在步骤S3.13中，资源服务器模块310从授权服务器模块210获得权限验证处理的结果(步骤S4.1)。
如果结果是许可，则资源服务器模块310在步骤S3.14中获得资源，具体地获得所请求的设置值。
在步骤S3.15中，资源服务器模块310向客户端应用420响应资源。注意，如果权限验证的结果是拒绝，则资源服务器模块310跳过步骤S3.14并且向客户端应用420响应错误。
接下来，在授权服务器模块210中，将描述用于授权确认处理(步骤S1.11)的结果为“拒绝响应”的情况的序列。具体地，进行图4中的步骤S5.1到步骤S5.2的处理。
在步骤S5.1和步骤S5.2中，授权服务器模块210经由Web浏览器410向客户端应用420响应拒绝。更具体地，授权服务器模块210响应于Web浏览器410，使得Web浏览器410被重定向到在授权请求时获得的重定向URI“https：//localhost：xx”。
以上是本实施例的序列，其使用权限委托协议，该权限委托协议继续直到客户端应用420使用资源服务器模块310公开的API。注意，使用OAuth 2.0的授权代码授权的示例描述了用于发布授权令牌的处理，但如果是权限委托协议，则不对此进行限制。例如，不一定需要发布授权代码，并且只要最终发布作为授权信息的授权令牌就足够了。
[刷新顺序]
接下来，使用图8，将描述根据本实施例的客户端应用420刷新授权令牌并且使用资源服务器模块310公开的API的刷新序列。注意，图8中的“Alt”指示分支，并且指示根据前述序列的结果的分支处理。此外，“Opt”是指可选的，并且可以省略处理。注意，对于与图4所示的处理相同的处理，添加相同的附图标记，并且省略其描述。
存在从步骤S6.1的用户操作开始该序列的情况，以及客户端应用420在其自身的处理期间开始该序列的情况。为此，将步骤S6.1和步骤S6.2记载为可选的。
在步骤S6.1中，用户在Web浏览器410上进行再执行操作(未示出)。该再执行操作例如可以经由配设在客户端应用420中的各种操作画面(未示出)来进行。
在步骤S6.2中，在Web浏览器410中，向客户端应用420发出再执行请求。客户端应用420在接收到该再执行请求之后，使用已经获得的授权令牌针对资源服务器模块310公开的API发出资源请求。这里，描述假定授权令牌是无效的。注意，从资源请求(步骤S3.10)直到资源服务器模块310向客户端应用420返回错误响应(步骤S3.15)的处理与使用图4描述的处理流程相同，因此这里省略该描述。
在步骤S7.5中，客户端应用420在接收到错误响应之后向授权服务器模块210发出授权令牌刷新请求(授权令牌再发布请求)。此时，授权令牌、在刷新令牌响应中获得的令牌标识符“rt_000001”或“rt_000002”、客户端ID“c001@xx.com”以及秘密“xxxxxxxxxx”被发送。
在步骤S7.6中，授权服务器模块210使用所获得的客户端ID“c001@xx.com”和秘密“xxxxxxxxxx”的集合来认证客户端。具体地，通过验证所获得的信息是否与客户端表(图6B)中的集合相匹配来进行认证。虽然未示出，但是如果客户端认证失败，则授权服务器模块210向客户端应用420响应认证错误。
在客户端认证成功的情况下，在步骤S7.7中，授权服务器模块210验证获得的刷新令牌。作为授权代码验证，确认所获得的刷新令牌是否被登记在令牌表中，并且在获得的刷新令牌被登记的情况下，进一步验证刷新令牌是否有效。此外，授权服务器模块210验证在授权令牌刷新请求中获得的客户端ID“c001@xx.com”是否与令牌表中的客户端ID相匹配。稍后将描述在刷新令牌验证的结果为“无效”的情况下的处理。这里，在刷新令牌验证的结果为“有效”的情况下，授权服务器模块210针对与刷新令牌相关联的用户的UUID和范围来执行范围验证处理(步骤S2.1)。稍后将描述范围验证处理(步骤S2.1)的细节。
接下来，在刷新令牌验证的结果为“有效”并且范围验证处理(步骤S2.1)的结果为“具有权限”的情况下，授权服务器模块210在步骤S8.1中发布授权令牌。更具体地，授权服务器模块210发布令牌标识符“at_000003”或“at_000004”。此外，授权服务器模块210在令牌表(图7A和图7B)中登记UUID“10000001”，范围“读取”或“组”，以及与刷新令牌相关联的用户的认证客户端ID“c001@xx.com”。此时，令牌类型被设为“授权令牌”，并且授权令牌直到其有效的日期和时间被登记为有效期。接下来，授权服务器模块210根据该信息和作为范围验证处理(步骤S2.1)的结果获得的范围生成JWT，并计算署名值。由于已经使用图11进行了描述，因此省略细节。此外，针对所生成的JWT，授权服务器模块210通过使用其保持的私有密钥生成并添加符合JWS的署名值。
此外，作为OAuth 2.0的可选项的指定，授权服务器模块210可以被构造为在步骤S8.2中再发布刷新令牌。在这种情况下，在步骤S8.3中，授权服务器模块210禁用所使用的刷新令牌。具体地，授权服务器模块210发布相应的令牌标识符“rt_000003”或“rt_000004”，并进一步将刷新令牌“rt_000001”或“rt_000002”的状态设置为“无效”。在本实施例中，描述了不执行刷新令牌再发布处理的方法。
在步骤S8.4中，授权服务器模块210向客户端应用420响应发布的署名授权令牌。
在步骤S3.10中，客户端应用420在获得授权令牌之后，针对资源服务器模块310公开的API发出资源请求。此后的处理与使用图4描述的相同。
接下来，将描述在范围验证处理(步骤S2.1)的结果是权限错误响应的情况下，授权服务器模块210中的序列。
在步骤S9.1中，授权服务器模块210向客户端应用420响应刷新令牌是“无效的”。客户端应用420在接收到刷新令牌无效的响应之后执行先前描述的授权请求(步骤S1.3)。因为此后的处理与使用图4描述的序列相同，因此将省略描述。
以上是用于客户端应用420刷新授权令牌并使用资源服务器模块310公开的API的权限委托协议中的刷新序列。
(范围验证处理)
接下来，使用图9给出关于图4和图8所示的范围验证处理(步骤S2.1)的描述。通过使用范围验证处理(步骤S2.1)，可以根据前面描述的范围组发布或验证授权令牌。
在步骤S901中，授权服务器模块210获得用户的UUID和范围。这里，在UUID“10000001”中，假定范围为“读取”或范围为“组”来给出说明。
在步骤S902中，授权服务器模块210通过使用在步骤S901中获得的UUID来获得用户的权限。更具体地，授权服务器模块210通过使用UUID“10000001”从授权服务器模块210的用户表中获得权限信息“设备设置者”和“设置值参照者”。
在步骤S903中，授权服务器模块210针对步骤S901中获得的每一个范围重复一次步骤S904至步骤S910。在本实施例中，假定将“读取”或“组”指定为单个范围(即，范围的数量为1)的情况来给出描述。
在步骤S904中，授权服务器模块210确定用户的范围是否是范围组。此时，确认授权服务器模块210的范围限定表的权限信息，并且在“范围-组”的情况下，确定为范围组。注意，对该方法没有限制。例如，另外，可以采取构造来增加用于区分是范围还是范围组的项目，并且可以将范围ID的格式设为添加前缀或后缀的范围ID，使得可以通过添加的信息来区分范围组。在不是范围组的情况下(步骤S904中为“否”；在本示例中为“读取”的情况)，进行到步骤S905，并且在是范围组的情况下(步骤S904中为“是”；在本示例中为“组”的情况)，进行到步骤S908。
在步骤S905中，授权服务器模块210确认用户的范围和权限。具体地，授权服务器模块210确认在步骤S902中获得的用户权限中是否包括范围限定表(图6C)的权限信息。换句话说，因为针对“读取”范围，将“设置值参照者”限定为权限信息，因此确认在步骤S902中获得的用户权限中是否包括“设置值参照者”。
在步骤S906中，作为步骤S905的确认的结果，授权服务器模块210确定是否保持有该权限。在确定“具有权限”的情况下(步骤S906中为“是”)，将处理目标设为下一个范围，并且继续步骤S903的循环处理。在针对所有范围的处理完成的情况下，进行到步骤S911。在确定“没有权限”的情况下(步骤S906中为“否”)，进行到步骤S907。
在步骤S907中，授权服务器模块210响应授权错误。然后，该处理流程结束。
在步骤S911中，授权服务器模块210响应用户权限为“具有权限”的范围。然后，该处理流程结束。注意，在本实施例中，由于“设置值参照者”被包括在用户权限中，因此确定“具有权限”。
在步骤S908中，授权服务器模块210获得与范围组相关联的所有范围。具体地，授权服务器模块210从范围限定表(图6C)获得组信息。在本实施例中，将“组”范围的组信息限定为“管理”，“编辑”，“读取”和“设备”。
在步骤S909中，授权服务器模块210对获得的范围中的各个执行类似于步骤S905的、用于确认用户的范围和权限的处理。
在步骤S910中，授权服务器模块210确定用户是否具有范围中的甚至一个的权限。在用户具有范围中的一个的权限的情况下，将处理目标设为下一范围，并且继续步骤S903的循环处理。此时，授权服务器模块210从与范围组相关联的范围当中提取在步骤S909中确定为“具有权限”的范围。在对所有范围的处理完成的情况下，进行到步骤S911。此外，在对所有范围确定“没有权限”的情况下(步骤S910中为“否”)，处理进行到步骤S907。
在步骤S911中，作为“具有权限”，授权服务器模块210响应用户具有权限的范围。此处包括在步骤S910的确定时提取的范围。在本实施例中，由于“设置值参照者”和“设备设置者”被包括在用户的权限中，此外，“读取”范围和“设备”范围的权限信息分别匹配，因此，有两个权限。结果，在步骤S910中，作为“具有权限”，以范围“读取”、“设备”和“组”做出响应。
以上是根据本实施例的范围验证处理的描述。通过使用范围验证处理，针对范围组，可以在提取用户具有权限的范围的同时验证权限的存在或不存在。
本发明的构造的特征之一在于：当客户端应用420向授权服务器模块210发送授权令牌刷新请求时，授权服务器模块210进行范围验证处理(图9)并发布授权令牌。本发明设想使用JWT和JWS进行授权处理。因此，存在对资源服务器模块310而不是授权服务器模块210执行授权令牌验证处理(图12)的形式的需求，并且尽可能多地，考虑在授权令牌验证处理时的最近的授权状态。使用图14A和图14B来描述细节。
(权限验证处理)
接下来，将使用图13描述图4所示的权限验证处理(步骤S4.1)的细节。通过根据本实施例的权限验证处理(步骤S4.1)，如果通过指定范围组来获得授权令牌，则在范围组中包括的范围的限度内执行权限验证。然后，在用户保持与这些范围对应的权限的情况下，将权限验证的结果确定为“具有权限”。
在步骤S1301中，授权服务器模块210从获得的授权令牌中获得用户的所有范围和UUID。这里，将分别给出“at_000001”和“at_000002”被获得为授权令牌的情况的描述。在授权令牌“at_000001”的情况下，获得用户的UUID“10000001”和授权服务器模块210的令牌表(图7B)中的范围“读取”。在授权令牌“at_000002”的情况下，获得用户的UUID“10000001”和授权服务器模块210的令牌表(图7B)中的范围“组”。
在步骤S1302中，授权服务器模块210针对每一个获得的范围以循环执行一次步骤S1303-步骤S1304的处理。在本实施例中，以分别得到一个范围的情况的示例给出说明。
在步骤S1303中，授权服务器模块210确定所获得的范围是否是范围组。此时，授权服务器模块210确认授权服务器模块210的范围限定表(图6C)的权限信息，并且在“范围-组”的情况下，确定所获得的范围是范围组。注意，不对该方法做出限制，另外，可以采用构造来增加用于区分获得的范围是范围还是范围组的项目，并且可以将范围ID的格式设为范围添加了前缀或后缀的ID，使得可以通过添加的信息区分范围组。如果范围不是范围组(步骤S1303中为“否”；在本示例的情况下，范围为“读取”的情况)，则继续步骤S1302的循环处理，其将未处理的范围作为处理目标。同时，在范围是范围组的情况下(步骤S1303中为“是”；在本示例的情况下，范围为“组”的情况)，处理进行到步骤S1304。
在步骤S1304中，授权服务器模块210获得与范围组相关联的所有范围。具体地，授权服务器模块210从范围限定表(图6C)获得组信息。在图6C的示例中，“组”范围的组信息被限定为“管理员”，“编辑”，“读取”和“设备”。授权服务器模块210将所获得的组信息进行分割，并将各个范围存储为后续处理的目标。然后，将未处理的范围作为处理目标，并且继续步骤S1302的循环处理。当针对所有范围的处理完成时，转移到步骤S1305。
在步骤S1305中，授权服务器模块210通过使用在步骤S1302中获得的UUID来获得用户的权限。更具体地，授权服务器模块210通过使用UUID“10000001”从授权服务器模块210的用户表(图6A)获得权限信息“设备设置者”和“设置值参照者”。
在步骤S1306中，授权服务器模块210对包括在权限验证请求中的每一个验证目标范围执行循环一次的、步骤S1307-步骤S1310的处理。在本实施例中，假定将用于参照设置值的范围“读取”指定为验证目标范围，来给出说明。
在步骤S1307中，授权服务器模块210验证验证目标范围是否包括在从包括分割范围组的结果的令牌中获得的一个或多个范围中。如果确定验证目标范围不包括在其中(步骤S1307中为“否”)，则进行到步骤S1308，并且如果确定验证目标范围被包括在内(步骤S1307中为“是”)，则进行到步骤S1309。在本实施例中，针对验证对象范围“读取”，由于从授权标记“at_000001”获得的范围为“读取”，所以确定该范围被包括在内，并且进行到步骤S1309。此外，由于从授权令牌“at_000002”获得的范围是“管理”，“编辑”，“读取”和“设备”，所以确定范围被包括在内，并且进行到步骤S1309。
在步骤S1308中，授权服务器模块210确定针对验证目标范围没有权限，并且实现该效果的某物被存储为响应。然后，将下一个未处理的范围作为验证的目标，并继续步骤S1307的循环处理。
在步骤S1309中，授权服务器模块210确认验证目标范围和用户的权限。具体地，授权服务器模块210确认在步骤S1305中获得的用户权限中是否包括范围限定表(图6C)的权限信息。具体地，由于针对作为验证目标范围的“读取”范围，将“设置值参照者”限定为权限信息，因此确认在步骤S1305中获得的用户权限中是否包括“设置值参照者”。
在步骤S1310中，在步骤S1309中确认“有权限”的情况下，授权服务器模块210存储具有针对验证目标范围的权限。然后，继续步骤S1307的循环处理，并且当对所有验证目标范围的授权验证结束时，进行到步骤S1311。
在步骤S1311中，授权服务器模块210响应权限验证结果，并结束处理。此时，授权服务器模块210响应所有存储的权限验证结果。例如，在验证请求中包含多个范围的情况下，做出与各个范围对应的验证结果的响应。在本实施例中，以“at_000001”和“at_000002”两者的结果“具有权限”做出响应。然后，该处理流程结束。
通过根据本实施例的权限验证处理，如果通过指定范围组获得授权令牌，则分割范围组，然后进行验证。为此，如果在范围组的范围的限度内，则可以执行用户权限验证确定，换句话说，执行步骤S1309的处理，而不执行用户授权处理。换句话说，针对用户的权限的改变，可以执行与用户权限相对应的权限验证处理，而不强制用户再次进行授权确认处理。
[根据时间序列描述使用例]
接下来，使用图14A和图14B以Oauth 2.0作为示例给出以下情况的描述：在范围限定有变化的情况下，可以继续API的使用而不必进行用户的再授权。此外，描述即使在用户权限变化的情况下，也可以继续使用API而无需用户再授权的情况。
图14A是通过时间序列来例示是否许可改变范围限定和API执行的动作的图。图14A的沿向右方向的箭头符号是时间轴。朝向时间轴的箭头符号指示：针对箭头符号指向的特定时间，范围限定、用户权限和从客户端应用420到资源服务器模块310的API使用，及其结果。
首先，如图14A所示，用户(用户ID“user@xx.com”)保持“设备设置者”和“设置值参照者”作为授权信息。接下来，范围限定如图14A所示。特别地，在范围ID“组”中，“读取”和“设备”范围作为其成员而被包括。
假定在该状态下，在客户端应用420中，在范围“组”中，获得署名授权令牌1(图14A中的JWT 1)。用于获得署名授权令牌的序列和流程如前所述。结果，获得将“读取”和“设备”的范围描述为范围的署名授权令牌。
接下来，客户端应用420通过使用所获得的署名授权令牌1(JWT 1)，针对需要资源服务器模块310的范围“读取”的资源来执行API。此时，范围“读取”包括在署名授权令牌中，并且由于署名值正确，因此API的执行成功。这里，由资源服务器模块310而不是授权服务器模块210执行署名值的验证(图4和图12的步骤S3.11)。结果，可以在没有给授权服务器模块210上带来负荷的情况下，进行权限验证。
接下来，客户端应用420通过使用获得的署名授权令牌1(JWT 1)，针对资源服务器模块310的、需要范围“顺序”的资源执行API。此时，范围“顺序”包括在署名授权令牌中，并且API的执行被拒绝。如作为问题描述的，如果不再次处理OAuth 2.0的授权代码授权，指定范围“顺序”，以获得另一个授权令牌，则不能使用该API。因此，在传统方法中，用户需要再次执行授权操作。
接下来，假定范围“顺序”被添加到范围限定的范围“组”的成员。之后，客户端应用420执行授权令牌的刷新(图8)。此时，获得“读取”、“设备”和“顺序”的范围被记载为范围的署名授权令牌2(图14A中的JWT 2)。
客户端应用420再次针对需要范围“顺序”的资源执行API。此时，范围“顺序”被包括在署名授权令牌中，并且由于署名值正确，API的执行成功。
换句话说，只要权限已被添加到用户，在指定“组”并获得授权令牌的情况下，可以通过进行刷新原样使用需要范围“顺序”的API。结果，在资源服务器模块310中实现新功能的情况下，客户端应用420可以使用调用该功能的API而不使用户再执行授权令牌的授权操作。此外，由资源服务器模块310而不是授权服务器模块210执行署名值的验证(图8和图12的步骤S3.11)。结果，可以在没有给授权服务器模块210上带来负荷的情况下，进行权限验证。
图14B是通过时间序列来例示是否许可改变用户权限和API执行的动作的图。图14B的沿向右方向的箭头符号是时间轴。朝向时间轴的箭头符号指示：针对箭头符号指向的特定时间，范围限定、用户权限和从客户端应用420到资源服务器模块310的API使用，及其结果。
首先，如图14B所示，用户(用户ID“user@xx.com”)保持“设备设置者”和“设置值参照者”作为授权信息。此外，范围限定如图14B所示。特别地，在范围ID“组”中，“读取”、“设备”和“顺序”范围作为其成员而被包括。另外，“安装工作者”被关联为与“顺序”范围有关的权限信息。
假定在该状态下，在客户端应用420处，在范围“组”中，获得署名授权令牌1(图14B中的JWT 1)。用于获得署名授权令牌的序列和流程如前所述。此时，获得将“读取”和“设备”的范围描述为范围的署名授权令牌。注意，虽然没有以图形方式示出，但是在通过指定范围“顺序”来执行署名授权令牌1(JWT 1)的获得的情况下，由于用户缺少权限，如流程(图9)中描述的那样，获得失败。
接下来，客户端应用420通过使用所获得的署名授权令牌1(JWT 1)，针对需要资源服务器模块310的范围“读取”的资源来执行API。范围“读取”包括在署名授权令牌中，并且由于署名值正确，因此API的执行成功。此时，由资源服务器模块310而不是授权服务器模块210执行署名值的验证。结果，可以在没有给授权服务器模块210上带来负荷的情况下，进行权限验证。
接下来，客户端应用420通过使用获得的署名授权令牌1(JWT 1)，针对资源服务器模块310的、需要范围“顺序”的资源执行API。此时，范围“顺序”包括在署名授权令牌中，并且API的执行被拒绝。直到这里描述的内容是描述为要被解决的问题的状态。
接下来，向用户(用户ID“user@xx.com”)添加“安装工作者”的权限。之后，客户端应用420执行授权令牌的刷新(图8)。结果，获得“读取”、“设备”和“顺序”的范围被记载为范围的署名授权令牌2(图14B中的JWT 2)。
客户端应用420再次针对需要范围“顺序”的资源执行API。结果，范围“顺序”被包括在署名授权令牌2(JWT 2)中，并且由于署名值正确，API的执行成功。
具体地，在用户权限发生变化的情况下，可以允许原样使用需要范围“顺序”的API，而不强制用户再次执行授权操作。此外，此外，由资源服务器模块310而不是授权服务器模块210执行署名值的验证。结果，可以在没有给授权服务器模块210上带来负荷的情况下，进行权限验证。
在上文中，在本实施例中，限定范围组，并且使用范围组来进行权限委托。因此，即使用户的权限发生变化，也可以在改变的用户的权限的限度内继续API使用，而无需提示用户再次进行授权操作。此外，即使存在伴随着服务的新功能的实现的范围变化，类似地，可以根据用户的权限继续使用包括与新功能对应的API的API，而不提示用户再次进行授权操作。
其他实施例
本发明的(多个)实施例也可以通过如下实现：一种系统或装置的计算机，该系统或装置读出并执行在存储介质(其也可被更充分地称为“非暂态计算机可读存储介质”)上记录的计算机可执行指令(例如，一个或更多个程序)，以执行上述(多个)实施例中的一个或更多个的功能，并且/或者，该系统或装置包括用于执行上述(多个)实施例中的一个或更多个的功能的一个或更多个电路(例如，专用集成电路(ASIC))；以及由该系统或者装置的计算机执行的方法，例如，从存储介质读出并执行计算机可执行指令，以执行上述(多个)实施例中的一个或更多个的功能，并且/或者，控制所述一个或更多个电路以执行上述(多个)实施例中的一个或更多个的功能。所述计算机可以包括一个或更多处理器(例如，中央处理单元(CPU)，微处理单元(MPU))，并且可以包括分开的计算机或分开的处理器的网络，以读出并执行所述计算机可执行指令。所述计算机可执行指令可以例如从网络或存储介质被提供给计算机。例如，存储介质可以包括如下中的一个或更多个：硬盘，随机存取存储器(RAM)，只读存储器(ROM)，分布式计算系统的存储器，光盘(例如，压缩盘(CD)，数字多功能光盘(DVD)，或蓝光光盘(BD)TM)，闪速存储器装置，存储卡，等等。
本发明的实施例还可以通过如下的方法来实现，即，通过网络或者各种存储介质将执行上述实施例的功能的软件(程序)提供给系统或装置，该系统或装置的计算机或是中央处理单元(CPU)、微处理单元(MPU)读出并执行程序的方法。
虽然已经参照示例性实施例描述了本发明，但是应当理解，本发明不限于所公开的示例性实施例。以下权利要求的范围将被赋予最广泛的解释，以便包含所有这些修改和等效的结构和功能。