WO2018198036A1

WO2018198036A1 - Authentication system and identity management without password by single-use qr code and related method

Info

Publication number: WO2018198036A1
Application number: PCT/IB2018/052860
Authority: WO
Inventors: Mauro LEONETTI; Francesco MELI; Massimiliano BOSCO; Davide Nigro; Andrea Re
Original assignee: Just Log Me S.R.L.
Priority date: 2017-04-24
Filing date: 2018-04-24
Publication date: 2018-11-01
Also published as: IT201700044688A1

Abstract

Methods and systems for secure, password less access to online services, events with subscription or building gates are described. To access, the user takes a picture of a unique one-time, encrypted and non-falsifiable QR code through a portable device (smartphone), displayed on the screen of a desktop computer or of an intercom or, alternatively, a unique and non-falsifiable QR code printed on paper. An application (app) on the smartphone reads the QR code, communicates to the user the list of personal data required for subscription and, following the consent, sends a One Time Password (OTP) and the identifier of the device to an identity provider which verifies them, completes the subscription and issues an access token. The identity provider prompts, via the app, for the missing data and the modification of the obsolete ones, controls and tracks the transfer of the single datum to the different services. If the smartphone does not have an app, the user takes a picture of the QR code and automatically installs the app, associates the device with its identity, enters the basic data in the identity provider, signs up and logs in. If the smartphone is offline, the user can authenticate in two steps, typing an OTP generated by the app and a code extracted from an encoded QR code generated by the identity provider.

Description

AUTHENTICATION SYSTEM AND IDENTITY MANAGEMENT WITHOUT PASSWORD BY SINGLE-USE QR CODE AND RELATED METHOD

DESCRIPTION

Field of Invention

The present invention relates to a system and a method of authentication and identity management without password, by means of a single-use QR code.

In particular, the invention finds application in the technical sector of access control to networked computer systems, of physical access control (buildings, places with security levels, events requiring registration, hotels, means of transport, etc.) and in managing the entire life cycle of a person's digital iden^¬ tities (from the first subscription to the right to be forgotten) and the scope thereof consists of methods and tools for the fa^¬ cilitated creation and management of digital identities, unified authentication on diversified applications (single sign on) and strong authentication without password (password less strong au^¬ thentication) , making use of the capabilities of personal mobile devices (typically smartphones) .

Background and prior art

As is known, the authentication of users in a software ap^¬ plication is based on at least one of the following three factors: a piece of information which is known only by the user (password or "secret") and which distinguishes him from other individuals, an object owned only by the user (smart card, token, etc.), or an inherent features of the person such as his biometric data (among which fingerprint, calligraphy, face or voice recognition, and others) .

The most popular and widespread authentication system, based on login and password, forces the user to subscribe to a service - for example, accessible through a Web portal of the service provider - by choosing a username and password (not too complex to be remembered but sufficiently articulated to guarantee its safety) ; typically, in case of need to subscribe to different services on a plurality of websites, it is necessary to repeat the subscription process for each website. The repeated input of personal data on an access interface has the following drawbacks :

- high cost of variations, as the user must make the same change to every service he/she previously subscribed to;

- high rate of abandonment, as the completion of the sub^¬ scription form from zero discourages the user;

- greater risk of identity theft, stealing of personal data and credentials, due to the increase of attack opportunities and to the inherent weakness of an authentication system the overall security of which is equal to that of the less protected site being subscribed by the user.

To avoid the problem of repeated data input, it has been proposed to store personal data of the user and its credentials on smartphone, so as to automate the submission from the smartphone to the website of the service provider when subscribing or accessing. Typically, the authentication process starts when the smartphone frames and acquires through the camera a QR code (see for example US20130167208 and US20160191506) containing the address of the specific resource on the Internet (URL, uniform resource locator) of the relevant service: with a suitable appli^¬ cation (app) , a process which is transparent to the user accesses and / or browses the address obtained from the QR code and auto^¬ matically fills in the subscription form or the login form with the data stored in the phone. This last solution allows to save time during subscription and login, however the personal data are duplicated at each new subscription and for their update it should be necessary to intervene on every single copy provided to the different service providers to which the user previously sub^¬ scribed; furthermore, the security of personal data is entrusted to the smartphone, wherein the data are stored: in addition to security problems related to the smartphone network, there are also problems related to the physical loss of the device with possible access by third parties.

In the context of this application, for sake of simplicity we will refer to a smartphone or a personal portable device, but it is understood that these - for the purposes of the invention - are equivalent to any personal portable device having computing capacity, a camera for acquiring images and a connection capacity to a data transmission network, for example a tablet, an e-reader, a PDA and so on.

The security problem is partly overcome in systems (see for example US8935777) envisaging to store the complete data and user credentials in a centralized server (identity provider) , whose reliability is recognized by a series of operators, including the same Web service providers. In this case, the smartphone only transmits the user's credentials for authentication to the cen^¬ tralized server (thereby avoiding storing the entire set of per^¬ sonal data) . However, even in this case it is assumed that the smartphone is a secure device as such ("trusted device") and that the set of operating system and application software on board of the phone can protect user credentials.

Since authentication with username and password has inherent insurmountable weaknesses, among which the ease of capturing key^¬ strokes (keystroke logging) or exposure to theft by forging the login masks (phishing) on the portal of the service provider, systems have been proposed - always based on smartphones, believed to be trusted devices - where the password is replaced by a cryp^¬ tographic key (password less authentication) . See for example US 9178890 and US 8627438.

In this last class of systems, it is provided to acquire a cryptographic key embedded in an alphanumeric sequence of a QR code framed with the smartphone camera, which is suitably inter^¬ preted by an application installed on the smartphone (customized according to the credentials of the user) and relayed to the centralized server of the identity provider. The possession of the key, generated by the server and sent to the smartphone, constitutes proof of the user identity.

However, these known systems have two drawbacks: the first is the assumption that the smartphone is secure, the second is that authentication is blocked when the smartphone is offline. The QR code itself is at risk of counterfeiting because it can be generated by anyone and, not being intelligible for the human eye, it is not possible to verify its origin and integrity in a simple way. In theory, the problem could be solved by inserting a digital signature in the QR code (see also US20120308003) : to allow local verification with the software installed on the smartphone, in the proposed solutions it is embedded in the QR code (i) a X.509 certificate or, alternatively, (ii) a unique identification code (ID) of the author that the client must present to a remote ver^¬ ification service together with the contents of the QR code. In the first case, at least 512 bytes are used (i.e. the minimum recommended length of an RSA key to be considered secure, equal to 2048 bits, plus the space occupied by the hash encoded with the private key, which in RSA has the same key length, 256 byte) : the QR code is then rather complex and, to be displayed, needs a larger surface or, with the same surface, requires a camera having higher resolution to be properly deciphered by the portable de^¬ vice, thus limiting the flexibility and the spread of the QR code, especially if printed on physical supports such as coloured paper, if reduced in size due to space reasons or displayed on low res^¬ olution displays or having a reduced size as on domotic or wearable systems. In the second considered case, the smartphone reading the QR code cannot verify the signature if it does not have access to the complete trust chain of the certificates; not having cer^¬ tificates on board, the device must access an external server which is necessarily entrusted; this transfers the problem of verification to a different object (the server response) which in turn should be signed as it is exposed in turn at the same risk of counterfeiting: in this case the digital signature of the QR code loses its meaning because the local verification becomes redundant and does not increase the overall security of the sys^¬ tem .

Moreover, in the systems of the prior art - in particular see also what is disclosed in US 8935777 and US 9288198 - the QR code is transmitted to the Web server and appears on an HTML page which is part of the site to be protected: this entails both inconveniences in terms of security, and the difficulties of im^¬ plementation when it is needed to access multiple websites with the same credentials (Single Sign On) , since each website would have its own login page with an inevitable multiplication of resources and lack of coordination; in particular, the multiplication of the login pages implies an unnecessary increase in terms of costs, since any maintenance, evolution or adaptation to the standards forces to modify at least one object for each website and increases the attack surface of the system, the overall secu^¬ rity of which decreases a lot as it is equal to that of the weakest link in the chain which, in this case, is the Web site.

A further disadvantage of the multiple login pages, located in the individual partner websites, is amplified by the introduc^¬ tion of the QR code, as the diversification of the graphics and of the layout of the login pages favours a known type of attack which involves the hijacking of a QR code login session (hence the name of QRLJacking) : it consists of imitating the login page with the QR code, cloning it in the same way as the traditional login pages and of convincing the user of the smartphone to view the counterfeit page and log in on it . Similarly to what happens with the counterfeiting of traditional login pages, based on user ID and password, conceived to capture the credentials of the vic^¬ tim (phishing) , the only remedy remains that of educating the user to possible frauds, this being often difficult to achieve.

Another limitation of the aforementioned systems of prior art is the fact that the authentication certificate is issued by the identity provider and provided directly to the Web server of the protected resource. These modes of operation are transparent to the user, but the currently used logins with QR code are exposed to the aforementioned security problems and imply a direct dia^¬ logue between the Web server of the protected resource and the identity provider, which complicates the infrastructure and re^¬ duces its commercial attractiveness.

Other systems involving similar technologies are disclosed in the following publications US2013/185210; US 2016/337351; Sya- mantak Mukhopadhyay et al . "OR-SSO: Towards a QR-Code based Single Sign-On System", INTERNATIONAL JOURNAL FOR DIGITAL SOCIETY, vol. 2, no. 4, pages 588-594; Christian Beck: "Einbindung des Smartphones m erne Single Sign-On (SSO) Architektur mittels QR- Codes", Las Palmas de Gran Canaria, Spain; Watanabe et al. "Fed^¬ erated Authentication Mechanism using Cellular Phone - Collaboration with OpenID", INFORMATION TECHNOLOGY: NEW GENERATIONS, 2009, ITNG '09, SIXTH INTERNATIONAL CONFERENCE ON, IEEE, PISCATAWAY, NJ, USA, pages 435-442; L. Roalter et al. "The Smartphone as Mobile Authorization Proxy", 14th International Conference on Com^¬ puter Aided Systems Theory (EUROCAST 2013), pages 306-307, Las Palmas de Gran Canaria, Spain.

Summary of the invention

The object of the present invention is therefore to provide a system and a method of authentication and credential management that overcomes the aforementioned problems, i.e. a simple system to be used, therefore without a password, which provides a good level of security and which can also operate offline. In the context of the present disclosure, offline operability means the capability of the authentication system to operate even when the mobile device is not connected to the network (offline smartphone) and its capability to perform authentication from the QR codes on different supports from Web pages, such as advertising posters.

This object is achieved by means of a system and a method as disclosed in their essential features in the appended claims.

In particular, it is provided a method and a system for the rapid creation and management of a digital identity of a user and its password less strong authentication by reading and decoding a unique and single-use QR code by a software application (app) resident on a personal portable device (smartphone, PDA, tablet, ... ) and validating some authentication factors through a centralized server (identity provider and backend services). The centralized server generates a single-use QR code (online QR code) containing a unique identifier (nonce) and a hash, calculated from the whole contents of the QR code and combined with a secret key, stored in a secure archive of the server. The server provides the QR code typically on a Web page of a contracted service provider and, at each new session (browser window or tab) , it provides a different QR code. The user frames the QR code with the camera of the portable device, which is acquired by the app on the portable device. The framed QR code is immediately "burned", i.e. it changes its status from "available" to "in use". A portable device, different from the first one, which for any reason frames the QR code already in use, cannot perform authentication.

The app sends a message with the content of the QR code, a single-use password (One Time Password, OTP) and unique identifi^¬ ers of the portable device and of the user registered and set in the app to the "backend" system of the server. The message is encrypted by the app with a standard symmetric key algorithm and is accompanied by a hash for the authentication of the message (HMAC) . The single-use OTP password is not entered manually but is automatically calculated by the app as a function of an alpha^¬ numeric sequence (OTP Secret) generated preliminarily (only once) by the centralized server and delivered on the client device dur^¬ ing the first (and only) subscription.

The backend server checks the HMAC, validates the OTP, the syntax of the contents of the QR code and checks the correspondence of the identifier of the portable device with those previously registered and associated with the digital identity of the user. If the outcome is positive, the process continues.

The backend server extracts from the acquired QR code a unique identifier of the browser session (nonce) and the hash; the backend server then verifies the nonce and recalculates the hash - using the same method used by the server when generating the Web page framed by the user device - to be compared with the hash included in the QR code acquired by the device of the user: if the values coincide, the process goes on.

The backend server recovers the service based on the nonce, it identifies and retrieves from the service provider the list of personal data of the user required for access, then checks if these data are already present in the identity provider and if the user has previously given that specific service provider con^¬ sent to their processing. If data are missing, the backend server informs the app on the device, which prompts the user to enter the missing data and any missing consent.

The new data, the modified data and the relative consent are saved in the identity provider and remain valid until the next modification or until the consent is revoked. Through the app the user can decide, if desired, to reconfirm the consent from time to time, even if it has already been given previously. Once the consent has been correctly acquired, the service provider auto^¬ matically redirects the Web browser of the user to the protected page to which access was requested, equipped with an access token generated and signed by the identity provider.

A particular aspect of the invention relates to the possi^¬ bility of operating also in an alternative way with respect to the previous one, used to perform strong authentication even when the personal portable device is disconnected from the network (offline or backup authentication) .

Another aspect concerns a user quick subscription mode, by means of a second family of specially designed QR codes (offline QR code or printable QR code) , which cannot be forged, reproduc^¬ ible in an unlimited number of copies on physical media the content of which has a dual function: the first is to provide a link to download the app from a generic portable device that does not have it; the second feature is to support the automatic subscription to the online service through the app.

The app reads from the printed QR code, for example on the paper support of an advertising billboard or a publication, a unique code associated with a provider of an online service, such as an e-commerce. The same unique code can be associated with additional codes to differentiate QR codes placed on different publications or on supports placed in different geographical lo^¬ cations, so as to allow, on the server side, the measurement of the effectiveness of an advertising campaign according to the single channel communication or to placement of billboards in strategic points of a city, on the occasion of events or other characteristics configurable by the manager.

In each QR code generated by the server, a hash is inserted and calculated starting from the content of the QR code itself and from a secret key, stored in a protected server storage. Without the secret key it is not possible to calculate the hash, which makes the origin of the QR code certain. In analogy to what happens for digital signatures, every time an app acquires a QR code, the hash is recalculated from the server and compared with that included in the QR code. If the reconstructed hash does not match the original one entered in the QR code, the server deduces that the latter is potentially forged and triggers an alarm. On the other hand, if the QR code passes the checks, a Web page of the online service is displayed on the portable personal device, pre-filled with all the data required for subscription, which are taken from the identity provider.

According to other aspects, it is envisaged that the QR code may be replaced by different physical or virtual supports, among which are included, without limitations, audio tracks, static or animated images, video sequences or virtual objects for augmented reality devices.

Other embodiments may include additional authentication fac^¬ tors, including, without limitations, biometric sensors, "ges^¬ tures", voice recognition or combinations thereof.

Other possible applications of the invention provide for the use of the method and of the authentication system to access services other than those provided through a Web portal, among which are included, without limitations, desktop software, compu^¬ ting services, storage services, infrastructure or platform ser^¬ vices (including cloud computing) shared over a public or private network, mobile applications (apps), access control systems for buildings, doors, gates and access turnstiles, applications to unlock doors and for the consent to start up motor vehicles and so on .

Brief Description of the Drawings

However, further characteristics and advantages of the sys^¬ tem and method according to the invention will be more apparent from the following detailed description of a preferred embodiment of the same, given by way of non-limiting example and illustrated in the accompanying drawings, wherein: FIG . 1 is a block diagram of the process and of the system with which a user authenticates and accesses a Web service framing a QR code by means of a personal portable device, according to a possible embodiment of the present invention;

FIG . 2 is a schematic view of an online, unique and single- use (one-time) QR code, as represented on a Web page of a service portal or on a display of a control system of building access according to a possible embodiment of the present invention;

FIG . 3 is a block diagram of the authentication process from a personal portable device by means of online QR codes according to a possible embodiment of the present invention;

FIGS . 4A— D are sequential views of a block diagram repre^¬ senting an authentication process with the portable device being offline (offline authentication or backup authentication) by means of online QR codes according to a possible embodiment of the present invention;

FIG . 5 is a representation of the unique, multi-purpose and printable QR code (offline QR code) , according to a possible em^¬ bodiment of the present invention;

FIG . 6 is a block diagram of the authentication process by means of an offline QR code according to a possible embodiment of the present invention;

FIG . 7 is a block diagram of the subscription process of a personal portable device and of a new private user by means of online and offline QR codes according to a possible embodiment of the present invention; and

FIG . 8 is a block diagram of the subscription process of a personal portable device and of a new corporate user by means of online and offline QR codes according to a possible embodiment of the present invention.

Detailed description of some preferred embodiments of the inven^¬ tion

With reference to the attached figures, and for the purpose of exemplifying and not limiting it, it is illustrated a preferred embodiment of the invention.

FIG . 1 shows a system in which a user 100 , equipped with a personal portable device or primary client 101 (for example a smartphone or tablet equipped with a camera and an operating sys^¬ tem like Android, iOS or Windows) , typically connected to a public network or private network 103 to communicate with an identity provider 107. A Web server 104 hosts a Web application of a service provider which can offer different kind of services such as e- commerce, banking or financial services, public services or access portals to distributed computing systems, including cloud compu^¬ ting, or more in general any entity providing access to an area reserved for authorized users only and distributing its services via a public or private network.

The network 103 can be any network or combination of data transmission networks which include, without limitations, wired (e.g. Ethernet) or wireless (e.g. Wi-Fi, 3G, 4G, 5G, H+, EDGE, Wi-Max) networks of any extension (local LAN networks, metropol^¬ itan MAN and geographical WAN) or the Internet.

The Web server 103 and the portable device 101 do not nec^¬ essarily need to interact with the same network, but the respec^¬ tive networks are interconnected somewhere in the network 103. To this end, the network 103 can support the protocols, services and technologies of the Web and mobile cellular network, among which, for example, without limitations, the http protocol or the mobile terminal notification services (push notifications) and can uniquely identify machines, resources or services by means of an Internet Protocol (IP) address, a Uniform Resource Identifier (URI) , or a Uniform Resource Locator (URL) hyperlink.

In the present embodiment, the user 100, which uses any device 101, whose security level is not known, is enabled to view Web pages being supplied via the network 103 to a secondary device 102 (it can be a public or private desktop PC equipped with a Web browser, an embedded PC equipped with an LCD display, a terminal of an automation system for buildings, a smart TV) , in order to access a reserved area of the website published on the server 104.

The secondary device or client 102 can be any device with a security level of any kind, even not secure (because it is irrel^¬ evant for the purposes of the invention) . When the user 100 attempts to browse the restricted area of the Web application on the server 104, the browser does not contain authentication data on first access, then it is redirected - ei^¬ ther automatically or by means of a special button that is pre^¬ sented for this purpose on a page generated by the Web server - to a login page of the identity provider 107. Alternatively, the secondary client 102 can be redirected to the login page of the identity provider 107 through a user interface element such as a button, a software module 105, or a combination thereof.

Differently from the prior art, it is the same identity provider which - after collecting the navigation data of the browser (IP, session, page of origin, ...) - proceeds to generate a secure QR code, i.e. a QR code containing a hash recognizable by the software application (app) previously installed on the smartphone (primary client) 101 of the user 100.

In essence, the landing page of the identity provider on which the user is directed, is displayed on the non-secure device or secondary client 102 and contains the secure QR code generated by a QR generation service 111, containing a unique identifier of the Web browser session of each client. As mentioned, the QR code generator 111 includes preferably in the QR code a hash calculated from the content of the QR code and a secret key, stored in the identity provider 107. An enlarged copy of the QR code is shown on the right side of FIG. 2.

In essence, the identity provider 107 mediates the access to the Web application on the Web server 104 as follows. A user 100 who wishes to authenticate and have access to a certain session of the Web server, takes a picture of the QR code with the portable device 101 which transmits the content through the network 103 to the authentication service 112 of the identity provider 107 by means of an encrypted message containing a unique identifier of the user 100, a unique identifier of the portable device 101, the content of the QR code and a One Time Password (OTP) generated preliminarily by the identity provider 107 upon initial subscription of the user 100. The message can be encrypted with a standard security algorithm, not lower than the Advanced Encryption Standard with a 256-bit key (AES-256) . An authentication code generated with the Keyed-Hash Message Authentication Code (HMAC) algorithm can be added to the message. The message can be delivered to the authentication service 112 with standard protocols such as Hyper Text Transfer Protocol (http) and the channel can be en^¬ crypted with the Transport Layer Security (TLS) protocol.

The authentication service 112 of the identity provider 107 checks the message and can reject the request in the following cases: 1) if the hash of the message is not correct; 2) if the hash of the QR code is not correct; 3) if the identifier of the personal device 101 is not present in a database of the devices 110; 4) if the user identifier is not present in an identity database 109; 5) if the identifier of the Web application of origin is not present in a corresponding database of the Web server applications 113; 6) if the OTP is not correct; 7) if a picture of the QR code has already been taken previously by another portable device which has sent the content to the identity pro^¬ vider .

The authentication service 112 can return a request to the portable device 101 of one or more additional authentication fac^¬ tors, which may include face recognition, "gesture", voice recog^¬ nition and others.

The authentication service 112 also consults the profiles of users and devices, or part of them, in an identity provider, an authentication service or an external online directory service 114. If the user's pre-recorded data is not sufficient to meet the requirements of the specific web server session to which the user requests access, the authentication service 112 may return a request to the mobile device 101 for one or more additional user information .

If all of the above checks are successful, the authentication service 112 produces a digitally signed access token, sends it to browser the secondary client 102 and redirects it to the original Web application of the web server 104 to which the user had requested for access. The Web application on the server 104, by means of an authorization module 106, can grant different access privileges based on the information included m the token issued and received by the identity provider 107.

In summary, the operating steps of the system are as follows: A) via the browser on the secondary client (not secure), a user 100 requests access to a protected page (technically via an HTTP GET method); GET instructions can be associated with headers: a standard http header is the so-called "Authorize" wherein the token is placed. At the first request the browser is not authen^¬ ticated and therefore the "Authorize" header is empty. B) The Web server therefore refuses access and redirects the browser - trans^¬ parently to the user - to a page of the identity provider wherein the QR code is generated, thus allowing the user to scan the QR code with the software application (app) of his/her smartphone (primary client) . C) Upon authentication (via the use of the app), the identity provider in turn redirects the browser to the page of origin of the service Web server referred to in point A) , but this time the correctly filled "Authorize" header in the GET re^¬ quest will be provided, which will allow access to the protected page of the Web server.

There is therefore no direct communication between identity provider and web server, because the token is provided by the identity provider to the user's browser 100 and then redirected to the web server's origin page.

The token is not editable by parties other than the identity provider, nor falsifiable, as it is protected by a hash mechanism.

FIG.2 illustrates an example of using the online QR code. The QR code generated by the generation service 111 is entered into an HTML page 202 displayed in a Web browser 201.

The QR code can be complemented by alternative authentica^¬ tion methods guided by traditional commands such as a button 203, which can be activated when the main method does not work.

The QR code 202 can be used in the pages of access to portals and distributed computing services, including cloud computing services, or displayed in a display 205 of access control systems at the gates of a building 204 or another controlled environment (car, vault, ... ) . In the case of an access control system that does not use a traditional IT system, such as the opening of a car or a turnstile to enter a building, electronics are very low, due to their size and cost, and may not be compatible with web page management. So the display of an intercom, a home automation system or a car will be able to show a bitmap of the QR code, but without embedding it in a Web page. Generally, these systems are called "embedded", as they are incorporated in electronics at (relatively) low cost, but have the same function as secondary client referred to in this context .

The online QR code 206 can include a URL 207 readable also by mobile devices provided with a generic reader. The URL 207 can automatically address the generic device to an archive (store) from which the device 101 of the user 100 can independently down^¬ load and install the software application (app) to manage the digital identity thereof and authenticate according to the process illustrated in FIG.3.

The same URL 207 may also include a list of parameters to uniquely identify the specific secondary client session wherein it is to be viewed, including the Web browser 201 or the access control or building automation system 204. The URL 207 can contain a hash, calculated according to the content of the QR code, com^¬ bined with a secret key stored on the identity provider 107 and recalculated each time the QR code is transmitted back to the server to identify any alteration of the original content or identify a QR code not coming from the identity provider 107.

FIG.3 shows the entire authentication process via a single- use QR code to a generic Web service. In step 301, the user requests a protected Web page to the Web server 104 through a desktop personal computer, tablet or other secondary client computer equipped with Web browser 102. The request can be sent through the network 103 using the GET or POST methods of the http protocol. In the next step 302 the Web server 104, through operating system functions or calls to standard libraries or frame^¬ works available in the most popular programming languages (C#, Java, PHP, etc.), checks if a valid access token is present in the http headers of the request.

The token is generated according to an open standard such as the Open ID Connect protocol to ensure the widest interoperability and can include an alphanumeric sequence that can be uniquely linked to the identity provider 107, the Web app 104 and the user 100. Unlike standard Open ID Connect protocol tokens, the token generated by the identity provider 107 loses its validity if the user attempts to access a website other than the one for which the token has been generated. In practice, the user who wants to access two websites must perform two distinct authentications, while with classic systems it is sufficient for the user to au^¬ thenticate only once and it is possible to "spend" the token on an arbitrary number of websites.

If the token is not present, as it ordinarily happens at the first access by the user 100, the web server 104 redirects the browser to a login page 201 of the identity provider 107. The browser redirection can be implemented with a standard http re^¬ sponse (result code 302 redirect) which forces the browser to request the URL of the login page 201 of the identity provider 107 with a standard call http GET. At the next step 303 the identity provider builds an HTML page 201 comprising a single-use QR code, containing a unique URL 207 for the browser session that performed the GET, and provides it to the secondary client 102 to be displayed to the user 100. A new request from the same browser session or a refresh thereof does not change the QR code. A request from any other session in any browser of a different device may have a different identifier from the previous one in the URL 207. In the URL 207, each QR code preferably shows a hash, calculated with standard algorithms (SHA256, SHA512, Blake2) starting from its content and from a secret alphanumeric sequence stored in the identity provider 107 and unique for the latter. The aforementioned sequence can be obtained from the private key of a digital certificate or from a digital signature calculated with standard algorithms (RSA or ECDSA) . At the next step 304 the HTML page generated at step 303 is displayed to the user in the browser on the secondary client 102. At the next step 305, the user 100 acquires the QR code 202 contained m the login page 201 via the application installed on the portable device 101. The camera of the device 101 can return to the application an electronic repre^¬ sentation of the framed image in the form of a bitmap which can be converted into the alphanumeric sequence 207. The application of the portable device 101 creates an encrypted message with a symmetric security key, for example not less than the Advanced Encryption Standard with a 256-bit key (AES-256) . An authentica^¬ tion code generated with the Keyed-Hash Message Authentication Code (HMAC) algorithm can be added to the message. The message may contain the sequence 207, a unique identifier of the user, a unique identifier of the portable device and a single-use password (One Time Password, OTP) . At the next step 306 the aforementioned message is sent to the authentication service 112 of the identity provider 107. At the next step 307 the identity provider checks the syntax of the QR code 207 content and recalculates the hash. If both checks are successful, the process goes on, otherwise the identity provider 107 refuses the authentication and can send an error message or repeat the process for a predetermined number of times, offering again a new QR code. At the next step 308 the system searches for the identifier of the portable device in the database of the devices 110 and, if successful, the authentication process continues. At the next step 309 the identity provider checks the OTP and, if successful, the authentication request can continue. Once the above checks have been completed, the process can proceed to the next step 310 which provides the request for consent to privacy data processing by the user through the soft^¬ ware application on board of the portable device 101. Upon the expression of consent, the identity provider 107 can request the user 100 via the application of the portable device 110 for the missing data of the user profile which are necessary for the subscription to the service or for the access to the site hosted by the Web server 104. If the user expresses the aforementioned consent, the process ends at step 311 wherein the identity pro^¬ vider 107 releases an access token, valid for the protected re^¬ source of the Web application resident on the web server 104, and sends it to the browser on the client device 102. If any of the checks 307, 308, 309 or 311 fails, the identity provider 107 refuses the authentication and can send an error message or repeat a new QR code for a predetermined number of times.

FIGs 4A— D show the authentication process when the mobile device is offline (offline or backup authentication) . The login page 201 of the identity provider 107 can be provided with a specific offline button 401 for starting the offline authentica^¬ tion process. The offline authentication process (backup authen^¬ tication) occurs in the following sequence: at the first step 406, the user 100 presses the offline button 401 which sends a request to the identity provider 107 to display a backup authentication page. At second step 407 the identity provider 107, in response to the user request, sends to the browser of the secondary client an offline service page 402 on which a unique identifier of the user account (user id) and a single-use OTP password must be entered. The unique identifier of the user account can consist of its email address.

The OTP is generated, for example by the software application on board of the portable device starting from the system time and from a secret alphanumeric sequence (secret OTP) stored in a pro^¬ tected storage of the portable device (Key Chain) and obtained in advance from the identity provider 107 at the first subscription step of the portable device 101 and of the user 100 in the identity provider 107.

At the next step 408, the user 100 enters user id and OTP, then (step 409) the user 100 presses the login button of page 402 and sends them to the identity provider 107. In the next step 410 the identity provider 107 checks the existence and validity of the user account specified in the login page 402 and, if the check is successful, the process goes on. In the following step 411 the identity provider checks the OTP and, if it is also valid, the authentication process continues. In the next step 412 the iden^¬ tity provider 107 sends to the browser 102 an HTML page comprising three elements: a QR code 403 with an encrypted message, a field 404 for entering a PIN and a button 405 for submitting the PIN to the identity provider 107. The encoded QR code 403 advantageously contains an alphanumeric sequence comprising the aforementioned PIN, encrypted with standard symmetric key algorithms having se^¬ curity not lower than AES-256 and a hash for message authentica^¬ tion (HMAC) , calculated on the QR code content. The symmetric key can be saved in the protected storage of the mobile device 101 and in the identity provider 107. At the next step 413 the user

100 acquires the encrypted QR code 403 with the portable device

101 and, through the software application (app) on board of the portable personal device, checks the hash (HMAC) , decrypts the content with the symmetric key and extract the PIN. The user 100 reads the PIN displayed on the mobile device application 101, types the PIN in the field 404 and press the key 405 to submit the PIN to the identity provider 107. In the next step 414 the identity provider 107 checks the PIN 404 and, if this corresponds to the encrypted PIN previously entered in the QR code 403 and sent to the browser in step 412, the authentication is successful and the identity provider 107, in the next step 415 issues an access token, valid for the protected resource of the application hosted on the Web server 104. If the PIN sent in the field 404 either does not match the one encoded by the identity provider 107 in the QR code 403 or is not valid, then the authentication is rejected (step 416).

FIG. 5 illustrates a printable QR code 501 (offline QR code) used in the subscription (onboarding) and authentication processes represented in the flow chart of FIG. 6. The offline QR code 501 can contain the URL of a Web page in standard HTML language (landing page) or a standard Web application, accessible from any portable device provided with a camera and able to read generic QR codes and browse the web page addressed by the QR code, without the aid of ad hoc software applications. The aforementioned Web page may contain an explanatory text of the authentication service implemented in the identity provider 107 and the software appli^¬ cation (app) that will be installed in the portable device 101 and can provide instructions for installing the aforementioned software application in the devices that are not provided with it at the time of scanning the offline QR code 501.

The content 502 of the offline QR code 501 may include a list of parameters queued to the URL, in standard format and readable by the web browsers installed on board of the portable devices 502. The format of the URL 502 may include a parameter divided into subfields including the following alphanumeric data 503: a unique identifier of the Web site or Web application hosted on the Web server 104 containing the protected area for which the portable device 101 requires access (PartnerlD) ; a unique identi^¬ fier reserved for the service provider of the aforementioned web^¬ site (partner site) whose use can be decided independently by the provider and, generally, uniquely identifies the printed series of offline QR code (ReservedID) , for example to monitor the sub^¬ scription to an e-commerce service managed by the provider that authenticates with identity provider 107; a unique identifier of the user's identity (TypelD) , which specifies the type of account required by the service and which can be of various types, in^¬ cluding, without limitation, the actual identity of the natural person requesting to access the service, the corporate identity (corporate identity) if the access to the service, for example, is reserved to legal representatives of a legal entity such as corporates or entities, or the zero level identity (cyber iden^¬ tity) for the access to services without special security require^¬ ments, such as Internet forum groups, which do not provide for certification of the user profile; a hash calculated with standard algorithms (among which can be included, by way of example and without limitations, SHA256, SHA512 or Blake 2) starting from the content of the offline QR code and from a secret keyword or from an alphanumeric sequence directly or indirectly generated, start^¬ ing from the private key of a digital certificate stored on the identity provider 107.

Alternatively, the QR code 501 may include a URL 504 divided into multiple substrings comprising the URL of the aforementioned landing page, a unique service ID, reserved for internal use of the identity provider 107, a hash calculated with the same modes used for the content 502 and a unique ID of the QR code (QRCodeUniquelD) .

Advantageously, the offline QR code can also contain geolo- cation information, for example the position in which the support bearing the QR code is installed. In this way, when the software application (app) detects the QR code and transmits it to the identity provider, it transfers this geolocation information, which allows both to verify the real location of the user regard^¬ less of the activation of the GPS on the mobile device, both the creation of statistical data collections about the most visited points or the ones more referenced by users to access that specific authenticated service, about the most used sales channel or the type and location of the most effective physical support, for example to optimize the return on the investment in a specific advertising campaign.

FIG. 6 illustrates the authentication process of the user 100 taking a picture and acquiring the offline QR code 601 by means of a portable device 101 with the application already in^¬ stalled on board. The offline QR code 601 may have the content 503 or the content 505 represented in FIG. 5. At the first step 602, the user 100 frames the QR code 601. At the next step 603 the software application (app) sends the contents of the QR code to the identity provider 107, together with a unique user identifier (User ID) , a unique identifier of the portable device (Device ID) and a One Time Password (OTP) . The mobile application can use for submitting a symmetric security encrypted key no less than the Advanced Encryption Standard with a 256-bit key (AES-256) . A code for the authentication thereof generated with the Keyed-Hash Message Authentication Code (HMAC) algorithm can be added to the aforementioned message. At the next step 604 the aforementioned message is validated by the identity provider 107. The checks may include, but are not limited to, the verification of the HMAC hash, the check of the existence of the User ID and the Device ID, the verification of the OTP, the syntactic check of the QR code, the verification of the existence of the provider codes

(Partner ID) included in the QR code 503, the verification of the existence and validity of the code reserved to the provider (ReservedID) , the recalculation of the hash on the content of the QR code 503 and the relative comparison with the hash included in the same content 503. The success of the checks advances the process, otherwise the identity provider 107 can return an error message 605. At the next step 606, the identity provider 107 sends the URL to the software application (app) of the secure page of the Web site of the provider hosted on the Web server 104. At the next step 607 the software application (app) starts an internal Web browser and tries to navigate the URL of the aforementioned page. At the next step 608 the Web server of the provider requires the authentication and redirects the browser on the portable de^¬ vice to a login page of the identity provider 107. At the next step 609 the identity provider 107 sends to the browser on the portable device an HTML code which can contain a text element (QR element) of content similar to that of the One Time QR code 207, comprising a unique identifier of the browser session and a hash calculated on the same content. At the next step 610 the software application (app) executes the same code described starting from step 306 of the flowchart in FIG.3, using the text QR element in place of the One Time QR code and building the same encrypted message of the sequence of FIG.3. The identity provider 107 per^¬ forms the same checks, valid for the authentication of the Web pages, described at step 307 and following FIG.3. The web appli^¬ cation hosted by the Web server 104 (provider site) can request the identity data of the user 100 to the identity provider 107. If the user's Web server requires user data not present in the identity provider 107, for example to start an online purchase in an e-commerce system or to subscribe to an event, the identity provider 107 can request the integration of the user's personal data 100 via the software application (app) and store them for future use.

FIG. 7 shows the subscription/registration process of a user 100 as a private entity, provided with a personal portable device 101, not controlled by a centralized control system (Mobile Device Management) . At the first step 703, the user 100 takes a picture an online One Time QR code 701 or an offline QR code 702 with a generic portable device, provided with the standard QR code reader provided with the operating system. At the next step 704 the portable device 101 makes a http GET request to the URL contained in the QR code (in the example 701 and 702 the URL is ht .ps : //I . irier, com) through the software application (app) browser. The URL pointed to by the QR code can be associated with a Web application (landing page) programmed to recognize the type of operating system of the portable device that is browsing it (for example, without limitations, Android, iOS or Windows). At the next step 705 the landing page logic redirects the browser of the portable device to a Web page comprising the hyperlink for downloading the software application (app) described above. The aforementioned logic can direct the browser directly to the online store of mobile applications (by way of example, and without lim^¬ itations, Google Play Store for Android, Apple Store for iOS and Windows Store for Windows Mobile) , or at Web pages in HTML language or other suitable standard la language and containing instructions for the use of the service, terms and conditions or other infor^¬ mation required by legal obligations and then move to the online store of the applications (store) . At the next step 706, the user downloads the software application, installs it on his/her port^¬ able device 101 and launches the app. At the next step 707, the running application registers the mobile device in the identity provider, sending a message containing its unique identifier (Device ID) . The message can be encrypted with a standard asymmetric key algorithm such as RSA. The identity provider 107 can respond to the mobile device with a unique code (GUID) using an alternative channel which is independent from the main channel in which the requests of the portable device 101 to the identity provider 107 are delivered. An example of an alternative channel with respect to the main one (which can be realized with a standard https connection encrypted with TLS protocol) may consist of notifica^¬ tion messages (push notifications) sent to the mobile device through different services based on the platform used (merely as an example, it is possible to mention Google Firebase for Android and Apple Push Notifications for iOS) . The identity provider 107 can check the unique GUID code for each request of the software application (app) , limit the maximum number of requests per unit of time from the same device and reject requests without the unique GUID. At the next step 708 the user 100 enters name, sur^¬ name, email address (email) and telephone number thereof in the software application (app) . At the next step 709 the aforemen^¬ tioned data are sent to the identity provider 107 in an encrypted message. The message can be encrypted with a standard asymmetric key algorithm, such as, without limitations, RSA or elliptic curve cryptography (ECC) . The identity provider 107 can check the syntax and validity of the message and the data contained and can reject the call in case of incomplete or incorrect data. If the checks are successful, the process goes on and at the next step 710, the identity provider can send two numeric codes, one via Short Mes^¬ sage System (SMS) and one via email. The codes can be produced with a random number generation software algorithm with cryptographic quality (cryptorandom) , with dedicated cryptographic hardware (Hardware Security Module or HSM) or through dedicated and trusted services. The channels for submitting codes can be replaced by a plurality of alternatives, among which are included, without limitation, interrupted telephone calls (missed calls), voice calls or the use of external verification services. At the next step 711 the user 100 resends the aforementioned codes by typing them in an input mask of the software application (app) . The software application can facilitate the process by automati^¬ cally retrieving, if the operating system allows it, the code from the received SMS and sending it to the identity provider 107 without user intervention. At the next step 712 the identity pro^¬ vider 107 checks the correspondence between the codes sent to the user and those returned by the software application (app) . If they coincide, the user is registered in the database of personal data and his/her software application (app) receives a secret key for the authentication (OTP Secret) and a symmetric key for the en^¬ cryption of all the messages exchanged between mobile device 101 and identity provider 107 compatible with an algorithm having a security level of not less than the 256 bit Advanced Encryption Standard (AES-256) . The software application (app) can prompt the user for a Personal Identification Number, store it in a protected storage of the operating system, request it at each subsequent use and inhibit the use of the application when the user does not enter it or types it wrongly for a predetermined number of at^¬ tempts. At the end of the procedure (step 713) the user can au^¬ thenticate to the Web services hosted on the Web 104 of the various service providers .

FIG. 8 illustrates the subscription/registration process in the case in which the user 100 is a corporate user whose personal details with relevant profile are already present in the infor^¬ mation system or in an online directory service owned by the company or available to them and the portable device 101 is a resource managed by the administrator of a Mobile Device Manage^¬ ment (MDM) system capable of installing applications remotely on the portable device 101, verifying their compliance with company policies, including those of security and deleting the content

(wiping) from a remote location provide with the necessary privileges. In the exemplary embodiment considered in FIG. 8, at step 801, the portable device 101 is included in the inventory of the MDM system that knows both the user base data 100, including the email address and telephone number, and the portable device 101 such as a unique identifier or the SIM card number. At step 802, the system administrator installs the software application (app) on the portable device 101. At step 803 the software application

(app) can communicate with the MDM and know if the portable device 101 is owned by the company or user. In the first case, the process goes on to step 805 in which the identity provider 107 retrieves the user's basic data, typically name, surname and email address, from the user profile already present in the company registry. The system administrator can impose restrictions on the access to the company profile by the identity provider 107 which can only see a subset of the personal and/or corporate data of the user 100. At the next step 806 the software application (app) of the portable device 101 prompts the identity provider 107 to generate the symmetric key and the secret OTP. In the following step 807 the identity provider 107 sends the symmetric key and the Secret OTP to the software application (app) . From this time (step 808) the account is ready and the portable device 101 can be used for the authentication of the user 100.

Following the above disclosure, it is evident that the inven^¬ tion achieves the intended purposes. In fact, thanks to the con^¬ nection infrastructure between personal portable device (primary client) , service provider web server, uncontrolled access device (secondary client) , server of the identity provider and connection network, it is possible to offer to the user an access to web server pages that require authentication, without the user having to remember complex passwords or having to worry about the secu^¬ rity level of the access device (secondary client).

It is no longer provided to multiply the login pages on the websites of the service providers, with the resulting advantages in terms of maintenance and security burden.

It is no longer necessary to train the user to recognize the login pages: the system of the invention provides to offer a unique and recognizable layout located on the server of the iden^¬ tity provider, which can be described minutely in the instruc^¬ tions, in a known and centralized position, easily identifiable and always protected by the ssl certificate of the identity pro^¬ vider which, being a key component of system security, it is easy to remember as it is unique.

The system is designed in such a way that it can also be operated in offline mode, i.e. with the personal portable device without an access to the communication network.

The object of the invention is susceptible of numerous modi^¬ fications and variations, all of which falling within the in^¬ ventive concept expressed in the attached claims. All the details may furthermore be replaced by other technically equivalent ele^¬ ments, and the single components may be different depending on the needs, without departing from the scope of the present inven^¬ tion .

Although the object has been disclosed with particular reference to the accompanying figures, the reference numbers used in the description and claims are used to improve understanding the invention and are not intended to limit the claimed scope.

In particular, it should be considered that throughout the text reference is made only to a QR code, but it is understood that the same reliable information can also be provided by dif^¬ ferent technologies, for example a dynamic light sequence or a sequence of sounds. In this sense, it is possible to make reference to all these different representative forms, as elements of safe routing .

Claims

1. A user authentication system (100) for access to a protected resource (104) of a service provider accessible in a first network (103), comprising

- a primary client, in the form of a personal portable device (101) , provided with means for acquiring a secure routing element (206) and on which a software application (app) is running, which is adapted at least to interpret said secure routing element (206) and to communicate it on a second communication network to an identity provider,

- a secondary client (102, 204) adapted to access said re^¬ source (104) of the service provider via said first network (103) using consultation means in the form of a browser,

- an identity provider infrastructure (107) adapted to store digital identity information of said user (100) and to generate an authentication token recognizable by said resource (104) of the service provider,

- said secure routing element (206) comprising coded infor^¬ mation at least of session and of identity of said identity pro^¬ vider (107), characterized in that,

- said secure routing element (206) is created by said iden^¬ tity provider infrastructure (107) at the time said consultation means in the form of a browser are routed from said resource (104) of the service provider to a landing page of the identity provider (107)

- said secure routing element (206) incorporates a hash rec^¬ ognizable only by said software application (app) , and in that

- said authentication token is provided by the identity pro^¬ vider (107) to said consultation means in the form of a browser.

2. System as in claim 1, wherein said secure routing element is a QR code and said acquisition means of the personal portable device (101) are a digital camera.

3. System of claim 1 or 2, wherein said protected resource is the set of Web pages that make up a reserved area of a Web server .

4. System as in claim 1 or 2, wherein said protected resource is an electronic device for the opening of a physical barrier of a user access.

5. A user authentication method (100) for access to a pro^¬ tected resource (104) of a service provider accessible in a first network (103), comprising the following steps to be performed in a system as in any one of the preceding claims:

- routing a primary client, in the form of a personal port^¬ able device (101), provided with means for acquiring a secure routing element (206) and on which a software application (app) is running, which is adapted at least to interpret said secure routing element (206) and to communicate it on a second communi^¬ cation network to an identity provider,

- routing consultation means in the form of a browser of a secondary client (102, 204), which require the access to a re^¬ source (104) of a service provider via a first network (103), to a landing page of an identity provider (107)

- causing said identity provider (107) to create a secure routing element (206) comprising coded information at least of session and of identity of said identity provider (107)

- supplying to said consultation means in the form of a browser on the secondary client (102, 204) said secure routing element, so that it can be acquired by said acquisition means of the primary client (101),

- generating a communication flow on a second communication network towards said identity provider (107) by said software application (app) ,

- generating an authentication token recognizable by said resource (104) of the service provider, the token comprising at least session and user identity information, characterized in that,

- said secure routing element (206) is generated in such a way as to incorporate a hash recognizable only by said software application (app) , and in that