KR102232763B1 - Single-sign-on method and system for multi-domain services - Google Patents

Abstract

A method in which a host authentication server in charge of single authentication of multi-domain services performs single authentication by interworking with authentication servers of the multi-domain services. Issuing a login token, among the multi-domain services, generating a first service list of services connected to the main account to which the login token was issued, and issuing a single authentication token to the client along with the first service list The step of, when receiving a single authentication token verification request from an authentication server of an arbitrary service included in the first service list, verifying whether the token included in the single authentication token verification request is the single authentication token issued to the client. And if the verification is successful, adding the random service to the session of the main account, and passing the key of the session to the authentication server of the random service. The client is a browser of a user terminal. The authentication server of the arbitrary service may set a key of the session for the client and generate an authentication cookie that enables the client to use the arbitrary service.

Description

A single authentication method for multi-domain services and a system implementing it {SINGLE-SIGN-ON METHOD AND SYSTEM FOR MULTI-DOMAIN SERVICES}

The present invention relates to a single sign-on (SSO) technology.

Single Sign On (SSO) is a technology that enables multiple services to be used with one account login, and is referred to as single authentication, integrated authentication, single sign-on, and single account login.

SSO can be implemented in various ways. For example, the browser of the terminal generates a unique key issued when logging in as a cookie, accesses each service site through the cookie, and deletes the cookie when logging out. In general, if multiple service sites are provided in the same domain, SSO can be easily implemented through cookies.

In recent years, due to attempts to link services provided in different domains or mergers of companies, there is a need to integrate multiple service sites already established with individual authentication systems and perform single authentication. However, in the case of service sites provided in other domains, there is a cross domain problem, and CORS (Cross Origin Resource Sharing) to solve the cross domain problem has restrictions such as cookie issuance restrictions, so it is easy to implement SSO. not. In addition, in a situation in which each service site is accessed and managed by its own authentication server, it is not easy to perform integrated authentication and integrated session management of different authentication servers of multi-domain services.

The problem to be solved is to provide a single authentication login and logout of multi-domain services, and a lazy single authentication login used in the login recovery procedure or re-authentication procedure, and integrated management of sessions of single authenticated multi-domain services. It is to provide a method and a system implementing the same.

According to an embodiment, as a method in which a subject authentication server in charge of single authentication of multi-domain services performs single authentication by interworking with authentication servers of the multi-domain services, and authenticates a main account included in a login request of a client. , Issuing a login token to the client who has successfully authenticated, among the multi-domain services, generating services connected to the main account to which the login token is issued as a first service list, and performing single authentication together with the first service list Issuing a token to the client, upon receiving a single authentication token verification request from an authentication server of an arbitrary service included in the first service list, the token included in the single authentication token verification request is issued to the client. Verifying whether it is a single authentication token, and if the verification is successful, adding the random service to the session of the main account, and passing the key of the session to the authentication server of the random service. The client is a browser of a user terminal. The authentication server of the arbitrary service sets a key of the session for the client, and generates an authentication cookie that enables the client to use the arbitrary service.

In the step of verifying whether the single authentication token is the single authentication token, the single authentication token verification request may be asynchronously received from an authentication server of each service included in the first service list.

In the single authentication method, receiving a logout request from the client, generating services added to the session created when logging in to the main account as a second service list, and delivering the second service list to the client. It may further include the step of. The client may request logout of a corresponding service to an authentication server of each service included in the second service list.

The single authentication method may further include receiving a logout request from the client, and deleting the session created when logging in to the main account to logout single authentication. The session may be a public session to which services that have received the key of the session are added.

The single authentication method, after issuing the login token to the client, receiving a single lazy authentication start request for a specific service from the client, and the single authentication token or a new single authentication token to the client It may further include the step of issuing. The client may request the start of the slow single authentication by calling a login confirmation interface provided by a service server related to the host authentication server while being connected to the server of the specific service. Alternatively, the client may request the slow single authentication start by redirecting to and calling a single authentication login page provided by a service server related to the host authentication server while accessing the server of the specific service.

According to another embodiment, an authentication server of a specific service among multi-domain services interlocks with a host authentication server that manages single authentication of the multi-domain services to perform single authentication, including a single authentication token from a client. Receiving an authentication request, requesting the subject authentication server to verify ownership whether the client has ownership of the single authentication token, receiving an ownership verification result from the subject authentication server, and the ownership verification result If successful, setting a session key included in the ownership verification result for the client, and generating an authentication cookie that enables the client to use the specific service. The client is a browser of a user terminal. The account of the specific service is linked to the main account, and the single authentication token is a token issued to the client after the host authentication server successfully logs in to the main account requested by the client. The session key is a key of a session created when the main account is logged in.

The client may request the single authentication to the authentication server of the specific service using an iFrame.

The single authentication method may further include receiving a logout request from the client after generating the authentication cookie, processing logout for the client, and responding to logout to the client. The client may request logout to the host authentication server and transmit the single authentication request based on a received service list.

According to another embodiment. A method in which a browser of a user terminal performs single authentication with multi-domain services, which is a host service system that manages single authentication of multi-domain services, requests login for a main account, and a login token for the main account from the host service system. Issuing, to the host service system, sending a single authentication start request including the login token and client information, and single authentication with a first service list including services connected to the primary account from the host service system Issuing a token, and transmitting a single authentication request including the single authentication token to the authentication server of each service included in the first service list, and sending an authentication cookie of the corresponding service issued from the authentication server of the corresponding service. Including the step of setting.

The single authentication method includes the steps of requesting logout to the host service system and receiving a second service list including services added to the session created when the main account is logged in from the host service system, and the second The step of requesting logout of the corresponding service to the authentication server of each service included in the service list may be further included.

The single authentication method includes receiving a login request response from the service server while accessing a service server of a specific service among the multi-domain services, and lazy single authentication for the specific service with the host service system. Requesting a start, receiving the single authentication token or a new single authentication token from the host service system, and transmitting a single authentication request including the token issued for the specific service to the authentication server of the specific service, And setting an authentication cookie of the specific service issued from the authentication server of the specific service.

The step of requesting the slow single authentication start may request the slow single authentication start by passing the login token to JSONP.

The step of requesting the start of the slow single authentication may include redirecting from the service page of the specific service to the single authentication login page of the host service system, and then transferring the login token to the host service system to start the slow single authentication. Can be requested.

In the step of requesting the start of the slow single authentication, when the login token cannot be delivered to JSONP, after redirecting from the service page of the specific service to the single authentication login page of the host service system, the login token is transferred to the The slow single authentication start can be requested by passing it to the host service system.

According to an embodiment, a user can use multi-domain services linked to the primary account only by logging in to the primary account.

According to an embodiment, a service provider may integrate a plurality of services implemented as individual authentication schemes in different domains into a single authentication scheme. According to an embodiment, a single authentication system can perform single authentication login and single authentication logout through interworking of multiple authentication servers, and can integrate and manage single authenticated services in the login session of the main account.

According to an embodiment, the single authentication system can provide login recovery for a service that fails single authentication at the time of login through a lazy single authentication login method, and provides a re-authentication procedure for a service requiring re-authentication. can do. In particular, even if there is a connection failure to the service site during the single authentication login phase or a single authentication for some services fails due to a problem with the browser (client) installed on the terminal, the browser performs the login procedure of the service through asynchronous slow single authentication login. Can be recovered. According to an embodiment, among a plurality of services capable of single authentication, if there is a service that requires a login when an event requiring login occurs or a service that periodically requests re-authentication, the browser performs an asynchronous slow single authentication login. You can proceed with the login process.

1 is a block diagram of a single authentication system according to an embodiment.
2 is a flowchart illustrating a single authentication login according to an embodiment.
3 is a flowchart illustrating a single authentication logout according to an embodiment.
4 and 5 each is a flow diagram of a lazy single authentication login according to one embodiment.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those of ordinary skill in the art may easily implement the present invention. However, the present invention may be implemented in various different forms and is not limited to the embodiments described herein. In the drawings, parts irrelevant to the description are omitted in order to clearly describe the present invention, and similar reference numerals are attached to similar parts throughout the specification.

Throughout the specification, when a part "includes" a certain component, it means that other components may be further included rather than excluding other components unless specifically stated to the contrary. In addition, terms such as "... unit", "... group", and "module" described in the specification mean a unit that processes at least one function or operation, which can be implemented by hardware or software or a combination of hardware and software. have.

The terminal includes a program stored in a computer-readable storage medium, and hardware such as a processor, a memory, a display, and a communication module. The processor runs the program in cooperation with the hardware. The display displays a user interface screen provided by the program and receives user input. The communication module communicates with various servers described in the present invention through a communication network. In the description, the program may be a browser program that displays information provided by a server on a screen and transmits input information to the server.

The terminal may be implemented in various forms, and may be implemented in the form of various types of computers such as laptop computers, desktop computers, and mobile terminals, wearable devices, and TV terminals.

1 is a block diagram of a single authentication system according to an embodiment.

Referring to FIG. 1, a single authentication system is constructed so that service systems that individually provide each of various services are interlocked. Here, three service systems 10, 20, and 30 are assumed and described. The user terminal 40 accesses various service sites (eg, kakao.com, daum.net, melon.com) through a browser. Service sites can exist in different domains.

Each service system includes an authentication server (100, 200, 300) in charge of various authentication processes such as login required for service use, a service server (130, 230, 330) that provides the service to the user terminal, and the corresponding service. Databases 150, 250, and 350 for storing necessary data may be included, and servers and databases constituting each service system may be designed in various ways.

In the description, it is assumed that each service system has service-specific authentication servers 100, 200, and 300, and that each authentication server individually performs access authentication for each service subscriber. The authentication server 100 manages connection information of accounts issued from other services through a main account, and provides service systems 10, 20, 30 through the main account input from the browser of the user terminal 40. You can manage a single authentication procedure such as single authentication login and single authentication logout to multiple services provided by ). Here, the service server 130 provides a login page displayed on the browser of the user terminal 40 and transmits the main account information input from the login page to the authentication server 100. In the future, the authentication server 100 may be referred to as a subject authentication server, the service server 130 may be referred to as a subject service server, and the database 150 may be referred to as a subject service database, and the service system 10 including these may be referred to as a subject service system. The user terminal 40 or the browser of the user terminal 40 is a client that communicates with the authentication servers 100, 200, and 300 and the service servers 130, 230, and 330. The browser is a program installed in the user terminal 40, and the types of browsers may vary, and may be a general-purpose browser provided by a browser developer.

Taking multi-domain services as an example, the host authentication server 100 is an authentication and session management server based on a main account (eg, Kakao account), and the authentication server 200 is a service A (eg, daum.net). It is a server that manages access to, and the authentication server 300 may be a server that manages access to service B (eg, melon.com). For example, if the Kakao account is the main account linked to the Daum service account and the Melon service account, the Daum service and Melon through the linkage between the browser and the authentication servers (100, 200, 300) while logged in with the Kakao account Single authentication of the service proceeds. Therefore, the user can use the corresponding services without having to log in separately to the next service and the Melon service.

When the service accounts are integrated, single authentication starts with the subject authentication server 100 and the subject service server 130. The authentication servers 200 and 300 of Service A and Service B interwork with the host authentication server 100 to verify the values received from the browser, and allow access (login) to the service site through the verification result. Specifically, after the host authentication server 100 creates a login token and a login session for the main account (eg, Kakao account), if there are service A and service B connected to the main account, a token for single authentication ( SSO token). Thereafter, the authentication servers 200 and 300 of Service A and Service B verify the SSO token delivered from the browser of the user terminal from the host authentication server 100, and the browser of the user terminal that has received the SSO token based on the verification result. Allows access through. Here, the SSO token may be asynchronously delivered to the authentication server of the service, and the delivery method may be determined according to the characteristics of the browser.

Meanwhile, the database 150 stores authentication and session management information generated by the host authentication server 100. In particular, the logged-in main account and the log-in session created corresponding to the main account are managed as a public session (global session). The database 150 may store a main account and a connection account. The public session is a session in which several services connected to the login session are added. Accordingly, the host authentication server 100 may log out a single authentication by deleting the public session.

In addition to account and session information, the database 150 includes a login token issued by the host authentication server 100 to a client, an SSO token, and client information for client identification (e.g., IP address, browser information, as shown in Table 1). OS information, etc.) can be managed.

account Account login token SSO token Client information Public session information Account 1 Account login token 1 SSO token 1 Client1 Public session key1;
Account service (kakao.com)
Service A (daum.net)
Service B (melon.com) Account 2 Account login token2 SSO token2 Client2 Public session key2;
Account service (kakao.com)
Service B (melon.com)

A browser (client) mounted on the user terminal 40 can communicate with authentication servers through various protocols. In particular, there is a cross domain problem like the same-origin policy, so inter-domain calls or access restrictions exist in the browser. To solve this, the browser may request a login, request a logout, request SSO authentication, and send a cookie in a specific format (eg, JSONP). The browser calls the login pages of the services with a specific tag (eg, iFrame), and can implement a single authentication procedure of the present invention through the specific tag. Alternatively, the browser may implement a single authentication procedure of the present invention through redirection. [0023] Fig. 2 is a flow chart of a single authentication login according to an embodiment.

Referring to FIG. 2, the browser of the user terminal 40 accesses the host service server 130 in charge of single authentication, and makes a login request for an account (S110). The login request may include account information such as email, phone number, or password. The host service server 130 provides a single authentication login page to the browser of the user terminal 40.

The host service server 130 requests the host authentication server 100 to authenticate the account included in the login request (S112). The account authentication request may include account information included in the login request.

The host authentication server 100 checks the account included in the account authentication request, and when the account authentication is successful, transmits a login token for the account to the host service server 130 (S114). In addition, the host authentication server 100 creates a login session for an account upon successful authentication. When account authentication fails, the browser of the user terminal 40 displays a login page so that the login request can be retried.

The host service server 130 transmits the login token to the browser of the user terminal 40 (S116). The account login token is set as a cookie in the browser.

The browser of the user terminal 40 having completed account authentication makes a single authentication (SSO) start request to the host service server 130 (S120). The SSO initiation request may include a login token and client information. The client information is information on the user terminal 40 or a browser, and may include at least one of, for example, IP address, browser information, or OS information.

In response to the SSO start request, the host service server 130 requests the host authentication server 100 to issue an SSO token for single authentication (S122). The SSO token issuance request may include a login token and client information included in the SSO request.

The host authentication server 100 checks the connection services of the account that issued the login token (S124).

The host authentication server 100 generates the service A and service B connected to the account as an SSO service list, and transmits the SSO service list and the SSO token to the host service server 130 (S126). The host authentication server 100 manages the ownership of the issued SSO token. After mapping the SSO token to the client information requesting the issuance of the SSO token, the mapped client information may be used when verifying the ownership of the SSO token. The SSO service list can be written as a service API url address or a service symbol string. In this case, when there are a plurality of services connected to the account, the host authentication server 100 may check whether each service is capable of SSO authentication, and generate only the services capable of SSO authentication as an SSO service list. Even if there are a plurality of services connected to the account, if there is no service capable of SSO authentication, the host authentication server 100 may not issue an SSO token and may notify the host service server 130 that SSO authentication is unnecessary.

The host service server 130 transmits the SSO service list and the SSO token to the browser of the user terminal 40 in response to the SSO start request (S128). The SSO service list may include an access address of the authentication server 200 of Service A and an access address of the authentication server 300 of Service B. The SSO token can be set as a cookie in the browser.

The browser of the user terminal 40 that has received the SSO token makes an SSO authentication request to the authentication server 300 of service B and the authentication server 200 of service A included in the SSO service list (S130 and S140). The SSO authentication request includes the issued SSO token and proceeds asynchronously, and the order of S130 and S140 may be changed. At this time, the browser of the user terminal 40 may request SSO authentication by calling the login interface of each of the authentication server 200 and the authentication server 300 with a specific tag (eg, iFrame) containing the SSO token. . Since the browser requests SSO authentication asynchronously, failure of some services or texts in the client during the SSO authentication process may not affect SSO authentication of other services. In addition, since the browser requests SSO authentication asynchronously, it is possible to implement a flexible authentication system that enables SSO authentication requests to be made to the service when SSO authentication is required.

The authentication server 300 of service B requests the host authentication server 100 to verify the ownership of the SSO token whether the client requesting SSO authentication has ownership of the SSO token (S132). The ownership verification request may include an SSO token and information on the client that sent the SSO token.

The host authentication server 100 verifies the ownership of the SSO token included in the ownership verification request based on the client information mapped to the issued SSO token. It is added to the session (S134).

The host authentication server 100 responds to the authentication server 300 of service B with the result of verifying the ownership of the SSO token (S136). When the client that transmitted the SSO token is verified as the owner, the result of verifying the ownership of the SSO token may include a public session key along with the successful ownership verification. If the client that sent the SSO token is not the owner, the result of verifying the ownership of the SSO token includes a failure to verify the ownership.

The service B authentication server 300 sets a public session key for the browser (client) of the user terminal 40 (S138). The authentication server 300 of service B may obtain a public session key from the host authentication server 100. Meanwhile, when a public session key is included in the SSO token, the authentication server 300 of service B may set a session key included in the SSO token when the result of verifying the ownership of the SSO token is successful.

The service B authentication server 300 creates a service B authentication cookie in the browser of the user terminal 40 (S139). The service B authentication cookie is generated by the authentication server 300 of the service B in a unique manner.

Like the authentication server 300 of service B, the authentication server 200 of service A requests the host authentication server 100 to verify ownership of the SSO token (S142).

The host authentication server 100 verifies the ownership of the SSO token included in the ownership verification request based on the client information mapped to the issued SSO tokens. It is added to the public session (S144).

The subject authentication server 100 responds to the authentication server 200 of the service A with the result of ownership verification including the successful ownership verification and the public session key (S146).

The service A authentication server 200 sets a global session key for the browser (client) of the user terminal 40 (S148), and creates a service A authentication cookie in the browser of the user terminal 40 (S149). The service A authentication cookie is generated by the authentication server 200 of the service A in a unique manner.

The browser of the user terminal 40 may move to the target page or use the service A authentication cookie and the service B authentication cookie to move to the pages of service A and service B. That is, the user can use the service without having to go through an additional login procedure on the pages of Service A and Service B.

In this way, even if the authentication server 200 of Service A and the authentication server 300 of Service B exist separately, the single authentication system can integrate the authentication system and perform single authentication through interworking between the authentication servers. In particular, by allowing each authentication server to set an authentication cookie in its own way in the browser, each authentication server can perform single authentication while maintaining an existing authentication system. In this way, service sites connected to the account at the time of login can issue authentication cookies. Asynchronous method using Javascript can be used, but asynchronous single authentication can be implemented with various technologies.

On the other hand, synchronous single authentication login is also possible. The host authentication server 100 checks the status of service A and service B connected to the login account, and generates only the services capable of a single authentication process as an SSO service list. The host authentication server 100 generates service A and service B from among the services connected to the account as an SSO service list, and transfers the SSO service list and the SSO token to the browser of the user terminal 40. The SSO token may include a login session key (public session key), and is delivered to the authentication server of the corresponding service in the order of the services included in the SSO service list. After issuing the authentication cookie of the corresponding service, the SSO token may sequentially move to the next service until authentication of the services included in the SSO service list is completed.

3 is a flowchart illustrating a single authentication logout according to an embodiment.

Referring to FIG. 3, after the browser of the user terminal 40 logs in with a single authentication of FIG. 2, a logout request is made to the host service server 130 (S210 ). The browser of the user terminal 40 may enter a logout page provided by the host service server 130 when the user inputs a logout operation for a login session or when a specified logout situation occurs.

The host service server 130 requests the host authentication server 100 to authenticate the client's logout request (S212).

The host authentication server 100 authenticates the logout request based on the client information included in the logout request, and transmits the authentication result to the host service server 130 (S214). If the authentication is successful, the authentication result may include the authentication success and the SSO service list (service API url address or service symbol string) added to the public session. The SSO service list added to the public session includes services that have created a public session for the browser of the user terminal 40 based on the SSO token. When the authentication result includes an authentication failure, the host service server 130 provides a logout failure page to the browser of the user terminal 40.

If authentication is successful, the host service server 130 provides a logout page to the browser of the user terminal 40 and transmits a list of SSO services added to the public session (S216).

The browser of the user terminal 40 requests logout to the authentication server of the corresponding service based on the SSO service list added to the public session (S220, S230). Logout requests are processed asynchronously.

The authentication server 200 of the service A logs out to the logout request and responds to the logout to the browser of the user terminal 40 (S222). The service A authentication server 200 may delete the service A authentication cookie issued to the browser of the user terminal 40. The authentication server 300 of service B may delete the session created in the browser of the user terminal 40. The authentication server 300 of service B may delete only the service B authentication cookie when a separate logout processing procedure is not required.

The authentication server 300 of the service B processes the logout in response to the logout request and responds to the logout to the browser of the user terminal 40 (S232). The service B authentication server 300 deletes the service B authentication cookie issued to the browser of the user terminal 40. The authentication server 300 of service B may delete the session created in the browser of the user terminal 40. The authentication server 300 of service B may delete only the service B authentication cookie when a separate logout processing procedure is not required.

After completing the single logout procedure, the browser of the user terminal 40 moves to the target page.

According to another embodiment, a single authentication logout may be performed by redirection. Upon successful authentication of the logout request, the browser of the user terminal 40 returns a list of SSO services added to the public session. When the SSO service list is bound to the return url and transmitted, the logout request may be redirected to the authentication server of each service until there is no service remaining in the SSO service list, and the logout procedure may be repeated.

According to another embodiment, a single authentication logout may be performed using a common session deletion method. For example, the host authentication server 100 authenticates the logout request based on the client information included in the logout request, and when authentication for the logout request is successful, the logout target information in the database 150 (e.g. For example, public session information) can be deleted (destroyed). And, when the logout authentication is successful, the host authentication server 100 delivers the authentication result to the host service server 130, and the host service server 130 provides a logout success page to the browser of the user terminal 40. can do.

In this way, when the browser of the user terminal 40 requests logout for the login account after the browser of the user terminal 40 logs in for single authentication, the single authentication system may logout even multi-domain services logged in with a single authentication at once. That is, since the single authentication system manages the login session of the logged-in client as a public session in which services of multiple domains are added, when the login session created for the login account is terminated, the services added to the login session are also terminated at once ( expire).

4 and 5 each is a flow diagram of a lazy single authentication login according to one embodiment.

Referring to FIG. 4, even if there is at least one service connected to a login account (eg, Kakao account), any service (eg, service B) proceeds to SSO authentication immediately when account authentication is successful, as shown in FIG. 2. I can't. That is, after successful authentication for the login account, a single authentication login selectively proceeding for a specific service is called a lazy single authentication login.

For example, the authentication server 300 of Service B is set to log in when a user requests a specific event (e.g., posting a comment, registering frequently listened music, etc.), or the user attempts to log in explicitly. If it is set to log in in the case of logging in, the service B may be set to log in with a slow single authentication without the need to immediately perform SSO authentication upon successful authentication of the connected main account. Alternatively, when the authentication server 300 of the service B is set to periodically re-authenticate, the service B may re-authenticate the SSO with a slow single authentication login while the login session of the connected main account is maintained.

It is assumed that the browser of the user terminal 40 stores the account login token issued after login authentication for the account, and service B is assumed to be a lazy single authentication login. Here, the account login token is set as a cookie in the browser of the user terminal 40 by steps S110 to S116 of FIG. 2.

The browser of the user terminal 40 requests a login to the service server 330 of service B or a specific event requiring login (S310). The login request is an explicit login attempt operation, and the browser of the user terminal 40 receives a login request by the user from a web page provided by the service server 330 of the service B, or the browser of the user terminal 40 serves. This may be the case when moving to a web page provided by the service server 330 of B. A specific event that requires logging in may be, for example, posting a comment, registering frequently listened music, or the like.

The service server 330 of service B determines whether or not login is necessary based on the request of the browser of the user terminal 40, and since there is no valid service B authentication cookie issued by itself in the request, it responds with a login required response (S312). . If there is no authentication cookie or the authentication cookie is invalid, the service server 330 of Service B returns a response indicating that login is required.

The browser of the user terminal 40 receiving the login required response makes a lazy single authentication (SSO) start request to the host service server 130 (S320). The slow SSO initiation request may include a login token, and client information. At this time, the browser of the user terminal 40 may request a slow SSO start by transmitting a login token set as a cookie to the host service server 130 using a specific format (eg, JSONP). When the host service server 130 provides a login verification interface (API), the browser of the user terminal 40 calls the login verification API to the host service server 130 using a specific format (eg, JSONP). can do.

The host service server 130 requests the host authentication server 100 to issue an SSO token for the service B that has requested the slow SSO start (S322). At this time, the host service server 130 requests the host authentication server 100 to verify information included in the slow SSO start request (eg, login token, service B, client information, etc.) before the request for issuing the SSO token, and , Upon successful verification, it is possible to request the host authentication server 100 to issue an SSO token for service B.

The subject authentication server 100 transmits the SSO token issued for single authentication of the service B to the subject service server 130 (S324). The host authentication server 100 maps the SSO token to client information when issuing a new SSO token. In the case of the user terminal 40 already logged in with the main account, the SSO token is returned to the browser of the user terminal 40. If it is not the user terminal 40 logged in with the main account, it is necessary to log in with the main account, so the log-in procedure of FIG. 2 moves.

The host service server 130 transmits the SSO token to the browser of the user terminal 40 in response to the slow SSO start request (S326).

The browser of the user terminal 40 makes an SSO authentication request including an SSO token to the authentication server 300 of service B (S330).

The authentication server 300 of service B requests the host authentication server 100 to verify the ownership of the SSO token whether the client requesting SSO authentication has ownership of the SSO token (S332). The ownership verification request may include an SSO token and information on the client that sent the SSO token.

The host authentication server 100 verifies the ownership of the SSO token included in the ownership verification request based on the client information mapped to the issued SSO token. It is added to the session (S334).

The subject authentication server 100 responds to the authentication server 300 of service B with the result of verifying the ownership of the SSO token (S336). The result of verifying ownership of the SSO token may include a public session key along with successful ownership verification.

The service B authentication server 300 sets a public session key for the browser of the user terminal 40 (S338).

The service B authentication server 300 generates a service B authentication cookie in the browser of the user terminal 40 (S339).

Thereafter, the browser of the user terminal 40 may access various login services of the service server 330 of the service B through the service B authentication cookie.

Meanwhile, in step S320 of FIG. 4, the browser of the user terminal 40 transmits the account login token set as a cookie to the host service server 130 using a specific format (eg, JSONP), thereby starting a slow SSO. On request, some browsers may have a default setting so that cookies are not passed when calling a specific format (for example, JSONP). In this case, as shown in FIG. 5 below, a login token may be delivered in a redirection method.

Referring to FIG. 5, after step S312 of FIG. 4 of receiving a login required response from the service server 330 of service B, the browser of the user terminal 40 displays the host service server 130 in the page of service B. After redirecting to the single authentication login page, a lazy single authentication (SSO) start request is made (S410). The browser of the user terminal 40 moves to a single authentication login page (sso login url) of the host service server 130 in a redirection method. The slow SSO start request by the redirection method may proceed after the failure of the slow SSO start request by the calling method using a specific format (eg, JSONP) of FIG. 4. Alternatively, the slow SSO initiation request may be selected from a specific format (eg, JSONP) calling method and a redirection method.

The host service server 130 requests the host authentication server 100 to issue an SSO token for the service B that has requested the slow SSO start (S412). At this time, the host service server 130 may request the host authentication server 100 to verify the account login token, and upon successful verification of the account login token, the host authentication server 100 may request the host authentication server 100 to issue an SSO token for service B. have.

The host authentication server 100 transmits the SSO token issued for single authentication of the service B to the host service server 130 (S414). When issuing a new SSO token, the host authentication server 100 maps client information to the SSO token.

The host service server 130 transfers the browser of the user terminal 40 to the page of the service B with the SSO token (S416).

The browser of the user terminal 40 makes an SSO authentication request including an SSO token to the authentication server 300 of service B (S420).

The authentication server 300 of service B requests the host authentication server 100 to verify ownership of the SSO token whether the client requesting SSO authentication has ownership of the SSO token (S422). The ownership verification request may include an SSO token and information on the client that sent the SSO token.

The host authentication server 100 verifies the ownership of the SSO token included in the ownership verification request based on the client information mapped to the issued SSO token. It is added to the session (S424).

The host authentication server 100 responds to the authentication server 300 of the service B with the result of verifying the ownership of the SSO token (S426). The result of verifying ownership of the SSO token may include a public session key along with successful ownership verification.

The service B authentication server 300 sets a public session key for the browser of the user terminal 40 (S428).

The service B authentication server 300 generates a service B authentication cookie in the browser of the user terminal 40 (S429).

Thereafter, the browser of the user terminal 40 may access various services requiring login of the service server 330 of the service B through the service B authentication cookie.

As described above, referring to FIGS. 4 and 5, the single authentication system may implement active SSO applied immediately after login to the main account and passive SSO applied to access individual services after logging in to the main account. When logging in to the main account, even if some services connected to the main account are in a failed state, single authentication can be performed normally through a slow single authentication procedure. In particular, the host authentication server 100 can store single authenticated services in the login session through a single slow authentication procedure, and manage the session by single authentication even after logging in, and authentication sessions when authentication expires/non-authentication of individual services Can provide recovery process.

The embodiments of the present invention described above are not implemented only through an apparatus and a method, but may be implemented through a program that realizes a function corresponding to the configuration of the embodiment of the present invention or a recording medium in which the program is recorded.

Although the embodiments of the present invention have been described in detail above, the scope of the present invention is not limited thereto, and various modifications and improvements by those skilled in the art using the basic concept of the present invention defined in the following claims are also provided. It belongs to the scope of rights.

Claims (14)

A method in which a host authentication server in charge of single authentication of multi-domain services performs single authentication in connection with authentication servers of the multi-domain services,
Authenticating the main account included in the client's login request, and issuing a login token to the client who successfully authenticated,
Generating, among the multi-domain services, services connected to the main account to which the login token was issued, as a first service list,
Issuing a single authentication token to the client together with the first service list,
When receiving a single authentication token verification request from the authentication server of each service included in the first service list, verifying whether the token included in the single authentication token verification request is the single authentication token issued to the client,
Adding each service successfully verified to the session of the main account, and transferring the session key to the authentication server of the corresponding service,
Upon receiving the logout request from the client, generating services added to the session of the main account as a second service list, and transmitting the second service list to the client, and
Deleting the session of the main account for single authentication logout of services added to the session of the main account,
The client is a browser of a user terminal,
The authentication server of each service included in the first service list sets a key of the session for the client, and generates an authentication cookie that enables the client to use the service,
The authentication server of each service included in the second service list receives a request to log out of the service from the client. In claim 1,
The step of verifying whether the single authentication token is
A single authentication method for asynchronously receiving the single authentication token verification request from an authentication server of each service included in the first service list. delete delete In claim 1,
After issuing the login token to the client, receiving a single lazy authentication start request for a specific service from the client, and
Issuing the single authentication token or a new single authentication token to the client, further comprising,
The client
In a state in which the server of the specific service is connected, a login confirmation interface provided by a service server related to the host authentication server is called to request the slow single authentication start, or
In a state of being connected to the server of the specific service, redirecting to a single authentication login page provided by a service server related to the host authentication server and requesting the start of the slow single authentication. delete delete delete As a method for single authentication by a browser of a user terminal with multi-domain services,
A host service system that manages single authentication of multi-domain services, requesting a login for a main account, and receiving a login token for the main account from the host service system,
Transmitting a single authentication start request including the login token and client information to the host service system, and issuing a single authentication token together with a first service list including services connected to the main account from the host service system , And
Transmitting a single authentication request including the single authentication token to an authentication server of each service included in the first service list, and setting an authentication cookie for the service issued from the unique authentication server of the service. And
Requesting logout to the host service system, and receiving a second service list including services added to a session created when logging into the main account from the host service system, and
Requesting logout of the service to the authentication server of each service included in the second service list
Further comprising, a single authentication method. delete In claim 9,
Receiving a login request response from the service server while being connected to a service server of a specific service among the multi-domain services,
Requesting the host service system to start a single lazy authentication for the specific service,
Issuing the single authentication token or a new single authentication token from the host service system, and
Transmitting a single authentication request including a token issued for the specific service to the authentication server of the specific service, and setting an authentication cookie for the specific service issued from the authentication server of the specific service
Further comprising, a single authentication method. In clause 11,
The step of requesting the start of the slow single authentication
A single authentication method for requesting the start of the slow single authentication by passing the login token to JSONP. In clause 11,
The step of requesting the start of the slow single authentication
After redirecting from the service page of the specific service to the single authentication login page of the host service system, the single authentication method is requested to start the slow single authentication by passing the login token to the host service system. In claim 13,
The step of requesting the start of the slow single authentication
When the login token cannot be delivered to JSONP, the slow single authentication is performed by redirecting from the service page of the specific service to the single authentication login page of the host service system, and then passing the login token to the host service system. A single authentication method that asks for initiation.

Images