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.
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.
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.
An authentication request reception unit 105 receives an authentication request transmitted from the resource server 104 to the federated authentication server 101. An authentication screen processing unit 106 enables the federated authentication server 101 to provide an authentication screen to the user terminal 103, and processes user authentication information input via the authentication screen. An authentication information transmission unit 107 transmits the user authentication information transmitted from the authentication screen processing unit 106 to the authentication server 102.
A token reception unit 108 receives a token from the authentication server 102 in a case where authentication is successful. A code issue unit 109 issues a code and transmits the code to the resource server 104. A storage unit 110 stores the code and the token in association with each other. A token request reception unit 111 receives a token request. A token transmission unit 112 transmits the token as a response to the token request. A token update unit 113 updates the token.
First, in step S301, the user accesses the resource server 104 from the user terminal 103. For example, a predetermined universal resource locator (URL) is input from a browser of the user terminal 103 to access the resource server 104. At this time, the resource server 104 checks a login state of the user as the resource server 104. The login state is determined based on whether, for example, cookie information about the browser that corresponds to a domain of the resource server 104 contains a valid token. In a case where the resource server 104 is determined to be not in the login state, then in step S302, a transition to the federated authentication server 101 is made. A destination of the transition to the federated authentication server 101 corresponds to the authentication request reception unit 105. In the present example embodiment, a case where the federated authentication server 101 provides a federated authentication function based on OpenID Connect will be described. In this case, the authentication request reception unit 105 corresponds 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 server 104 may be employed.
Next, in step S303, the authentication screen processing unit 106 provides the authentication screen to the user terminal 103.
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 terminal 103 transmits the authentication information to the federated authentication server 101. In step S306, the authentication information transmission unit 107 of the federated authentication server 101 transmits the authentication information to the authentication server 102.
In step S307, the authentication server 102 verifies the authentication information and performs authentication. In a case where the authentication information is not matched and the authentication is unsuccessful, the authentication server 102 returns an error response to the federated authentication server 101, and the federated authentication server 101 returns the error response to the user terminal 103. The user terminal 103 displays an authentication error message on the authentication screen. On the other hand, in step S307, in a case where the authentication server 102 successfully performs authentication, then in step S308, the authentication server 102 issues a token and returns an authentication success response together with the token to the federated authentication server 101. The token reception unit 108 of the federated authentication server 101 receives 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.
When the federated authentication server 101 receives the token and the authentication success response, then in step S309, the code issue unit 109 issues 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 unit 110 stores the code and the token in association with each other.
Data stored by the storage unit 110 according 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 server 101 and the token issued by the authentication server 102 are stored in association with each other.
A feature of the present example embodiment is that the token issued by the authentication server 102, which is different from the federated authentication server 101, is received in step S309 and then stored in association with the code in step S310 for use in the subsequent steps.
Next, in step S311, the code issue unit 109 transmits the issued code to the resource server 104. 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 server 101 in step S302.
Next, in step S312, the resource server 104 transmits a token request to the federated authentication server 101. The token request reception unit 111 of the federated authentication server 101 receives 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 unit 111 verifies 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 unit 111 determines to return the token, then in step S313, the token transmission unit 112 acquires from the storage unit 110 the token corresponding to the code contained in the token request, and transmits the acquired token to the resource server 104.
In step S314, the resource server 104 verifies whether the token received from the federated authentication server 101 is the appropriate token issued by the authentication server 102. 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 server 102, and a signature of the token and appropriateness of the claims in
In a case where the token is successfully verified, then in step S315, the resource server 104 manages the login state of the resource server 104 and provides the service to the user terminal 103.
With the above-described configuration and sequence, the federated authentication server 101 according to the present example embodiment transmits the authentication information from the authentication screen to the authentication server 102, and in a case where authentication is successful, the federated authentication server 101 receives a token and stores the received token in association with a code issued by the federated authentication server 101.
Thus, the federated authentication function such as OpenID Connect and the own authentication screen of the federated authentication server 101 are 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 server 102.
In the first example embodiment, the token issued by the authentication server 102 in step S308 is stored in association with the code by the storage unit 110, and when the token request is received from the resource server 104, the token transmission unit 112 transmits the stored token in step S313. Thus, the issue time (the “iat” claim) of the ID token in
Steps S301 to S307 in
Next, in step S602, the storage unit 110 stores the code and the refresh token in association with each other. At this time, the token issued by the authentication server 102 in step S601 may 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 S311 and S312 are similar to those in the first example embodiment. After the token request reception unit 111 receives the token request, the token update unit 113 acquires the refresh token associated with the code from the storage unit 110. Then in step S603, the token update unit 113 transmits the acquired refresh token and a token update request to the authentication server 102. In step S604, the authentication server 102 issues a token updated in response to the token update request. Then in step S605, the token transmission unit 112 transmits the updated token to the resource server 104. At this time, the refresh token used to update the token may also be provided together with the token to the resource server 104.
With the above-described sequence, the federated authentication server 101 according to the present example embodiment updates the token using the refresh token issued in step S601 at 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 server 101.
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 server 102 is 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 unit 105 as the authorization end point to which the transition is made in step S302 may not be based on the authorization end point of OpenID Connect. Furthermore, the end point received by the token request reception unit 111 in step S312 may not be based on the token end point of OpenID Connect. The token issued by the authentication server 102 may be stored in association with the code issued by the federated authentication server 101, and the token associated with the code may be returned in response to the token request using the code from the resource server 104.
A fourth example embodiment will be described. While three types of servers, i.e., the federated authentication server 101, the authentication server 102, and the resource server 104 are described in the first to third example embodiments, the federated authentication server 101, the authentication server 102, and the resource server 104 may not be configured as separate apparatuses. For example, the federated authentication server 101 and the resource server 104 may be configured as a single apparatus, and the processing in steps S302, S311, S312, and S313 may be performed by communication between functions operating in the same apparatus.
In a case where the functions of the federated authentication server 101 and the authentication server 102 are configured as a single apparatus, the storage unit 110 can be eliminated if the issue of the token, which is originally performed in step S308 following the authentication in step S307, is performed following step S312. In this case, a configuration in which software of the federated authentication server 101 and software of the authentication server 102 are run in the same apparatus may be desirably used.
Various embodiment(s) of the present disclosure can also be realized by a computer of a system or apparatus that reads out and executes computer executable instructions (e.g., one or more programs) recorded on a storage medium (which may also be referred to more fully as a ‘non-transitory computer-readable storage medium’) to perform the functions of one or more of the above-described embodiment(s) and/or that includes one or more circuits (e.g., application specific integrated circuit (ASIC)) for performing the functions of one or more of the above-described embodiment(s), and by a method performed by the computer of the system or apparatus by, for example, reading out and executing the computer executable instructions from the storage medium to perform the functions of one or more of the above-described embodiment(s) and/or controlling the one or more circuits to perform the functions of one or more of the above-described embodiment(s). The computer may comprise one or more processors (e.g., central processing unit (CPU), micro processing unit (MPU)) and may include a network of separate computers or separate processors to read out and execute the computer executable instructions. The computer executable instructions may be provided to the computer, for example, from a network or the storage medium. The storage medium may include, for example, one or more of a hard disk, a random-access memory (RAM), a read only memory (ROM), a storage of distributed computing systems, an optical disk (such as a compact disc (CD), digital versatile disc (DVD), or Blu-ray Disc (BD)™), a flash memory device, a memory card, and the like.
While example embodiments have been described, it is to be understood that the disclosure is not limited to the disclosed example embodiments. The scope of the following claims is to be accorded the broadest interpretation so as to encompass all such modifications and equivalent structures and functions.
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.
Number | Date | Country | Kind |
---|---|---|---|
2021-013917 | Jan 2021 | JP | national |