FEDERATED AUTHENTICATION SERVER, FEDERATED AUTHENTICATION METHOD, FEDERATED AUTHENTICATION SYSTEM, AND STORAGE MEDIUM

A federated authentication server provides, in cooperation with an authentication server, a function of authenticating a user terminal to a resource server configured to provide a service to the user terminal, and includes an authentication information transmission unit configured to transmit authentication information about a user of the user terminal to the authentication server, a token reception unit configured to receive, from the authentication server, a token for use in accessing the resource server from the user terminal, a code issue unit configured to issue a code for identifying an authentication success response and transmit the code to the resource server, a storage unit configured to store the code and the token in association with each other, and a token transmission unit configured to transmit the token associated with the code to the resource server in a case where the code is transmitted from the resource server.

BACKGROUND

Field

The present disclosure relates to a federated authentication server configured to provide, in cooperation with an authentication server, a function of authenticating a user terminal, a federated authentication method, a federated authentication system, and a storage medium.

Description of the Related Art

A service that enables a user at a user terminal to use various functions provided by a server apparatus via a network has been widely developed in recent years. In many cases, the server apparatus (hereinafter referred to as the “resource server”) providing the service requests user authentication using account information such as a user identification (ID) and a password, when receiving from the user terminal a request for accessing a resource stored on the resource server.

In order to perform the user authentication, the resource server needs to prepare a server (hereinafter referred to as an “authentication server”) for user authentication in addition to the service that the resource server provides. A service, such as OpenID Connect (OIDC), for federated authentication using a user ID issued by an identification (ID) provider of a cloud service as the user ID of the user has been discussed and known. Using such an authentication service, the resource server no longer needs to prepare its own authentication service, so that the resource server can focus on developing the service that the resource server provides.

According to a technique discussed in Japanese Patent Application Laid-Open No. 2017-154492, authentication information is transmitted to an external authentication system, and in a case where authentication is successful, the authentication information is stored in association with address information. Then, in a case where a response to a use end request transmitted based on an operation of ending the use of an external service on a predetermined screen is received, first authentication information associated with the address information of the external service is erased.

In a case where a federated authentication function such as OpenID Connect provided by the authentication service to be used and a function of a login screen for authentication satisfy requirements of the resource server, the resource server can use the authentication server using the technique discussed in Japanese Patent Application Laid-Open No. 2017-154492. However, the federated authentication function of the authentication service may be inadequate depending on the requirements of the resource server.

SUMMARY

Various embodiments of the present disclosure provide techniques and mechanisms for a function of authenticating a user terminal, in cooperation with an authentication server.

According to one embodiment of the present disclosure, a federated authentication server is configured to provide, in cooperation with an authentication server, a function of authenticating a user terminal to a resource server configured to provide a service to the user terminal. The federated authentication server includes an authentication information transmission unit configured to transmit authentication information about a user of the user terminal to the authentication server; a token reception unit configured to receive, from the authentication server, a token for use in accessing the resource server from the user terminal; a code issue unit configured to issue a code for identifying an authentication success response and transmit the code to the resource server; a storage unit configured to store the code and the token in association with each other; and a token transmission unit configured to transmit the token associated with the code to the resource server in a case where the code is transmitted from the resource server.

Further features of the present disclosure will become apparent from the following description of example embodiments with reference to the attached drawings.

DESCRIPTION OF THE EMBODIMENTS

FIG. 1is a diagram illustrating a functional configuration of a federated authentication server101according to a first example embodiment of the present disclosure. InFIG. 1, an authentication server102manages identifications (IDs) and performs authentication processing and token issue processing. The federated authentication server101and the authentication server102cooperate with each other to function as a federated authentication system. A user terminal103is used by a user. A resource server104provides a service to be used by the user via the user terminal103. The resource server104uses a token to manage access from the user terminal103.

An authentication request reception unit105receives an authentication request transmitted from the resource server104to the federated authentication server101. An authentication screen processing unit106enables the federated authentication server101to provide an authentication screen to the user terminal103, and processes user authentication information input via the authentication screen. An authentication information transmission unit107transmits the user authentication information transmitted from the authentication screen processing unit106to the authentication server102.

A token reception unit108receives a token from the authentication server102in a case where authentication is successful. A code issue unit109issues a code and transmits the code to the resource server104. A storage unit110stores the code and the token in association with each other. A token request reception unit111receives a token request. A token transmission unit112transmits the token as a response to the token request. A token update unit113updates the token.

FIG. 2is a diagram illustrating a hardware configuration of the federated authentication server101according to the present example embodiment. InFIG. 2, a central processing unit (CPU)201executes a control program for the federated authentication server101. A read-only memory (ROM)202stores the control program. A random access memory (RAM)203is used to provide a work area of the CPU201. A network interface (I/F)204communicates with applications outside the federated authentication server101. A storage device205is, for example, a hard disk drive and stores data.

FIG. 3is a diagram illustrating a federated authentication sequence performed by the federated authentication server101according to the present example embodiment in response to receiving a request from the resource server104.

First, in step S301, the user accesses the resource server104from the user terminal103. For example, a predetermined universal resource locator (URL) is input from a browser of the user terminal103to access the resource server104. At this time, the resource server104checks a login state of the user as the resource server104. The login state is determined based on whether, for example, cookie information about the browser that corresponds to a domain of the resource server104contains a valid token. In a case where the resource server104is determined to be not in the login state, then in step S302, a transition to the federated authentication server101is made. A destination of the transition to the federated authentication server101corresponds to the authentication request reception unit105. In the present example embodiment, a case where the federated authentication server101provides a federated authentication function based on OpenID Connect will be described. In this case, the authentication request reception unit105corresponds to an authorization end point in the OpenID Connect specification. At this time, a client ID, a scope, a response type, and a redirect URI are added to a request parameter transmitted to the authorization end point in transition to the authorization end point according to the specification. However, the present example embodiment is not limited thereto, and any specification that can provide the destination of the transition to federated authentication from the resource server104may be employed.

Next, in step S303, the authentication screen processing unit106provides the authentication screen to the user terminal103.

In step S304, the user inputs the authentication information via the authentication screen. The authentication information is typically an ID and a password but may be any information including biometric authentication information.

After the user inputs the authentication information, in step S305, the user terminal103transmits the authentication information to the federated authentication server101. In step S306, the authentication information transmission unit107of the federated authentication server101transmits the authentication information to the authentication server102.

In step S307, the authentication server102verifies the authentication information and performs authentication. In a case where the authentication information is not matched and the authentication is unsuccessful, the authentication server102returns an error response to the federated authentication server101, and the federated authentication server101returns the error response to the user terminal103. The user terminal103displays an authentication error message on the authentication screen. On the other hand, in step S307, in a case where the authentication server102successfully performs authentication, then in step S308, the authentication server102issues a token and returns an authentication success response together with the token to the federated authentication server101. The token reception unit108of the federated authentication server101receives the issued token. In the present example embodiment, the issued token will be described as a pair of an ID token and a refresh token based on the OpenID Connect specification.

FIG. 4illustrates an example of claims contained in the ID token. The “iss” claim represents the issuer of the token and corresponds to the authentication server102. The “sub” claim represents a value that uniquely identifies the ID authenticated by the authentication server102. The “aud” claim represents the ID of the client to which the ID token is issued and corresponds to the resource server104. The “iat” claim represents the issue time of the ID token. The “exp” claim represents the expiration date of the ID token. The “auth_time” claim represents the time of the authentication by the authentication server102. The “preferred_username” claim represents the username of the ID in the authentication information. The “email” claim represents the email address associated with the authentication information. The claims of the token described above are a mere example, and the present example embodiment is not limited thereto.

When the federated authentication server101receives the token and the authentication success response, then in step S309, the code issue unit109issues a code. The code may be any information for identifying the authentication success response, such as a universally unique identifier (UUID).

Next, in step S310, the storage unit110stores the code and the token in association with each other.FIG. 5illustrates an example of a database in which the storage unit110stores the code and the token in association with each other. InFIG. 5, a code501corresponds to the code. An ID token502is the ID token issued by the authentication server102. A refresh token503is issued together with the ID token by the authentication server102. A client ID504is the client ID transmitted by the resource server104in the transition to the authorization end point of the federated authentication server101in step S302. A redirect URI505is the redirect URI transmitted by the resource server104in the transition to the authorization end point of the federated authentication server101in step S302. The redirect URI505is used in verification of the request parameter by a token end point (described below). A code expiration date506specifies the expiration date of the code, and a token request (described below) transmitted using a code having passed the expiration date is invalidated.

Data stored by the storage unit110according to the present example embodiment is not limited thereto, and the present example embodiment is applicable to any case where the code issued by the federated authentication server101and the token issued by the authentication server102are stored in association with each other.

A feature of the present example embodiment is that the token issued by the authentication server102, which is different from the federated authentication server101, is received in step S309and then stored in association with the code in step S310for use in the subsequent steps.

Next, in step S311, the code issue unit109transmits the issued code to the resource server104. The code is an authorization code of the authorization end point according to the authorization code flow of OpenID Connect. This corresponds to a transition with the code added to the redirect URI transmitted to the authorization end point in response to the transition to the authorization end point of the federated authentication server101in step S302.

Next, in step S312, the resource server104transmits a token request to the federated authentication server101. The token request reception unit111of the federated authentication server101receives the token request. This request corresponds to an ID token request made to the token end point using the authorization code issued by the authorization end point according to the authorization code flow of the OpenID Connect specification. Also in this case, the authentication information for the client ID and the redirect URI specified in the transition to the authorization end point are transmitted as the request parameter. The token request reception unit111verifies the request parameter of the token request. However, the present example embodiment is not limited to the OpenID Connect specification.

In a case where the token request reception unit111determines to return the token, then in step S313, the token transmission unit112acquires from the storage unit110the token corresponding to the code contained in the token request, and transmits the acquired token to the resource server104.

In step S314, the resource server104verifies whether the token received from the federated authentication server101is the appropriate token issued by the authentication server102. For example, in a case where the token is the ID token, since the token is in Json Web Token (JWT) format, a public key is acquired from the authentication server102, and a signature of the token and appropriateness of the claims inFIG. 4are verified.

In a case where the token is successfully verified, then in step S315, the resource server104manages the login state of the resource server104and provides the service to the user terminal103.

With the above-described configuration and sequence, the federated authentication server101according to the present example embodiment transmits the authentication information from the authentication screen to the authentication server102, and in a case where authentication is successful, the federated authentication server101receives a token and stores the received token in association with a code issued by the federated authentication server101.

Thus, the federated authentication function such as OpenID Connect and the own authentication screen of the federated authentication server101are provided using the authentication function, the token issue function, and the function of providing the public key for token verification which are the functions of the authentication server102.

In the first example embodiment, the token issued by the authentication server102in step S308is stored in association with the code by the storage unit110, and when the token request is received from the resource server104, the token transmission unit112transmits the stored token in step S313. Thus, the issue time (the “iat” claim) of the ID token inFIG. 4is technically not the time corresponding to the processing in step S313but the time corresponding to the processing in step S308. In addition, the expiration date (the “exp” claim) of the ID token is determined based on the time corresponding to the processing in step S308. Accordingly, the difference in time between the processing in step S308and the processing in S313may affect the processing of the resource server104and the specification rigor.

FIG. 6illustrates processing according to a second example embodiment as a solution to the above-described issue. While in the first example embodiment, the token is of any type and the refresh token may not necessarily be used, the refresh token is used in the present example embodiment.

Steps S301to S307inFIG. 6are similar to those inFIG. 3according to the first example embodiment. After the authentication by the authentication server102in step S307, in step S601, the authentication server102issues a token and a refresh token. In step S309, the code issue unit109of the federated authentication server101issues a code as in the first example embodiment.

Next, in step S602, the storage unit110stores the code and the refresh token in association with each other. At this time, the token issued by the authentication server102in step S601may be stored or may be discarded without being stored in the present example embodiment. At least the refresh token is stored together with the code.

Steps S311and S312are similar to those in the first example embodiment. After the token request reception unit111receives the token request, the token update unit113acquires the refresh token associated with the code from the storage unit110. Then in step S603, the token update unit113transmits the acquired refresh token and a token update request to the authentication server102. In step S604, the authentication server102issues a token updated in response to the token update request. Then in step S605, the token transmission unit112transmits the updated token to the resource server104. At this time, the refresh token used to update the token may also be provided together with the token to the resource server104.

With the above-described sequence, the federated authentication server101according to the present example embodiment updates the token using the refresh token issued in step S601at the time of receiving the token request in step S312. Thus, the issue time and the expiration date of the token that are contained in the token are set based on the time updated in step S604, so that the issue time and the expiration date are set more appropriately for the token to be returned from the federated authentication server101.

A third example embodiment will be described. While in the first and second example embodiments, the description is given based on the authorization code flow of OpenID Connect and the token issued by the authentication server102is also described as the ID token, example embodiments of the present disclosure are not limited thereto. The token may be in a format different from that of the ID token, such as a simple UUID. In addition, the authentication request reception unit105as the authorization end point to which the transition is made in step S302may not be based on the authorization end point of OpenID Connect. Furthermore, the end point received by the token request reception unit111in step S312may not be based on the token end point of OpenID Connect. The token issued by the authentication server102may be stored in association with the code issued by the federated authentication server101, and the token associated with the code may be returned in response to the token request using the code from the resource server104.

A fourth example embodiment will be described. While three types of servers, i.e., the federated authentication server101, the authentication server102, and the resource server104are described in the first to third example embodiments, the federated authentication server101, the authentication server102, and the resource server104may not be configured as separate apparatuses. For example, the federated authentication server101and the resource server104may be configured as a single apparatus, and the processing in steps S302, S311, S312, and S313may be performed by communication between functions operating in the same apparatus.

In a case where the functions of the federated authentication server101and the authentication server102are configured as a single apparatus, the storage unit110can be eliminated if the issue of the token, which is originally performed in step S308following the authentication in step S307, is performed following step S312. In this case, a configuration in which software of the federated authentication server101and software of the authentication server102are run in the same apparatus may be desirably used.

OTHER EMBODIMENTS

This application claims the benefit of Japanese Patent Application No. 2021-013917, filed Jan. 29, 2021, which is hereby incorporated by reference herein in its entirety.