Method and a system for authenticating a user

专利摘要:
49 Abstract Method for authenticating a user, comprising the steps of a) providing' a central server (lOl), in communicationwith at least two authentication(llO,l20,l30) (l50); service providers and at least one user service provider associating each authentication service provider withat least one respective available level of authenti-cation; receiving a request from the user service provider to authenticate a particular user accessing the userservice provider via an electronic device (l70,l80);identifying a minimum level of authentication; the central server identifying a selected one (llO) of said authentication service providers; either providing user credential data directly to theselected authentication service provider, withoutsaid user credential data being supplied to the cen-tral server, or determining that the selected authen-tication service provider has an active authentica-tion session for the particular user; and causing the selected authentication service providerto authenticate the particular user and to provide an authentication response. The invention also relates to a system. Application text 2014-08-08 140032SE
公开号:SE1450927A1
申请号:SE1450927
申请日:2014-08-08
公开日:2016-02-09
发明作者:Philip Hallenborg；Mindaugas Kezionis
申请人:Identitrade Ab；
IPC主号:

专利说明:

Method and system for authenticating a user The present invention relates to a næthod and a system for authenticating a user. In particular, the invention relates to remote authentication of a user, via an electronic device operated by the user.
In many circumstances a user needs to be remotely authenti-cated, in order for a remotely arranged party to verify theidentity of a user contacting the remotely arranged party. Inparticular, this is the case in digital communication appli- cations, especially online. For instance, within the fields of e-commerce, online transactions and banking, digital ser- vice provision and user account registration, a user contact-ing a central server over the internet needs to be authenti- cated by providing some type of proof of his or her identity.
There are many conventional technologies for providing suchauthentication, ranging from less secure alternatives such assimply entering a user name and a password, via more elabo-rate techniques such as Public Key Infrastructure-based sys-tems, to multi-factor authentication solutions involving SMS(Short Message Service) messages sent to a mobile phone con- trolled by the user, or even biometric measurement data, and SO On.
There is a problem in that it is costly for a user service provider to provide such authentication procedures. In gen- eral, in order to provide adequate security and user conven-ience, complex or different authentication methods shouldalso in many cases be provided. Especially for small user service providers, this can represent a significant implemen- tation cost.
Application text 2014-08-08 140032SE Another problem is that it is difficult for individual users to keep track of various authentication tools, login creden- tials, etc., for use with different user service providers.
One known solution. to these problems is to allow a third party, such as a large, well-known company, to authenticate a user on behalf of the user service provider. Examples include the so called OpenID initiative, in turn using the open au- thentication standard. Oauth, using' which. an authenticating party can provide an access token, using which the proprietor of said access token can obtain access to a defined subset ofservices provided by the authenticating party. Another exam- ple is Facebook (registered trademark) Connect.
However, such conventional methods often impose specific requirements on the user, such as first signing up for anaccount with. a particular authentication service provider.For service providers, there is a desire for increased flexi-bility and possibility to tailor the authentication type toeach particular authentication need, such as depending on thetype of service provided. or the type of electronic devicethere is a desire for an authentica- used by the user. Also, tion service which can be acquired at a lower cost.
A related problem is that it is desired for users not to have to enter personal information, such as billing address, re-peatedly when ordering transactions with various serviceproviders. Also, many user service providers, such as onlinevendors, have a desire to obtain more detailed user infor- mation as early as possible during the ordering procedure of a transactions, such as a purchase.
Another problem is to provide a simple and efficient way of allowing authentication service providers to authenticate Application text 2014-08-08 140032SE users across borders, in which case access to agreements andthe operation under different legislations may impose signif- icant cost to small-scale user service providers.
The present invention solves the above described problem.
Hence, the invention relates to a method for authenticating a user, which method characterised in that the method comprises the steps of a) providing a central server, in communication with. at least two authentication service providers and at least one user service provider; b) associating each authen-tication service provider with at least one respective avail-at the central able level of authentication; c) receiving, server, a request from the user service provider to authenti-cate a particular user accessing the user service providervia an electronic device; d) identifying a minimum level ofauthentication to use for the said request; e) causing thecentral server to identify a selected one of said authentica-tion service providers which is associated with at least oneallowable level of authentication which is at least as highas the said minimum level of authentication, and which se-lected authentication service provider is capable of authen-said allowable level of ticating said particular user at authentication; f) either providing user credential data associated with said particular user directly to the selected authentication service provider, without said user credential data being supplied. to the central server, or determiningthat the selected authentication service provider has anactive authentication session for the particular user; and g) causing the selected authentication service provider to au-thenticate the particular user and to provide an authentica- tion response.
Application text 2014-08-08 140032SE Furthermore, the invention relates to a system for authenti- cating a user, wherein the system comprises a central server, in communication with at least two authentication service providers and at least one user service provider, wherein the system. further comprises a database comprising respectiveassociations between each authentication service provider andat least one respective available level of authentication,which system is characterised in that the central server isarranged to receive a request from the user service providerto authenticate a particular user accessing the user serviceprovider via an electronic device, to identify' a minimumlevel of authentication to use for the said request and toidentify a selected one of said authentication service pro-viders which is associated with at least one allowable levelof authentication which is at least as high as the said mini-mum level of authentication, and which selected authentica-tion service provider is capable of authenticating said par-ticular user at said allowable level of authentication, inthat the system is arranged to thereafter either provide usercredential data associated with said particular user directlyfrom the user service provider to the selected authenticationwithout service provider, said. user credential data being supplied. to the central server, or to determine that the selected. authentication. service provider* has an active au-thentication session for the particular user, and in that thesystem is arranged to cause the selected authentication ser-vice provider to authenticate the particular user and toprovide an authentication response to the user service pro-vider.
In the following, the invention will be described in closerdetail, which: partly with reference to the enclosed drawings, in Application text 2014-08-08 140032SE Figure 1 is an overview diagram of a system according to thepresent invention and arranged to perform a method accordingto the invention; Figure 2 is a flow chart depicting the various method stepsof a method according to a first aspect of the present inven-tion; Figure 3 is a flow chart depicting the various method stepsof a method according to a second aspect of the present in-and vention; Figures 4a-4g show various interfaces provided by a web browser on the display of a user electronic device.
All figures share reference numerals for the same parts.
Figure 1 shows a system 100 according to the present inven-tion for authenticating a user via an electronic device 170,180. The system 100 is furthermore arranged to perform themethods described herein according to various aspects of thepresent invention.
In one aspect of the invention, the system 100 comprises a central server 101, in communication. with a database 102; comprising' or at least one, preferably at least two, prefera- bly a plurality of user service providers 150 (only one shown in figure 1); and. at least one, preferably' at least two,preferably a. plurality 110, 120, 130. service providers In another aspect of the invention, the system 100 only comprises the central server 101, the database 102 and any software provided by the central server 101 to con- nected. authentication service providers 110, 120, 130 and user service providers 150, which are as such thus not part of the system 100.
The database 102 comprises information regarding registered authentication service providers 110, 120, 130, user service Application text 2014-08-08 140032SE providers 150 and 'users, such. as required. minimum. allowed authentication levels for various conditions.
The user service provider 150 may be any type of party capa- ble of providing services to users remotely, such as online vendors; public service actors such as libraries, governmentinstitutions or the like; financial institutions, such asonline banks; payment providers; online communities; communi- cation services; or any other actor providing a service to users remotely in a way so that the identity of the user isneeded in order to provide at least one of the services pro- vided. It is preferred that users communicate with the ser- vice provider 150 directly over a digital communications network such as the internet. In the following, when the term “internet” is used, it is understood that any type of digital communications network may be used, as applicable, such aswired or wireless local area or wide area networks.The authentication service providers 110, 120, 130 may, fur- thermore, be any type of party capable of providing authenti- cation services to users remotely, and in particular arrangedto perform authentication of users, such as online vendors; public service actors such as libraries, government institu- tions or the like; financial institutions, such. as onlinebanks; payment providers; online communities; communicationservices; or any' other* actor* the relationship of which. to each user requires that the identity of the user in questionis safely established by a user authentication function pro-120,110, 130. It is120, 130 vided by the authentication provider 110,preferred. that the authentication providerscommunicate directly with each respective user, over a digi- tal communications network such as the Internet.
Application text 2014-08-08 140032SE As used. herein, the term. “authentication service” means a remotely provided service for authenticating a user, compris- ing establishing with a certain minimum level of security a correct identity of the user. Such a minimum level of securi- ty, such as a nfinimum level of assurance (LOA), is herein denoted “authentication level”. Examples of such authentica- tion levels are those definitions of which are provided by NIST (National Institution of Standards and Technology, USA), according to which there are at least four basic levels of assurance levels, ranging from low security procedures where it is only tested whether it is the same user accessing a service at different occasions (“Level 1") up to high securi- ty procedures where authentication is dependent upon the user's possession of a strongly encrypted cryptographic key (“Level 4"). See www.nist.gov for further information. Here- in, it is preferred that each authentication service provider 110, 120, 130 is unambiguously associated with one or several certain available well-defined authentication levels, the requirements of which the authentication service in questionfulfills, and that each authentication service provider isassociated. with. a certain. respective minimun1 supported. au-thentication level. It is possible that a particular authen-tication service provider is associated with different mini-mum authentication levels in relation to different users. Itis preferred that this information is stored in the database102 and accessible from the central server 101. The infor- mation may, for instance, be supplied in an initial registra- tion step of each authentication service provider 110, 120, 130, and may subsequently be updated, for instance in reac- tion to new information in relation to specific users. It isalso possible that available authentication levels in rela-tion to a specific user are provided, by request from the central server 10 to one or several authentication service Application text 2014-08-08 140032SE providers that have been identified as being available forauthenticating the user in question (see below).It is realized that each one of entities 101, 150 may be 110, 120, 130, implemented as a standalone, internet connected server; a distributed or virtual set of servers; or in any other configuration, as long as the entity in question pro-vides a well-defined interface for communications to and from the entity.
Each user communicating with the system 100 uses an electron- ic device, which is preferably arranged to communicate with the system 100 over a digital communications network such as the internet. In figure 1, such devices are exemplified by a mobile phone 170 of so-called smartphone type and a portable computer 180. However, the electronic device can be any de- vice capable of communicating with the system 100, such as a desktop computer or za machine-to-machine interface. It is preferred that the device 170, 180 is of general-purpose type, and it is also preferred that the device comprises arespective display 171, 181 capable of providing an interac-tive graphical user interface to the user.
The user is preferably a human being, but in some aspects theuser* may' be a machine-implemented. communication. part in amachine-to-machine implemented. system. In the latter case, the electronic device 170, 180 may be comprised in or consti- tute the machine in question.
Figure 2 shows a method according to a first aspect of thepresent invention for authenticating a user. In a step 201, the method starts.
Application text 2014-08-08 140032SE In a step 202, the central server 101 is provided, and is arranged to be in communication with at least two authentica-120, tion service providers 110, 130 and at least one user service provider 150, that are also provided. It is realizedthat this step 202 can be performed in advance and only one time for several runs of the method.
In a step 203, each authentication service provider 110, 120,130 is associated. with at least one respective availablelevel of authentication. Each particular provider 110, 120, 130 may be associated with several available such levels, inwhich case one of the available levels for a certain provider110, 120, 130 is considered to be the lowest, or least safe, level. For instance, adding another identification factor, such as a physical token owned by the user, or adding encryp-tion, would make the authentication level safer.
According to a preferred embodiment, in a step 204, which canbe performed in advance of the existence of a need for theuser service provider 150 to authenticate the user, the useris authenticated by a certain authentication service provid-er. This may, for instance, mean that the user successfullylogs into a web page provided by the authentication serviceprovider in question, or that the user in any other suitablemanner provides proof, at a certain authentication level, ofthe identity of the user in question. It is preferred thatsuch authentication in step 204 comprises the user providingsome type of user credential data to the authentication ser-vice provider.
Herein, “credential data” is to be understood as all types ofuser-specific information that can be provided from a uservia an electronic device and that can be used by an authenti- cating party to identify or prove the identity of the user in Application text 2014-08-08 140032SE question, such as user name - password combinations; PIN codes; cryptographic keys; hash values; biometric data, such as fingerprint data; and so on.
In other words, after step 204, the authentication serviceprovider in question holds information regarding the user, inparticular user credential data allowing the authenticationservice provider* to authenticate the user* at a particularauthentication level. This authentication may be performed inconnection to the authentication service provider in questionproviding some type of service to the user. After the authen-tication in step 204, (see below), or an authentication in step 221it is preferred that the authentication service pro-vider has an active authentication session with respect tothe authenticated user. This may mean that the user does not have to provide credential data when being authenticated again within. a predetermined. time period. during' which thesaid session is active. The time period may be defined by the authentication service provider.
Preferably, in a step 205, the authentication service provid-er in question, more preferably several, or all, of the au-thentication service providers 110, 120, 130, are caused to be remotely configurable by individual users so that they canprovide information regarding their respective capability toauthenticate the users in question to the central server 101.Hence, the user in question may remotely instruct the authen- tication service provider in question, preferably over theinternet and preferably in connection to the authenticationstep 204, such as via a user control provided as an integrat-ed part of a web page displayed as a result of a successfullogin with the authentication service provider in question,to, upon request from the central server 101 or automatically upon authentication of the user in question, provide infor- Application text 2014-08-08 140032SE ll mation indicating that the authentication service provider inquestion is capable of authenticating the user at least at the said authentication level, and preferably also to pro- vide, in a subsequent step 224, user information to the graphical user service interface (see below).
In particular, the, several or all authentica- 120, in a step 206,tion service providers 110, 130 is or are arranged tonotify the central server 101 when a user has been authenti-cated by the authentication service provider in question.
In a preferred step 207, which is preferably performed as aninitial step in connection to setting up an association be- server 101 and. a certain authentication 120, 130, tween the centralservice provider 110, but which may be performed atany time before step 218, a respective template for a secondinteractive graphical user interface is provided to the or those authentication service providers that will use such templates, see below.According to the said first aspect of the present invention,in a step 211, the central server 101 receives a request,from one 150 of said one or several user service providers,to authenticate a particular user accessing the user serviceprovider 150 in question via an electronic device 170 or 180.This request can be provided in different ways.
As an example, the central server 101 may be directly provid-ed, for instance from the user, with information indicatingthat the user wishes to be authenticated using a particularspecified authentication service provider 110, 120 or 130, inturn providing an adequate authentication level for the pre-sent purposes.
In another example, the user may be presented with a list of available authentication service providers Application text 2014-08-08 140032SE 12 with. which. the central server' 101 is in communication. and that can deliver an adequate authentication level, from which list the user can select a certain authentication service provider to use for a later authentication step 220.However, figure 2 illustrates an alternative, preferred way,according to which the user first initiates contact with theuser service provider 150, and it is the user service provid-er that in turn requests, possibly via an interface providedby the user service provider to the user, the central server 101 to authenticate the user. In general, and. as will be explained in the following, the central server 101 may makethe decision automatically as to what specific authenticationservice provider that will be used to authenticate the user.
Hence, in a preferred step 208, a first interactive graphicaluser interface is provided by the user service provider 150.For instance, the user service provider 150 comprises a webserver providing a web page which is the first interface. Ina step 209, the user is provided with remote access to theuser service provider 150 via this first interface, displayedto the user on the display 171, 181 of the device 170, 180 used by the user, by the user service provider 150. For in- stance, the device 170, 180 may comprise a web browser ar-ranged to read and display the first interface provided bythe user service provider 150 web server.
In a preferred step 210, which may be performed at any time prior to step 225 but preferably is performed before step211, a particular user service transaction. is identified,which transaction. is to be performed. by the user service provider 150 for, to or on behalf of the user, and. which requires the user to be authenticated before being performed.
Application text 2014-08-08 140032SE 13 Then, in step 211, the user service provider 150 requests the central server 101 to authenticate the user, in other words to provide an authentication service of the user. Preferably, the request comprises or implies a specific allowable authen- tication level, as dictated by the type of transaction and/or the particular user service provider 150 and/or the particu- lar user or user category. The allowable authentication level is the minimal authentication level that is allowed for au- thentication of the user under the current conditions. The database 102 may comprise information regarding what types of transactions, particular user service providers and particu- lar users and/or user categories that require what ndnimum authentication levels.
According tm) a preferred embodiment, the ndnimum allowable level of authentication used for each authentication service provider 110, 120, 130 is caused to depend on at least one of the collection of parameters consisting of type of the elec- tronic device; type and/or provider of a graphical user in- terface via which the user accesses the user service provid- er; the access of the authentication service provider in question to information identifying the particular user; geographical location of the electronic device; and/or the existence of an active authentication session with the au- thentication service provider in question.
It is realized, as is illustrated in figure 3 (below), that the request in step 211 may also be performed in an indirect way' by the service provider 150, via the first graphical interface. The, the service provider 150 is not directly involved at the moment of the request, which is rather per-formed by for instance the device 170, 180 on behalf of the user service provider 150.
Application text 2014-08-08 140032SE 14 In a step 212 according to the said first aspect of the in- vention, it is determined, preferably by the central server101 and preferably based upon the said available authentica-tion-related information, an allowable authentication levelto use for the said request, which level is required to au- thenticate the user under the current conditions. the central server is arranged to identify a 110, In a step 214,selected. one of said. authentication. service providers120, 130 which is associated with at least one level of au-thentication which is at least as high as the allowable au-thentication level, and which authentication service provideris capable of authenticating the said particular user at the allowable authentication level.
According to a preferred step 213, preceding step 214, thecentral server 101 is however arranged to first identify, forseveral authentication service providers 110, 120, 130, a respective offered sell price for performing user authentica-tion at the allowable level of authentication. For instance,the central server 101 may be arranged to request a respec-tive sell price at which each respective authentication ser-vice provider is willing to perform the user authenticationin question, preferably with knowledge of the particular user to be authenticated. Alternatively, the central server 101 has beforehand received price lists from several authentica-tion service providers regarding various types of authentica- tions.
Once the authentication service providers have responded tothis request or the price list information has been analyzed,the central server 101 is arranged to identify at least one,preferably exactly one, authentication service provider of- fering a lowest sell price at the respective allowable level, Application text 2014-08-08 140032SE and to use this authentication service provider as the saidselected authentication service provider in the following.
According to one preferred embodiment, an auction over one orseveral bid rounds is performed among authentication service120, providers 110, 130 being capable of providing at least the allowable authentication level, the final winner of which auction is the selected authentication service provider to use for the authentication in question.
It is also possible for the central server 101, via the userservice provider 150 such as via the first graphical userinterface, to allow the user to select what authenticationservice provider to use among a set of lowest-bidding authen-tication service providers.
In a preferred step 215, the central server 101 evaluates ifat least one authentication service provider could be identi-fied. as the selected. authentication service provider. Fornone of the connected authentication service pro- 120, instance, viders 110, 130 may have been able to provide at least the allowable authentication level, or none may' have been able to authenticate the particular user. If an authentica- tion provider was identified in step 214, the method skips to step 217. Otherwise, it is preferred that the steps 217-225 are not performed, but the user service provider 150 is in- stead caused to authenticate, in a step 216, the particular user for the particular transaction in question without in- volving any of said authentication service providers 110, 120, 130. Preferably, this means that the user service pro- vider 150 performs its own, conventional, default procedure for authenticating the user.
Application text 2014-08-08 140032SE 16 In a preferred step 217, the user is then presented, via agraphical user interface, preferably the above mentionedfirst graphical user interface on the display 171, 181, with an option whether or not to authenticate using one of the authenticating service providers 110, 120, 130. Preferably,it is not specified at this point to the user which of theauthentication service providers that was identified in step214. If the user does not choose to allow such authentica-tion, the method again skips to step 216 rather than perform- ing steps 218-225.
It is furthermore preferred that the option being presentedin step 217 is comprised in the first interaction, relatingto user authentication. with regards to the transaction inquestion to be performed, between the user and the interac-tive graphical user interface provided to the user by theit is preferred that the 150, the user service provider 150. Hence,service provider 120, 130, communications between the user authentication service providers 110, and the cen- tral server 101 described above in relation to the previous steps are fully automatic, and do not require any user inter- action. In other words, when for instance loading the check- out page from an online vendor being the user service provid- er 150 in question, a user control may be automatically in- cluded in the which, when activated by the user, Pageacknowledges that the user wishes to allow any one of theauthentication service providers 110, 120, 130, or at leastany one of said providers that the user has previously agreedto use, such as in a preferences setting supplied previouslyto the central server or by checking corresponding controlson the respective web page of each donor, to perform the user authentication for the purchase.
Application text 2014-08-08 140032SE 17 According to the said first aspect of the invention, thereaf- ter either user credential data associated with the user inquestion is provided, in a step 219, directly to the selected authentication service provider, without the user credentialdata being supplied to the central server 101, or it is de- termined, in a step 220, that the selected. authentication service provider already has an active authentication sessionfor the user in question.Hence, in step 219 or 220, the central server 101 acts as a pure intermediary, 150 with binding together the user service provider several available authentication service 120, 130, one of providers 110, without ever gaining actual knowledge of the specific credential information. necessary for performing said authentication. Since the credential data is not provided. to the central server 101, it is neither stored therein, nor in the database 102.According to a preferred embodiment, the provision in step219 is made possible by a step 218, in which the above men-tioned first graphical user interface is arranged to in turnactivate a second user interface. This second user interfaceis then arranged to allow the user in question to communicatedirectly with the selected authentication service provider,thereby to supply said user credential data to the selectedauthentication service provider without it passing via thecentral server 101.
According to one preferred embodiment, the second user inter-face is an interactive graphical user interface provided tothe user on the display 171, 181 of the electronic device170, 180, and via which the user can enter the credential data.
Application text 2014-08-08 140032SE 18 For instance, in this case the second graphical interface may be in the form of a locally installed or remotely accessedapplication which is activated by the first graphical inter- face, and to which the active view of the display 171, 181 is transferred. upon such activation. However, according' to a preferred embodiment the second graphical user interface is provided. as an integrated graphical sub interface of the first graphical user interface, such. as within. a specific subpart, such as an iframe, provided within a web page com- prised in the first graphical user interface. For instance,the second graphical interface may be embodied as a particu-lar graphical field in the first interface, or a popup dialog launched by and from the first interface. In these and simi- lar examples, the second interface will typically compriseuser controls activatable for recording or entering, andproviding, credential data specifically selected for authen- ticating the user in relation to the transaction to be per- formed.
In a particularly preferred embodiment, the second interface is populated. with contents by the selected. authentication service provider itself, after initiation by the user service provider 150. In case a relevant template was provided by the central server 101 to the selected. authentication service provider in step 207, this template is preferably used as a basis for the population of the second interface with such user controls. For instance, a template for entering a user name and a password may comprise labels, user input fields for user name and password, as well as a field in which the authentication service provider can insert its logotype.
Also, a link to a standardized set of terms and conditionscan be provided as a part of the template, and so on. Ingeneral, it is preferred that the same template is provided to several authentication service providers, so that the user Application text 2014-08-08 140032SE 19 experience for the end user becomes as similar as possible when using different authentication service providers. Hence, in this case the selected. authentication service provider provides the actual second graphical user interface to the user service provider 150, the 180, or preferably' directly todevice 170, for provision to the user in question as apart of the first graphical user interface, based upon saidtemplate.
According to another preferred embodiment, the second inter-face may be provided by specific software or hardware whichis not part of the first graphical interface, but as initiat-ed by the first graphical interface, such as activation of afingerprint sensor on the device for reading the user's fin-gerprint and. providing' related. data to the central 101; serveractivating' a mobile telephony' operator* of the mobile phone of the user for sending an SMS (Short Message Sevice) to the mobile phone's telephone number (MSISDN), comprising an alphanumerical challenge to be nmnually provided to the user service provider by the user, or providing a request to the said. mobile telephone to re-enter the SIM (Subscriber Identity Module) PIN code; activating a cryptographically based authentication procedure which is locally activatable on the electronic device; or the like.
As mentioned above, in the alternative step 220, it is deter- mined that there is already an active authentication session involving' the selected. authentication service provider and the user in question, in which case the second interface is not presented but the method instead skips to step 221. For instance, the central server 101 may collect information regarding such an active authentication session, or the first interface may receive such information upon a request to the Application text 2014-08-08 140032SE selected authentication service provider to provide the sec- ond interface.
Then, in a step 221 according to the present invention, the selected authentication service provider authenticates the particular user. 219, In case credential data was supplied in stepthe authentication comprises the selected authenticationservice provider verifying the credential data. In case anactive session was determined to exist in step 220, the au- thentication comprises the selected. authentication service provider verifying the said active authentication session, inwhich case steps 220 and 221 may be one and the same.
In a subsequent step 222, an authentication response is pro- vided to the user service provider 150. This authenticationresponse may' be that no authentication was possible, forinstance since the user did. not supply' correct credentialdata to the authentication service provider, or that the authentication was validly performed based upon the supplieduser credential data or the fact that an active authentica-tion session existed. It is preferred that the authenticationresponse is provided from the selected authentication serviceprovider to the user service provider 150 via the centralserver 101.
According to a preferred embodiment, the user service provid- er 150 is then provided. with access, preferably' from. the selected authentication service provider and via the central server 101, to user information previously stored. by the selected authentication service provider and therein associ-ated with the particular user in question. According to analternative embodiment, the said user information is provideddirectly from the authentication service providers (or sever- al authentication service providers, see below) to the user Application text 2014-08-08 140032SE 21 service provider, by the central server providing a direct communication channel between the user service provider and the authentication service provider.
Herein, the term “user information” means any user metadata information, such as name, delivery and invoicing addresses, telephone numbers, credit card information, clothing sizes, contact lists, preferred configuration options, previous user behavior, etc., that is specific to the user* in question.Such user metadata has preferably been provided by the userin question as a part of the interaction between the user andthe selected. authentication service provider in step 204,under the security provided by an active authentication ses-sion, for instance during the course of the ordering of aservice the delivery of which requires user information to be provided by the user.
It is preferred that the said user information is used by theuser service provider 150 to automatically populate corre-sponding 'user interface, input fields iJ1 a graphical user such as the first graphical interface, provided to the userby the user service provider 150 and via the electronic de-vice 170, 180. Hence, all or only a subset of the user infor-mation which is required by the user service provider 150 mayfrom. the authentication for be available service provider such auto population. According to one preferred embodiment,all available user information is supplied as a part of theabove said authentication response. Alternatively, a separateinterface is provided to the user service provider 150 by the central server 101 for querying available user information.
It is furthermore preferred that access to user informationis only provided to the user service provider 150 after an explicit approval from the user in question. Such approval Application text 2014-08-08 140032SE 22 may' be delivered. for more or less general purposes in an initial step in which the user registers with the user ser- vice provider 150, the central server 101 or the authentica- tion service provider, or at a later point. According to the preferred. embodiment illustrated. in figure 2, the user is presented, in step 223, with an option, for instance in the form of an activatable user control, in the said first graph-ical interface, to automatically populate input fields usingavailable user data, or to populate only certain specifiedsuch input fields.
In case the user opts input fields in to automatically' populate in the interface, the population is performed in a preferred step 224. Non-automatically populated input fields are filled in by the user manually.
Thereafter, in a step 225, the transaction identified in step 210 is performed by the user service provider 150 in relationto the user in question. This may mean the ordering or pur- chasing' of a good or a service, involving' a transfer of funds; the publication. or transmittal of information; the activation of a subscription; the modification of user infor-mation; or any other conventional user service.
In step 226, the method ends.
According to a preferred embodiment, both the selected au-thentication service provider and the user service provider150 are accessed by the particular user in question via a webbrowser provided on the electronic device 170, 180. This isalso the case in a method according to a second aspect of theinvention, which is illustrated in figure 3 and which will bedescribed in the following. The following description of the method according to this second aspect of the invention will Application text 2014-08-08 140032SE 23 furthermore provide a Inore detailed. description. of certainpreferred aspects of the above described method according to the first aspect of the invention.
Hence, in a step 301 the method starts.
In a step 302, which. is similar* to step 202, the central at least one, preferably several, preferably a 110, 120, server 101, plurality' of, authentication service provider(s) 130 and at least one, preferably several, preferably a plu- rality' of user service provider(s) 150 are provided. The central server 101 is in communication with both the authen- tication service provider(s) 110, 120, 130 and the user ser- vice provider(s) 150.
According to this second aspect of the present invention, the authentication service providers are arranged to authenticate users via a respective authentication web interface each.
Such a web interface, of course, is an example of an interac- tive graphical user interface. Moreover, the user service providers are arranged to provide user services to particular users via a respective user service web interface each. Fur- thermore, the said web interfaces are provided to the user via one and the same web browser executed from (such as via a remotely provided web browsing service), or by, the electron- ic device 170, 180 belonging to the user in question. The user service web interface corresponds to the first user interface as discussed above in relation to figure 2.
In a preferred step 303, the said authentication web inter-face is provided by at least one of said authentication ser-vice providers 110, 120, 130, for instance by making availa-ble a corresponding web page by a web server comprised in said provider 110, 120, 130.
Application text 2014-08-08 140032SE 24 According to the second aspect of the present invention, access is provided, for a particular user and using the saidweb browser, to the authentication web interface of a partic-ular one of said authentication service providers 110, 120,130, and the user is authenticated by the particular authen-tication service provider in a manner which may be similar tothe one described above in connection to step 204.
Upon such an authentication of the user, the authenticationweb interface of the particular authentication service pro-vider is then caused to allow the central server 101 to placesuch as on the which a cookie in the above described web browser,electronic device 170, 180 used by the particular user,cookie identifies the particular authentication service pro-vider to the central server 101.
In the exemplifying embodiment illustrated in figure 3, this involves steps 304-310.
In a step 304, the web browser of device 170, 180 requests a web page from the particular authentication service provider,a web server functionality of which in turn, in a step 305, replies with. an authentication. web interface page in HTML (HyperText Markup Language) code or the corresponding. Thisweb page preferably comprises input fields for the user tofill in user credential data for transmittal to the particu-lar authentication service provider and subsequent use forauthentication of the user as described above. Hence, in a step 306, the user provides said credential data, using the web page, to the particular authentication service provider.According to a preferred embodiment, the user is furthermore provided with an option, in a step 307 which may be similar Application text 2014-08-08 140032SE to step 205 and which may be performed in addition to steps 304-306, to allow the particular authentication service pro- vider to provide, to the central server 101, information regarding the authentication status of the user, and prefera- bly also to be able to, in a subsequent step 331, provide user information to the user service provider 150 (see be-low). The option is preferably arranged as an integrated partof the authentication service provider web page provided instep 305, such as an activatable user control.
An example of such. an authentication service provider web page 410 is illustrated in figure 4a, as provided by authen-tication service provider 110 and shown on the display 181 ofthe device 180 and hence viewable to the user. A number ofuser controls 411 allow the user to enter user-specific cre-dential data for transmittal to the authentication. service provider 110 upon pressing the “Login” button 412.
Figure 4b illustrates an exemplifying state 420 of the web interface after the button 412 has been pressed, wherein user controls 421 (step 307) for allowing the authentication ser- vice provider 410 to be used in subsequent authentication of the user via the central server 101.
In fact, the user controls 421 represents one example of a preferred embodiment, in which central server 101 authentica- tion content is provided, in a step 308, as a part of and comprised in a web page 410 of the authentication web inter- face, which content is fetched from the central server 101.
Herein, “central server authentication content” means web page content the display or activation of which requires acall, such as a redirect performed by requesting the corre- sponding central server 101 URL (Uniform Resource Locator), Application text 2014-08-08 140032SE 26 from the web browser of the device 180 to the central server 101. In the case shown in figure 4b, the activation of the “Yes” button in controls 421 will result in a correspondingcall to the central server 101. In another preferred example,as illustrated in step 308-309 of figure 3, the display of central server content, which may be, for instance, invisible content such as an empty iframe, a passively displayed image or the like, or an activatable user control, etc., and whichpoints to a web server or the like provided by the centralserver 101, therefore requires a redirect to be performed, in step 309, to the central server 101. In the latter case, noexplicit user interaction is thus necessary for achieving the said call to the central server 101.
The central server 101 is then in turn arranged to place the cookie, in the above described web browser, such as on the electronic device 180, as a part of a response to this callor redirect from the authentication web interface requestingsaid central server 101 authentication content. The placingof the cookie can be performed in a way which is conventionalthe cookie is placed with a specified “call”, as such. Preferably, expiry time. Herein, the term in this context, is intended to also encompass a redirect.In the case illustrated in figure 4b, wherein the said cen-tral server 101 authentication content comprises a user con-trol 421 activatable for allowing the authentication serviceprovider 110 in question. to provide authentication. of theuser in relation to user service provider(s) 150 in communi- cation with the central server 101, the cookie is either caused to comprise information regarding whether or not suchauthentication has been allowed by the user and for the par- ticular authentication service provider in question, alterna- Application text 2014-08-08 140032SE 27 tively that the cookie is not placed if the user control 421is not activated.
In general, it is preferred that the central server 101 au-thentication content is comprised in a web page displayed tothe user in the authentication web interface 181 in a statein other words wherein an in which the user is authenticated, active user authentication session exists. Preferably, the content is displayed as a part of a web page confirming the successful authentication of the user.
It is realized that steps 303-310 correspond to steps 204- 206. In other words, the placing of the cookie by the central server 101 after* being called. from. the authentication. webinterface constitutes an example of notifying' the central server 101 of the performed authentication.In a preferred step 311, similar to step 207, a template maybe provided to the authentication service provider 110 fromthe central server 101.
Then, in a step 312 according to the second aspect of the present invention, access is provided by a particular user service provider 150, for the user and using the same webbrowser executed from or by the same electronic device 180 as304-310, in steps to the above næntioned user service web interface. The web page is requested in a step 314 by theuser, for instance by the user surfing to an online vendorsite for the purchase of one or several products.
As a result of this provision, the cookie placed in step 310 is provided, in a step 318, to the central server 101, in a way which will be described in the following.
Application text 2014-08-08 140032SE 28 In particular, it is preferred. that the provision. of the cookie to the central server 101 takes place by the userservice web interface comprising central server 101 userservice content which is fetched from the central server 101, and by the central server 101 receiving the cookie as a partof a call from the user service web interface requesting said content. Herein, the term “central server user service con- tent” is intended to have a meaning similar to that of “cen-tral server authentication content", but provided as a partof the user service web interface rather than the authentica- tion service web interface.
This is illustrated in figure 4c, showing a products checkout page 430 in the user service web interface, as displayed onthe display 181 of the device 180 after being fetched fromthe user service provider 150. The web interface comprisesuser controls 432 for entering and transmitting, to the user service provider 150, user information. The button checkout” 431 “Express constitutes central server 101 user service content, in the sense that the activation of the button 431 results in a call or redirect to the central server 101,and/or in the sense that the display of the button 431 itselfresults in a call or redirect to the central server 101. Inthe latter case, such content 431 may, depending on the re- sult of the identification. described. below in relation to step 319, be arranged. to be automatically' updated. by thecentral server 101 to display the option presented in step315, for instance by displaying the button 431 only when anavailable authentication service has been identified in step319.
In a step 313, which is similar to step 210 and which can be performed at any time prior to step 334 but preferably prior Application text 2014-08-08 140032SE 29 to step 315, the transaction. to be performed. by the user service provider 150 is identified.
In a preferred step 315, which is similar to step 217, theuser is hence presented with an option to use the centralserver 101 for authentication. This option is exemplified by the button 431. Again, if the user does not wish to be au- thenticated via the central server 101, he or she may opt out, in which case the method, in a step 316, causes the userservice provider 150 to jperfornl the authentication. in itsdefault way, which may be conventional as such and similar to step 216. In figure 4c, this may take place by the user fill-ing in the user data in fields 432 and then pressing button 461 instead of button 431.If, on the other hand, the user wishes to proceed with au-thentication via the central server 101, the button 431 ispressed, whereupon the method continues to a preferred step317, in which the existence of central server 101 user ser-vice content in the user service web page 430 causes a redi-rect or call to the central server 101. it is understood that the steps 313, From the above, 314, 315 and 317 can be performed in different order, depending on the detailed purposes of the method. For instance, the call in step 317 may be performed prior to step 315, by the presenta-tion of the web content 432 requiring a call to the centralserver 101. Step 317 may also be performed several times for the same transaction.
As a consequence of the call to the central server 101 instep 317, the central server 101 gains access to the cookieplaced in step 310 as described above, preferably as a part of the call in step 317, and the central server 101 can hence Application text 2014-08-08 140032SE identify the authentication service provider 110 as one thatis capable of authenticating the same user as is now access- ing the user service web interface 430.
According to a preferred embodiment, several cookies are placed by the central sever 101 in steps similar to step 310but in relation to authentication with different respective authentication service providers at different respective points in time. Then, in step 318, several or, preferably, all of these previously placed cookies are provided to the central server 101. This provision of available cookies pre- viously placed by the central server 101, as a consequence of a call to the central server 101, may' be conventional as such. This way, the central server gains awareness of several authentication service providers that can authenticate the user in question.
Then, in a step 319, which is similar to step 214, the au- thentication service provider 110 previously authenticating the user, or a preferred authentication service provider, for instance selected among several available authentication service providers as described above in connection to step 214, is identified based on the cookie(s) read in step 318.
It is preferred that the central server 101 selects one au-thentication service provider 110 from the several authenti- cation service providers 110, 120, 130 as identified using the said cookies.
In case there are at least several authentication service providers 110, 120, 130 for which cookies have been placed in various runs of step 310, it is preferred. that each such placed. cookie comprises information. making' it possible for the central server 101 to identify what authentication level Application text 2014-08-08 140032SE 31 is available with the authentication service provider in question. and. for the user* in question. Alternatively, the database 102 may comprise information regarding the available authentication levels of different authentication service providers and for various users, user categories, transaction types, etc.
Then, in a step 320 according to the second aspect of the method, the central server 101 is arranged to redirect the web browser of the device 180 to the authentication service provider 110 identified or selected in step 319. Hence, the redirect of the web browser to the identified authentication service provider 110 takes place in two steps: First, a redi- rect is performed to the central server 101, then further to the identified authentication service provider 110.
According to a preferred embodiment, the central server 101 user service content exemplified in figure 4c by button 431 is populated, by the central server 101, with a user control arranged to allow the user to be authenticated by any authen- tication service provider 110, 120, 130 or the identified authentication service provider 110, and in a way so that theactivation of said user control 431 results in the redirec- tion in step 320.
Figure 4d illustrates the state 440 of the user service web interface according to a preferred embodiment after the pressing of button 431. Hence, the activation of the user control 431 activates a popup dialog 444, the contents of which are fetched from the central server 101. As a responseto the request to the central server 101 for the contents ofthe popup dialog 444, the central server 101 in turn performsthe redirect of step 320 to an authentication interface pro- vided by the identified authentication service provider 110.
Application text 2014-08-08 140032SE 32 In a preferred step 321, which is similar to step 220, the identified authentication service provider 110 is further arranged to determine whether there is an active authentica-tion session with respect to the user in question. This may, for instance, take place by the identified. authentication service provider reading, in a way which is conventional assuch, a cookie provided as a part of the redirect or call fron1 the central server 101 to the authentication service provider in question in step 320, which cookie carries infor-mation regarding a possible such authentication session. Forinstance, a cookie may have been placed by the authenticationservice provider in question in the web browser of the device180 as a result of the authentication performed in steps 304-308.
Hence, in case no active authentication session is detectedfor the user in question, the evaluation in step 322 results in the negative, and. the identified. authentication. serviceto the central server 443, provider 110 replies, in a step 323, 101 with the popup dialog 444 user controls 442, in turn constituting an authentication web interface corresponding to the above discussed second interface. Using these controls 442, the user can provide credential information from. the device 180, directly to the identified authentication service provider 110, by pressing the “Submit” button 443, without the central server 101 or the user service provider 150 gain-ing access to this information.On the other hand, in case an active authentication session was detected. for the user* in question. with. the identified authentication service provider 110, which session has ade-quate properties such as fulfilling the above discussed re-selected. minimum. allowable authentication quirements for a Application text 2014-08-08 140032SE 33 level, an empty popup dialog 444 may be returned by the pro- vider llO, with the result that the popup dialog 444 is never displayed to the user. Instead, the activation of the user control 43l then results in a confirmation from the identi-fied authentication service provider llO that such an ade-indeed. exists for the quate active authentication session user in question.
According' to yet another* preferred. embodiment, the centralsystem lOl is arranged to cause the identified authenticationservice provider llO to check whether the user already has anactive authentication session with the identification authen-tication service provider llO before displaying' the popup dialog 444, in step 322 and as described above. Then, if such an active session is found to exist, the method skips direct-ly to step 325, without displaying even an empty popup dia- log. If no active authentication session is found, the useris instead presented with the second graphical user inter-face, in the form of popup 444, allowing, in a step 324, theuser to enter user credential data to the identified authen-tication service provider llO for authentication in step 325.Hence, in a step 325 which is similar to step 221, the iden-tified authentication service provider llO authenticates theuser, either based upon the detected existing authenticationsession or upon the provided credential data. In the lattercase, it is preferred that a new active authentication ses-sion is opened for the user in question by the provider llO,preferably by placing a new cookie in the web browser of thedevice 180, with information regarding the active session inquestion. user authentication information Thereafter, is provided to the user service provider l5O from the identified authentica- Application text 2014-08-08 140032SE 34 tion service provider 110, 101. preferably via the central serverThis step is similar to step 222, but may involve sever-al sub steps 326-331, as described in the following.
Thus, in a step 326 after the said authentication, a firstaccess token is provided from the identified authenticationSuch. an access token is service provider 110. arranged to allow the holder of the token to access, using the token, acertain subset of otherwise secret information from the iden-tified. authentication service provider, in particular user information (as defined above) for the user in question.
Hence, using the first access token, the holder may query theidentified authentication service provider 110 for at leastsome user information associated with the user in questionand known to the provider 110. Such querying takes place viaa specified interface provided by the authentication serviceprovider 110. Suitable examples of such access tokens com- prise OAuth2 access tokens.
The user service provider 150 may be provided directly with the first access token. However, it is preferred that it isthe central server 101 that is provided with the first access token.
In the latter case, bly, the central server 101 is then prefera-in turn, in a step 327 arranged to issue a second accesstoken, preferably of similar functionality and type as thefirst access token, 150, and send it to the user service providerpossibly indirectly by sending it to the user serviceweb interface as operating on or from the device 180. Using the second access token, the user service provider 150, again possibly indirectly via the user service web interface, canobtain access, by querying to the central server 101 using a specified interface, to at least some user information.
Application text 2014-08-08 140032SE According to a preferred embodiment, the user, in a step 328, is presented with an option whereas to allow such user infor-mation to be queried from the identified authentication ser-This is illus- vice provider 110, via the central server 101. trated in figure 4e, showing the state 450 of the user ser- vice web interface after the user' has been authenticated.
Instead. of filling' in the user information. fields 432 and then pressing the button 461,451. the user may instead press the button “Fetch data” In case the button 451 is pressed, in a step 330 the second access token is presented by theuser service provider 150 to the central server 101, and used to request specified user data. Thereafter, the central serv- er is arranged to, in a step 331, if allowed by the second access token, request user information corresponding to theinformation requested in step 330 from the identified authen-tication service provider 110.
In a step 332, the requested information, if known to theidentified authentication service provider 110 and allowed byreturned. to the central the first access token, is 101, serverwhich in turn is arranged to provide the information tothe user service provider 150.
The issuing, provision and use of the first and second accesstokens are conventional as such, and possible implementationsare for instance described in the OAuth2 documentation avail-,^, net/¿/. able from http://oauth.
Then, in a step 333, the input fields 432 for the correspond- ing user information are automatically populated by the userinterface, information obtained service web using the user from the central server 101 in step 332. Figure 4f shows the state 460 of the user service web interface after this auto Application text 2014-08-08 140032SE 36 population step 333. As is clear from figure 4f, the only relevant user information available from the identified au-thentication service provider 110 was the name of the userthe address and. credit card infor- (“John Doe”). However, mation could very well have been available as well, dependingon the type of authentication service provider used as theidentified one.
According tm) a preferred embodiment, several authenticationservice providers 110, 120, steps 319-332, 130 are contacted in parallel in so that user information from several differ- ent sources can be provided to the user service provider 150 for automatic population of the input fields 432. The corre- sponding can of course also be true for step 224, above. It is in this case preferred that the option presented in step 328 covers all used authentication service providers 110,120, 130 in only one user approval.Then, by pressing' the “Checkout” button 461, a step 334, similar to step 225, is performed, in which the transaction in question is performed by the user service provider 150using the automatically populated user information, if any; manually entered user information, if any; and the authenti-cation provided by the at least one identified authenticationservice provider 110.
Thereafter, in a step 335, the method ends.According to a preferred variant of the above described, thestep 315 is performed already before the transaction has beendefined, such as before proceeding to checkout in an online vendor web site. This way, user information can be providedto the user service provider 150, 325-332, via the mechanism in steps and used for instance to provide enhanced purchasing Application text 2014-08-08 140032SE 37 support information to the user. This can be achieved by, for instance, a button representing the option in step 315 beingdisplayed at the welcoming page of the user service web in-terface.
According to another preferred embodiment, the database 102comprises a respective record for each user registered foruse with the system 100, comprising a flag setting that theuser always, or at least for a certain set of user serviceproviders 150, wishes to accept the option presented in step217 or 315,or 220, or 317, of 216 or 316, respectively. If the flag is set, the steps 218 respectively, are always performed, insteadwhenever and as soon as at least 120, respectively,one authentication service provider 110, 130 is availa- ble for valid user authentication as described above.
Figure 4g illustrates an example of these two latter varia-tions, in the form of the welcome page 470 of a user serviceweb interface provided on the display 181 of the device 180of the user John Doe, displaying user controls 472 for navi- gating the page. In this case, the user has agreed to always allow user service providers to gain access to the user namevia the above described access tokens, as provided by the user's online community' service provider. By pressing the button 471, the user agrees that the user service provider is entitled. to request also other available user information from the central server 101 and, when proceeding to checkout,available user information will be used to auto populate anyinput fields as described above.
In fact, the button 471 will generate a redirect to the cen-tral server 101, which then receives any cookies previouslystored in the web browser of the device 180 by central server authentication content by the action of authentication ser- Application text 2014-08-08 140032SE 38 vice providers, and then, after proper verification of the settings in the database 102 and the contents of the saidcookies, redirects to the said online community service pro- vider, which, in turn, issues and returns the above described first access token. To the user, this process is completely unnoticeable and virtually instantaneous, since the user inthis exemplifying case already has an active authenticationsession with the said online community provider.
A. method. and. a system. according' to the present inventionprovides a cost-efficient way for a user service provider 150to be able to offer secure authentication of its users. Byregistering' with. the central server 101 and. specifying atleast one minimum allowable authentication level, such a userservice provider 150 gains access to a network of third partyauthentication service providers 110, 120, 130 that can pro-vide required user authentication on behalf of the user ser-vice provider. Since each user authentication service provid-er can offer to sell such an authentication for a particularprice, using good economies of scale, the central server 101can. provide complex and. advanced. user authentication. at avery cost-efficient total cost per authentication than, forinstance, a small-scale user service provider 101 is capableof reaching. It is even possible for such a small-scale userservice provider to offer a wide and highly specialized setservice total of authentication functionality without its costs for authentication increasing significantly.On the other side, users of the system 100 can authenticatethemselves to a wide range of user service providers 150 in avery efficient manner, and also have the system. 100 keeptrack of relevant user information such as credit card num-bers, without jeopardizing personal information integrity, by simply agreeing to letting one or several trusted authentica- Application text 2014-08-08 140032SE 39tion service providers, such as the user's personal online banking facility, authenticate the user on behalf of other parties and to contribute with user information known tothem.Importantly, these advantages can be achieved without remov- ing much flexibility for any of the stakeholders. The users can choose to use any registered authentication service pro- vider, and the user service providers do not have to follow authentication standards or protocols offered by the individ- ual authentication service providers.
Furthermore, users will experience better efficacy when deal- ing with user service providers, since much user information can be made available automatically, without the user having to type it in repeatedly at various sites. At the same time, user service providers can offer* a more tailor made user experience with extra knowledge of the visiting user at an early point in the transaction process. These advantages are even more powerful in case several authentication service providers are used in parallel to together provide a nwre complete set of available user information.
According to a further preferred embodiment, the selected or identified authentication service provider described above isa mobile telephony operator to which the particular user is a subscriber. In this case, the user authentication provided by such authentication service provider comprises a Hwbile au- thentication. step in which. the user communicates with the selected authentication service provider using a mobile de-vice comprising' a SIM card. associated. with. the particular user's subscription with the said authentication service provider. For instance, the credential data provided by the user to the authentication service provider may then comprise Application text 2014-08-08 140032SE an alphanumeric code sent to the telephone number (MSISDN) of the mobile phone as an SMS, read by the user and input into an input box comprised in the graphical interface. The above described first graphical interface may be provided on the display of the said mobile telephone, such as by a web brows- er running on the nwbile telephone. Such method provides a second authentication factor (something the user has, namely the mobile telephone).
It is particularly preferred that the mobile authenticationstep specifically comprises the verification of a certificate which has previously been provided on the said SIM card. This provides very good security.
In case the first graphical interface is provided by a mobile telephone, it is preferred that the selection or identifica- tion, by the central server, of which authentication service provider to use for user authentication comprises to firstinvestigate whether the user's mobile operator is registered with the central server 101 for user authentication, and available for authenticating the particular user in question at the current moment. This investigation is preferably per- formed by consulting data stored in the database 102. If this is not the case, the availability' of other authentication service providers are investigated.
In another preferred. embodiment, the said. user credential data comprises information identifyimg a wireless or wired local internet access network, such as a WiFi or LAN network, to which the electronic device is locally connected, prefera-bly such a network which is associated with a certain limitedgeographical coverage area so that a device being registeredon the network in question is also located in the said cover- age area unless the network registration is fraudulently Application text 2014-08-08 140032SE 4l achieved. This can be achieved in different ways. In a first example, the said. network itself is identified. using said user credential data, read off automatically by the connecteddevice and sent to the central server IOI. In a second exam-ple, a particular SIM card used for providing wireless inter-net connectivity to the electronic device, such as a SIM cardin the device itself or a SIM card in a mobile phone used tocreate a WiFi netwotk to which the device is locally connect-ed, is identified using the credential information and pro-the central server lOl vided to the central server IOI. Then, is arranged. to compare the provided. network- or SIM cardidentifying information tm) a predetermined, assumed network or SIM card to which the user should be connected if authen- tic.Above, a number of preferred embodiments have been described.However, it is apparent to the skilled person that many modi- fications can be made to the described embodiments withoutdeparting from the basic idea of the invention.
For instance, the above described first and second aspects ofthe present invention represent two different ways of achiev-ing similar goals. These two aspects have considerable over-lap, many of which have been pointed out in the above de- scription. However, it is realized that all features from one of these can be freely applied to the other, and vice versa,when so is practically applicable.
Moreover, one or several of the authentication service pro-viders may be comprised by respective external central serv-ers similar to the central server IOI. Such external central servers will then, typically, be connected to a respective plurality' of other authentication service providers. Then, such external central servers are treated as ordinary authen- Application text 2014-08-08 140032SE 42 tication service providers. So, for instance in the above described auction procedure, an external central server mayprovide a sell price for authentication of a user in a cer-tain current situation and under certain conditions, usingits own network of available authentication service provid-ers. Such a setup may for instance be advantageous to facili-tate geographic coverage of the system 100 in several coun-tries or regions.
Hence, the invention is not to be considered limited to thedescribed embodiments, but may be varied within the scope of the enclosed claims.
Application text 2014-08-08 140032SE

权利要求:
Claims (18)
[1] 1. l. i s e d a) Application text 2014-08-08 Method for authenticating a user, c h a r a c t e r - i n that the method comprises the steps of providing a central server (lOl), in communication with at least two authentication service (llO,l20,l30)(l50); providers and at least one user service provider associating each authentication service provider with atleast one respective available level of authentication; receiving, at the central server, a request from the user service provider* to authenticate a [particular 'user ac- cessing the user service provider via an electronic de- vice (l70,l80); identifying a minimum level of authentication to use forthe said request;server to selected causing' the central one (llO) identify' aof said authentication service providers which isassociated with at least one allowable level of authenti-cation which is at least as high as the said minimum lev-el of authentication, and which selected authenticationservice provider is capable of authenticating said par-ticular user at said allowable level of authentication; either providing user credential data associated withsaid particular user directly to the selected authentica-tion service provider, without said user credential databeing supplied to the central server, or determining thatthe selected authentication service provider has an ac-tive authentication session for the particular user; andcausing the selected authentication service provider toauthenticate the particular user and to provide an au- thentication response. 140032SE 44
[2] 2. Method according to claim l, c h a r a c t e r i s e d i n that the particular user accesses the user service pro- vider (150) remotely' via a first graphical user interface provided. on a display (l7l,l8l) of the electronic device (l70,l80), and in that the first graphical user interface is arranged to in turn activate a second user interface which isarranged to allow the particular user to communicate directly with the selected authentication service provider (110), thereby to supply said user credential data.
[3] 3. Method c h a r a c t e r i s e d according to claim 2, i n that the second user interface is a graphical user in- terface provided to the user on the electronic device(l70,l80).
[4] 4. Method according to claim 3, c h a r a c t e r i s e d i n that the second graphical user interface is provided asan integrated graphical sub interface of the first graphical user interface, such. as within. a specific iframe provided within a web page comprised in the first graphical user in- terface.
[5] 5. Method claim 4, c h a r a c t e r i s e d (l0l) according toi n that the central server provides a template for interface to the selected (110) , the said second graphical user authentication service provider and in that the se- lected. authentication service provider* provides the actual second graphical user interface to the user service provider (150), for provision to the particular user as a part of the first graphical user interface, based upon said template.
[6] 6. Method according to any one of the preceding claims, c h a r a c t e r i s e d i n that the authentication service providers (ll0,l20,l30) are caused to be remotely configura-
[7] 7. Application text 2014-08-08 140032SE ble by individual users to provide information regarding thecapability of authentication of the users in question to thecentral server (101).7. Method c h a r a c t e r i s e d (110,l20,l30) according to claim 6, i n that the authentication service providers notify the central server (101) when a user has been authen- ticated by the authentication service provider in question.
[8] 8. Method according to any one of the preceding claims, c h a r a c t e r i s e d i n that the steps f) and.«g) are only performed if the identification in step e) succeeds in identifying at least one capable authentication service pro- vider (110), and, in case the identification in step e) does not succeed, the user service provider (150) is instead caused to authenticate the particular user without involving any of said authentication service providers (110,120,130).
[9] 9. Method according to claim 8, c h a r a c t e r i s e d i n that the identification in step e) is first performed, and in that, only if said identification succeeds, the par- ticular user is presented with an option, via a graphical user interface, to authenticate using said authenticating service providers.
[10] 10. Method according to any one of the preceding claims, c h a r a c t e r i s e d i n that the respective at least one level of authentication used in step e) for each authen- tication service provider (110,120,130) is caused to depend on at least one of the collection of parameters consisting of type of the electronic device (170,180); type and/or provider of a graphical user interface via which the user accesses the user service provider (150); the access of the authentication service provider (110) in question to information identifying Application text 2014-08-08 140032SE 46 the particular user; geographical location of the electronic device; and/or the existence of an active authentication session with the authentication service provider in question. c h a r a c t e r i s e d (110)
[11] 11. Method according to claim 10,i n that the selected authentication service provideris a mobile telephony operator to which the particular useris a subscriber, and in that step g) comprises a mobile au- thentication. step in which. the user communicates with theselected authentication service provider using a mobile de-vice (170,180) comprising' a SIM card associated. with the particular user's subscription with the selected authentica- tion service provider.
[12] 12. Method according to any one of the preceding claims, c h a r a c t e r i s e d i n that 'the user~ credential comprises information identifying a wireless or Wired local internet access network to which. the electronic device is connected, either in the sense that the network itself is identified. using said information. or in the sense that a particular SIM card used for providing wireless internet connectivity' to the electronic device is identified. using said information.
[13] 13. Method according to any one of the preceding claims,comprises provid- (150), c h a r a c t e r i s e d i n that step g) ing access, to the user service provider to user in- formation previously stored and associated with the particu- lar user with the selected authentication service provider (110).
[14] 14. Method according to claim. 13, c h a r a c t e r i s e d i n that said user information is used to automatically populate corresponding user input fields in a graphical user Application text 2014-08-08 140032SE 47 interface provided to the particular user by the user service provider (150) and via the electronic device (170,180).
[15] 15. Method. according- to clain1 13 or 14, c h a r a c t e r - i.s e d i n that said access to user information is only provided after an explicit approval from the particular user.
[16] 16. Method according to any one of the preceding claims, i n that both the selected authen- (110) c h a r a c t e r i s e d tication service provider (150) and the user service providerare accessed by the particular user via a web browser provided on the electronic device (170,180).
[17] 17. Method according to any one of the preceding claims,c h a r a c t e r i s e d i n that step e) comprises thecentral server (101) identifying, for several authentication service providers (110,120,130), a respective offered sell price for jperforming' user* authentication. at the respective allowable level of authentication, and the central server further identifying an authentication service provider (110) offering' a lowest sell price at the respective allowable level and using this as the selected authentication service provider.
[18] 18. System (100) for authenticating a user, (101) , wherein the sys-in communication with (110,l20,l30) tem comprises a central serverat least two authentication service providers and at least one user service provider (150), wherein the system further comprises a database (102) comprising respec- tive associations between each authentication service provid-er and at least one respective available level of authentica-tion, c h a r a c t e r i s e d i n that the service provider via an electronic device to iden- Application text 2014-08-08 140032SE 48 tify a ndnimum level of authentication to use for the said request and to identify a selected one (llO) of said authen-tication service providers which is associated with at leastone allowable level of authentication which is at least ashigh as the said minimum level of authentication, and whichselected. authentication. service provider* is capable of au-thenticating said particular user at said allowable level ofauthentication, in that the system is arranged to thereafter either provide user credential data associated with saidparticular user directly from the user service provider tothe selected. authentication service provider, without saiduser credential data being supplied to the central server, orto determine that the selected authentication service provid-er has an active authentication session for the particularuser, and in that the system is arranged to cause the select-ed authentication service provider to authenticate the par-ticular user and to provide an authentication response to the user service provider. Application text 2014-08-08 140032SE

类似技术:

---

公开号 | 公开日 | 专利标题

---

EP3178212B1|2020-04-29|Method and system for authenticating a user

---

US10708257B2|2020-07-07|Systems and methods for using imaging to authenticate online users

---

EP2873192B1|2018-01-31|Methods and systems for using derived credentials to authenticate a device across multiple platforms

---

US11222312B2|2022-01-11|Method and system for a secure registration

---

JP4856755B2|2012-01-18|Customizable sign-on service

---

WO2016127797A1|2016-08-18|User information acquisition method, apparatus, and server

---

JP2013211020A|2013-10-10|Method and apparatus for preventing phishing attacks

---

EP1807966A1|2007-07-18|Authentication method

---

US10212154B2|2019-02-19|Method and system for authenticating a user

---

KR102055897B1|2019-12-16|Authentication Method and System for Service Connection of Internet Site using Phone Number

---

JP2014215620A|2014-11-17|Authentication system and authentication method

---

JPWO2010050406A1|2012-03-29|Service provision system

---

CA2844888A1|2014-09-08|System and method of extending a host website

---

WO2017048177A1|2017-03-23|Method and system for authenticating a user

---

JP6643374B2|2020-02-12|Service management system and service management method

---

US20210166226A1|2021-06-03|Deep link authentication

---

WO2010140955A1|2010-12-09|Selection of transaction functions based on user identity

同族专利:

---

公开号 | 公开日

---

EP3178195B1|2019-05-01|

---

CN106716918A|2017-05-24|

---

US10212154B2|2019-02-19|

---

US20170230351A1|2017-08-10|

---

SE539192C2|2017-05-09|

---

EP3178195A4|2017-07-19|

---

WO2016022057A1|2016-02-11|

---

EP3178195A1|2017-06-14|

---

CN106716918B|2020-05-22|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

US10970370B2|2017-07-21|2021-04-06|Zealid Ab|Method and system for creating a strong authentication for a user using a portable electronic device|US8121874B1|1999-05-27|2012-02-21|Accenture Global Services Limited|Phase delivery of components of a system required for implementation technology|

---

US7137006B1|1999-09-24|2006-11-14|Citicorp Development Center, Inc.|Method and system for single sign-on user access to multiple web servers|

---

US20020026328A1|2000-05-05|2002-02-28|Westerkamp Thomas M.|Method and system for management of patient accounts|

---

US20030028782A1|2000-11-22|2003-02-06|Grundfest Joseph A.|System and method for facilitating initiation and disposition of proceedings online within an access controlled environment|

---

US6744874B2|2001-05-15|2004-06-01|Hengning Wu|Method of universal communication and devices thereof|

---

US7610390B2|2001-12-04|2009-10-27|Sun Microsystems, Inc.|Distributed network identity|

---

ITMO20020006A1|2002-01-10|2003-07-10|Dream Team Srl|METHOD AND SYSTEM FOR USER IDENTIFICATION AND AUTHENTICATION OF DIGITAL DOCUMENTS ON TELEMATIC NETWORKS|

---

US20040030603A1|2002-08-09|2004-02-12|Grundfest Joseph A.|System and method for facilitating management of a matter online within an access controlled environment|

---

US8413890B1|2002-11-25|2013-04-09|Diebold Self-Service Systems Division Of Diebold, Incorporated|Automated banking machine that operates responsive to data read from data bearing records|

---

US8403205B1|2002-11-25|2013-03-26|Diebold Self-Service Systems Division Of Diebold, Incorporated|Automated banking machine that operates responsive to data read from data bearing records|

---

EP1618520A4|2003-04-01|2007-10-31|Yong-Gyun Shin|Electronic commerce method using combined publicity according to goods/service type and computer readable recording media storing program for executing the same|

---

FR2856865A1|2003-06-25|2004-12-31|France Telecom|ASSIGNMENT OF A RESOURCE ACCESS AUTHORIZATION|

---

US20050138065A1|2003-12-18|2005-06-23|Xerox Corporation|System and method for providing document services|

---

JP4455170B2|2004-05-31|2010-04-21|株式会社東芝|Network home appliance control system|

---

US20060010203A1|2004-06-15|2006-01-12|Nokia Corporation|Personal server and network|

---

US20060010251A1|2004-06-16|2006-01-12|Nokia Corporation|Global community naming authority|

---

US7578436B1|2004-11-08|2009-08-25|Pisafe, Inc.|Method and apparatus for providing secure document distribution|

---

US20060200814A1|2005-03-02|2006-09-07|Nokia Corporation|Software distribution with activation control|

---

US7533802B1|2005-08-08|2009-05-19|Diebold Self-Service Systems Division Of Diebold, Incorporated|Automated banking machine system and method|

---

US7716467B1|2005-12-02|2010-05-11|Sprint Communications Company L.P.|Encryption gateway service|

---

US20070254630A1|2006-04-24|2007-11-01|Nokia Corporation|Methods, devices and modules for secure remote access to home networks|

---

US8041942B2|2006-09-05|2011-10-18|Panasonic Corporation|Robust peer-to-peer networks and methods of use thereof|

---

WO2008028287A1|2006-09-08|2008-03-13|Memory Experts International Inc.|Automated security privilege setting for remote system users|

---

WO2008072211A2|2006-12-14|2008-06-19|Iwics Inc|Distributed network management hierarchy in a multi-station communication network|

---

US8045956B2|2007-01-05|2011-10-25|Macronix International Co., Ltd.|System and method of managing contactless payment transactions using a mobile communication device as a stored value device|

---

US7949359B2|2007-04-05|2011-05-24|Sejo Pan|Methods and system for dynamically and anonymously linking wireless communications unit users|

---

US8204536B2|2007-12-13|2012-06-19|Microsoft Corporation|Automatic provisioning based on communication network connectivity and characteristics|

---

US20090288138A1|2008-05-19|2009-11-19|Dimitris Kalofonos|Methods, systems, and apparatus for peer-to peer authentication|

---

WO2010010430A2|2008-07-25|2010-01-28|Lee Kok-Wah|Methods and systems to create big memorizable secrets and their applications in information engineering|

---

JP5153591B2|2008-11-26|2013-02-27|株式会社日立製作所|Authentication mediation server, program, authentication system, and selection method|

---

US20100138900A1|2008-12-02|2010-06-03|General Instrument Corporation|Remote access of protected internet protocol -based content over an ip multimedia subsystem -based network|

---

US8782755B2|2009-03-20|2014-07-15|Citrix Systems, Inc.|Systems and methods for selecting an authentication virtual server from a plurality of virtual servers|

---

EP3832975A1|2009-05-29|2021-06-09|Alcatel Lucent|System and method for accessing private digital content|

---

US8644795B2|2009-11-25|2014-02-04|Centurylink Intellectual Property Llc|System and method for managing individual use of a mobile telecommunications account|

---

EP2381385B1|2010-04-26|2013-08-28|Research In Motion Limited|Method and system for third party client authentication|

---

DE102010033232A1|2010-08-03|2012-02-09|Siemens Aktiengesellschaft|Method and device for providing a one-time password|

---

US20120232969A1|2010-12-31|2012-09-13|Nest Labs, Inc.|Systems and methods for updating climate control algorithms|

---

US9690941B2|2011-05-17|2017-06-27|Microsoft Technology Licensing, Llc|Policy bound key creation and re-wrap service|

---

WO2013052678A2|2011-10-04|2013-04-11|Advanergy, Inc.|Battery management system and method|

---

CN103067338B|2011-10-20|2017-04-19|上海贝尔股份有限公司|Third party application centralized safety management method and system and corresponding communication system|

---

US9559859B2|2012-01-05|2017-01-31|Dell Products L.P.|Home hub|

---

FI125972B|2012-01-09|2016-05-13|Tosibox Oy|Equipment arrangement and method for creating a data transmission network for remote property management|

---

EP2817917B1|2012-02-20|2018-04-11|KL Data Security Pty Ltd|Cryptographic method and system|

---

US20120266209A1|2012-06-11|2012-10-18|David Jeffrey Gooding|Method of Secure Electric Power Grid Operations Using Common Cyber Security Services|

---

US9361436B2|2012-09-05|2016-06-07|Bank Of America Corporation|Multiple profile authentication|

---

US9444855B2|2012-11-19|2016-09-13|At&T Intellectual Property I, L.P.|Initiating a central server-directed communication session from an in-progress half call model communication session|

---

EP2932680A1|2012-12-12|2015-10-21|Interdigital Patent Holdings, Inc.|Independent identity management systems|

---

US9160743B2|2013-02-12|2015-10-13|Qualcomm Incorporated|Biometrics based electronic device authentication and authorization|

---

IN2013CH01644A|2013-05-11|2015-08-07|Telibrahma Convergent Comm Pvt Ltd|

---

US9246945B2|2013-05-29|2016-01-26|International Business Machines Corporation|Techniques for reconciling permission usage with security policy for policy optimization and monitoring continuous compliance|

---

CN103269349A|2013-06-13|2013-08-28|百度在线网络技术（北京）有限公司|Social log-in method, system and device|

---

US9413762B2|2013-06-17|2016-08-09|Cable Television Laboratories, Inc.|Asynchronous user permission model for applications|

---

US9276933B2|2013-12-20|2016-03-01|Sharp Laboratories Of America, Inc.|Security token caching in centralized authentication systems|US10802888B2|2014-09-19|2020-10-13|Nec Corporation|Information processing device and cooperative distributed storage system|

---

SE1551176A1|2015-09-14|2017-03-15|Identitrade Ab|Method and system for authenticating a user|

---

CN106454821A|2016-02-01|2017-02-22|深圳市途鸽信息有限公司|VSIMauthentication method and apparatus|

法律状态:

优先权:

---

申请号 | 申请日 | 专利标题

---

SE1450927A|SE539192C2|2014-08-08|2014-08-08|Method and a system for authenticating a user|SE1450927A| SE539192C2|2014-08-08|2014-08-08|Method and a system for authenticating a user|

---

US15/502,281| US10212154B2|2014-08-08|2015-07-31|Method and system for authenticating a user|

---

CN201580050752.1A| CN106716918B|2014-08-08|2015-07-31|User authentication method and system|

---

PCT/SE2015/050840| WO2016022057A1|2014-08-08|2015-07-31|Method and system for authenticating a user|

---

EP15830581.3A| EP3178195B1|2014-08-08|2015-07-31|Method and system for authenticating a user|