Automatic authentication by a gateway for access to a resource by a device
A gateway automates authentication for multiple devices by storing resource identifiers and authentication data, providing secure and efficient access management without device configuration, addressing the inefficiencies of current password management systems.
Patent Information
- Application Number
- PCT/EP2025/069442
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-07-26
- Filing Date
- 2025-07-08
- Publication Date
- 2026-01-29
AI Technical Summary
Managing multiple device authentication for secure access to resources is cumbersome due to the need for individual configuration and password management, especially on devices that cannot install applications, leading to a tedious and inefficient user experience.
A gateway determines and provides authentication data for devices accessing resources, storing associations between resource identifiers and authentication data, allowing transparent and automated access management across devices without requiring device modifications.
Enables seamless, secure, and centralized authentication management across devices, reducing user effort and enhancing security by distributing authentication data across multiple devices, thus minimizing risks from cyberattacks and device theft.
Smart Images

Figure EP2025069442_29012026_PF_FP_ABST
Abstract
Description
Automatic authentication via a gateway for access to a resource by a device FIELD OF INVENTION
[0001] The present invention relates to secure access to resources available on servers from equipment connected to the server via a gateway. It applies to resources secured by the requirement for the equipment to provide authentication data. These resources are typically web resources.
[0002] Many resources accessible on servers are secured to allow access only after user authentication. These resources can include website pages, audio and video content, and so on. Authentication is necessary when these resources should only be accessible to specific users, for example, because they contain personal data (banking websites, etc.) or because a prior action (payment, subscription, etc.) is required.
[0003] It is common for the user to have to authenticate with the server hosting the requested resource by providing authentication data, typically a pair consisting of a user ID (or "login" according to the usual English language terminology) and a password.
[0004] Because authentication data is sensitive, users are often required to set strong passwords (number of characters, various character types, etc.) and to change them regularly. As a result, remembering and managing passwords has become a complex task for users.
[0005] Specific applications are available for managing these passwords. These applications, or "password vaults," generally need to be manually installed by the user for each device used and are not necessarily available on all devices.
[0006] Some devices, such as connected objects (smart speakers, etc.), do not have open interfaces allowing the user to install new applications.
[0007] Furthermore, when a user (or typically a family) has multiple devices that can access the same resource, it is necessary to install and configure each device, saving the authentication information. When it becomes necessary to change this authentication information periodically, the user must reconfigure each device using its specific interface and procedures.
[0008] This situation can arise when a user wants to be able to access an audiovisual content delivery service from one or more televisions, one or more computers, the mobile phones of each family member, connected speakers (to stream radio, on-demand music, etc.)…
[0009] It is understandable that the need to configure each piece of equipment individually can become a tedious task, especially when there are multiple access points to manage in the same way.
[0010] There is therefore a need to improve current state-of-the-art proposals to allow for more ergonomic management of access to resources, particularly in the case of multiple devices.
[0011] The invention aims to enable access to a remote resource by at least one device through automated and transparent authentication performed by a gateway. In particular, it avoids the need to modify the device environment and can therefore be adapted to any type of device, including those that do not allow the addition of applications or configuration.
[0012] For these purposes, according to a first aspect, the present invention can be implemented by a method for accessing a resource accessible on a server connected to a first telecommunications network by equipment connected to a second telecommunications network linked to said first telecommunications network by a gateway, in which said gateway determines authentication data for said resource; provides authentication data to said server upon receipt of an authentication request received from said server and intended for said equipment; transmits said resource received from said server to said equipment).
[0013] According to preferred embodiments, the invention comprises one or more of the following features, which may be used separately, partially, or in full: The authentication data is determined from an identifier corresponding to the resource transmitted by the equipment during an initial request. Typically, this initial request is directed to a domain name server or DNS server. Thus, the gateway can determine the identifier corresponding to the resources in subsequent requests, leveraging standard protocol exchanges without requiring additional signaling. The gateway stores an association between identifiers corresponding to a set of resources, including the resource itself, and the authentication data.These stored associations can thus be maintained in the medium or long term, allowing access to resources at any time by devices connected to the gateway. The gateway subjects access to the resource to an identifier of the device. An access control mechanism inherent to the proposed process can therefore be easily implemented. Furthermore, the association is linked to at least one identifier of an authorized device, and upon receiving a request to access the resource from that device, the gateway verifies whether an identifier of that device is associated with the resource in order to determine the authentication data. A user can provision these associations through an administration interface of the gateway. This mechanism allows for the consolidation of the administrative task that each user would otherwise have to perform for all their devices.
[0014] Another aspect of the invention relates to a gateway for accessing a resource accessible on a server connected to a first telecommunications network by equipment connected to a second telecommunications network linked to said first telecommunications network by said gateway, in which said gateway is adapted to: determine authentication data for said resource; provide authentication data to said server upon receipt of an authentication request received from said server and intended for said equipment; transmit said resource received from said server to said equipment.
[0015] In one particular embodiment, the gateway includes a digital vault for storing the authentication data. This allows authentication data to be stored securely, as on a personal device, but in a centralized and shared manner.
[0016] Another aspect of the invention relates to a computer program suitable for implementation on a gateway, the program comprising code instructions which, when executed by a processor, carries out the steps of the process as previously defined.
[0017] Another aspect of the invention relates to a data carrier on which at least one series of program code instructions for the execution of a process as previously defined has been stored.
[0018] Other features and advantages of the invention will become apparent from the following description of a preferred embodiment of the invention, given by way of example and with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE FIGURES
[0019] This illustrates a context for implementing a process according to embodiments of the invention.
[0020] This illustrates an example of the functional architecture of a management entity according to one embodiment of the invention.
[0021] Draw a schematic diagram of a process according to an embodiment of the invention.
[0022] DETAILED DESCRIPTION OF METHODS OF IMPLEMENTING THE INVENTION
[0023] An example of the context for implementing the proposed process is illustrated.
[0024] A device wishes to access a resource R accessible on a server S connected to a first WAN telecommunications network.
[0025] This equipment T can be any device suitable for accessing a telecommunications network. To do this, it has suitable hardware interfaces and corresponding software modules (implementing in particular the protocol stack corresponding to the hardware interface and the type of telecommunications network).
[0026] Equipment T can be of different kinds: computer (portable or fixed), mobile communication terminal such as "smartphone", MOB, digital tablet, connected television, TV, etc.
[0027] The television can be natively connected or connected via an associated device, such as a TV dongle connected to the television, usually via HDMI. One example of an external device that communicates with a TV is Chromecast. Chromecast is a real-time media streaming device (media gateway) developed and marketed by Google. The device plugs into the HDMI port of a television and communicates, via Wi-Fi, with another internet-connected device (computer, smartphone, tablet, etc.) to display media content on the television. This content can be received from a Google Cast-compatible application, from the Google Chrome browser on a computer, or from certain Android devices.
[0028] The resource R can also be of different natures: generally speaking, it can be any resource that can be identified by an address or URL ("Unified Resource Locator"). It can be a file in any format that can be accessed by any device.
[0029] In concrete terms, this can be a web page, that is to say a computer file in HTML format ("Hyper Text Markup Language"), or a set of web pages. It can also be an audio or video file, a streaming audio-video resource, etc.
[0030] This resource is accessible on a server S. This server S must be understood here from a functional point of view: the server S can be concretely deployed on a single machine or within a set of machines operating in a "farm", or on a computing or cloud platform (or "cloud computing" in English).
[0031] We assume here that the resource is secure: in order to access this resource, the equipment user must authenticate. According to a mechanism known in itself, if authentication is successful, the server S verifies whether the equipment can actually access the requested resource.
[0032] This mechanism can be implemented in different situations.
[0033] A first example is a page or set of pages containing the user's personal data. This could be, for example, an e-commerce site, a bank's website, a government website, etc. In such a situation, it is important to prevent other users from accessing the resource.
[0034] Another example is one or more pieces of content, such as audio or video, access to which is subject to a prior action, such as payment. The payment may be linked to this (or these) piece(s) of content in a "pay-per-view" manner, or it may be linked to a more comprehensive subscription (channel, service, etc.).
[0035] Other examples are obviously possible, and the proposed process is independent of the nature of the resource required by the equipment.
[0036] When a resource is secured, the server may require authentication data. This data is generally a pair consisting of a user ID (or "login" in common English terminology) and a password. However, other implementations are possible.
[0037] This provision ensures the identity of the user and thus allows them access to the resources to which they are entitled.
[0038] Server S is connected to a first telecommunications network of the "WAN" type (for "Wide Area Network").
[0039] This type of telecommunications network typically consists of several interconnected networks, including an access network that allows clients to connect to a main network (itself made up of interconnected subnets) or "backbone." This WAN is commonly called the Internet.
[0040] In general, the T equipment is connected to a second telecommunications network which can be a local network, LAN (for "Local Area Network").
[0041] For example, it could be a wireless local area network, commonly called WLAN for "Wireless Local Area Network". It can conform to the Wi-Fi, or wifi, protocols as specified in the IEEE 802.11 family of standards documents (or ISO / IEC 8802-11).
[0042] This local area network (LAN) can be an internal network within a home (home network), for example, allowing all the devices, or clients, of a user or family to connect. The LAN can also be an internal network within a company, allowing the devices, or clients, of the various users within the company to connect.
[0043] The local area network (LAN) can be connected to the WAN via a gateway P.
[0044] Gateway P is therefore in charge of routing and forwarding data packets between the two communication networks, LAN, WAN.
[0045] It can also provide additional functionalities such as a Wi-Fi router, in order to constitute the LAN communication network itself. However, this functionality can, depending on the embodiment, be offloaded to another piece of equipment.
[0046] An example of such a gateway is the Livebox™ from the company Orange.
[0047] According to one aspect of the proposed process, the gateway acts with respect to the server S to authenticate the user of the equipment T on its behalf.
[0048] Lare represents an organizational chart illustrating a process that can be implemented by the gateway.
[0049] Gateway P can implement the following steps: Step S1: determination of authentication data for resource R which the equipment wishes to access; Step S2: provision of authentication data to server S upon receipt of an authentication request received from this server S and intended for equipment T; Step S3: transmission of resource R received from server S to equipment T.
[0050] Thus, when a request from equipment T triggers the transmission of an authentication request from server S, this request can be processed by gateway P, in step S2, by providing the authentication data previously determined in step S1.
[0051] Once authentication is complete, server S can grant (or deny) access to the requested resource R. This access can be concretely manifested by the transmission of resource R from server S to equipment T, via gateway P.
[0052] Laillust illustrates more precisely an example of the implementation of this process in the form of a chronogram.
[0053] In a first preliminary step, S0, authentication data can be provisioned in the gateway P.
[0054] It can therefore include memory (preferably local, but it can possibly be remote) to store this authentication data.
[0055] According to one embodiment, gateway P includes a digital safe for storing these authentication data.
[0056] Such a digital vault is a software, or primarily software, mechanism that allows a set of digital data to be secured within an online platform or equipment, such as the P gateway here.
[0057] A digital vault can implement various technologies to achieve this data security objective: Data encryption. Different tools and mechanisms can be implemented such as AES (Advanced Encryption Standard), RSA (Rivest-Shamir-Adleman), TLS / SSL (Transport Layer Security / Secure Sockets Layer)... Authentication, generally two-factor, to access the digital vault. And, optionally, physical security to increase security, with technologies such as HSM (Hardware Security Module) or TPM (Trusted Platform Module), based on the addition of a dedicated microelectronic chip.
[0058] Software tools also exist for implementing such digital vaults, with varying security performance characteristics and designed for different operating systems. These tools can therefore be easily deployed on the P gateway depending on the operating system it uses.
[0059] According to one embodiment, during the preliminary step S0, the gateway stores an association between at least one identifier corresponding to the resource R and the corresponding authentication data.
[0060] The identifier corresponding to the resource can directly and uniquely identify the resource; that is, it can be a resource identifier. It can be, for example, a URI (Uniform Resource Identifier) for that resource.
[0061] In another embodiment, the identifier corresponding to the resource can identify a set of resources of which the requested resource is a part. For example, the identifier could be that of a website, for instance, or that of the host associated with the requested resource.
[0062] In such a situation, any particular resource belonging to that host can be associated with the same authentication data, so it is sufficient to remember a host identifier, rather than remembering the identifiers of each resource individually. Furthermore, the user may not be aware of these R resources at the time of provisioning, but only of a website or a host.
[0063] For example, an R resource belonging to a site "mysite" would have the corresponding identifier "www.mysite.com / R" or, preferably, "www.mysite.com"
[0064] It is thus easy for gateway P to determine later that a request to a resource R corresponds to an association provisioned in its memory.
[0065] Gateway P may have an administration interface that allows a user to provision these associations. The user can then choose which websites they want to delegate automatic authentication to Gateway P.
[0066] This task is similar to that performed in other approaches where the user must provision the data on their own equipment. However, in the proposed method, provisioning is performed on a gateway P, allowing this provisioning to be shared among multiple devices (which access resources R via gateway P) and, potentially, multiple users.
[0067] The administration interface can already be planned and adapted to allow the additional functionality of provisioning (and modifying) this association. It can be a web-based interface to which the user can connect via a T-type device. It can also be an API (Application Programming Interface) to which the user can connect using a specific application installed on a T-type device. Other implementations are, of course, also possible.
[0068] Thus, the gateway can store a table, or database, made up of associations provisioned by the user or, possibly, by other means (for example, automatically retrieved from the T equipment by a synchronization tool, or retrieved from a remote service platform, etc.)
[0069] Later, a device T wishes to access a resource R available on a server S.
[0070] In this situation, it issues an initial request m1. This first request contains an identifier corresponding to the resource R (for example, its URL). Typically, this first request is intended for a domain name server or DNS (for "Domain Name Server").
[0071] The role of this domain name server, DNS, is to provide the network address (or IP for "Internet Protocol") at which the requested resource is available.
[0072] This first request m1 therefore contains an identifier corresponding to the resource R. The gateway P can therefore determine this identifier from this first request m1.
[0073] In a step S1, the gateway P can determine authentication data for the resource R identified by the identifier corresponding to the resource transmitted by this first request m1.
[0074] To do this, it can rely on the associations previously provisioned (step S0). In particular, it can determine the authentication data from the identifier corresponding to the resource transmitted in this first m1 request by searching for it within these associations and selecting the corresponding authentication data.
[0075] The domain name server, DNS, responds to the first query m1 with a message m2 indicating the address of the server S on which the resource R is accessible. This address is typically an IP (Internet Protocol) address, IPv4 or IPv6. The gateway P can then store an association between the IP address and the URL.
[0076] According to one embodiment, gateway P can subject access to resource R to the identifier of equipment T.
[0077] The gateway can interpret the first m1 request to determine an identifier of the equipment, such as its IP address (in the case where this is fixed and not assigned to each connection) or its physical address, MAC.
[0078] It is then possible to grant access to the resource only for certain equipment.
[0079] These devices can be planned in advance, for example, during the provisioning of associations in step S0. In this case, the gateway can be configured to associate the provisioned associations with at least one identifier of an authorized device. Thus, upon receiving a request m1 to access the resource R from this device, the gateway P checks if a device identifier is associated with the resource in order to determine the authentication data. If not, the gateway may not determine any authentication data.
[0080] It is also possible to grant access to the resource to any device known to gateway T, but to deny access to a new device. This prevents unauthorized devices or devices not belonging to the family or company's equipment pool associated with the LAN from benefiting from the automatic authentication feature.
[0081] Device T can then send a second m3 request to server S where the resource is available. This m3 request is addressed to the IP address sent by the m2 message from the DNS domain name server.
[0082] In response to this m3 request, the server S can respond with an authentication request m4.
[0083] Server S can detect that the resource R requested by device T and identified in the m3 request is a secure resource. This detection can trigger an authentication request.
[0084] This authentication request may consist, in particular, of verifying whether the equipment (or its user) has the security data allowing access to the resource; of verifying that an account, or profile, associated with the user has sufficient rights for access to the resource.
[0085] In both situations, the authentication request can, for example, take the form of a web page (i.e., in HTML format, which may encapsulate or refer to scripts) containing a form for entering a pair consisting of a user identifier (or "login") and a word, or phrase, for a password (or "password").
[0086] The m4 authentication request is a response to the m3 request and is therefore intended for the equipment T from which this request was issued.
[0087] This could typically be a "200 OK" message according to the HTTP protocol, for example:
[0088] <form>
[0089] <input login=" / ">
[0090] <input password=" / ">
[0091] < / form>
[0092] The user is expected to fill out this form and send back the entered data in a new message to the server S. In the proposed process, however, this authentication request can be intercepted and processed by the gateway P on behalf of the user.
[0093] Indeed, as we saw previously, the authentication data was previously stored (provisioned) in the gateway P in association with identifiers corresponding to the resources R.
[0094] Also, upon receiving the authentication request, in step S2, the gateway P is able to provide this authentication data to the server S, in a message m5. It simply needs to search in memory for the association corresponding to the identifier of the resource R. This identifier is present in the various requests, and the gateway P may have previously stored the correspondence between the identifier corresponding to the (logical) resource and its physical (IP) address present in the second request m3 and in the authentication request m4.
[0095] This m5 message can conform to prior art mechanisms; in particular, it can be a POST request from the HTTP protocol (the difference being that it is issued by the gateway and not by the device). Server S receives authentication data from gateway P, but this message can be constructed as a response to the authentication request m4 so that it is correctly interpreted by the server in the context of the dialogue with device T.
[0096] Upon receipt of the identification data, as explained previously, the server can determine, in a way known in itself, whether the authentication data provided allows access to the requested R resource or not.
[0097] If so, the server S transmits the requested resource in an m6 message.
[0098] In an S3 step, the gateway P transmits the resource received from the server S to the equipment T, in a way that is classic in itself.
[0099] The m6 message may also contain a certificate transmitted by the server S. This certificate, or "cookie" as it is commonly known in English, ensures that the device has been authenticated with the server: the device T can then transmit this certificate for subsequent requests to access other resources on the same site, for example, without having to authenticate again. This certificate may have a limited lifespan, after which the device must authenticate again.
[0100] Equipment T thus receives the requested resource without having to authenticate itself.
[0101] More specifically, we see that device T is not involved during the authentication phase. Authentication is therefore transparent to device T, meaning that the user does not need to take any action and that no modifications or special configurations are required for device T. It can be a standard, state-of-the-art device, without any additional software modules.
[0102] As previously mentioned, if a user has several devices T, they can provision the associations within the gateway P and, automatically, each of their devices will be able to access the resources without them having to perform any configuration operations on their devices.
[0103] If access to the resource is restricted by a device identifier, for example, to prevent access by unknown devices, then the authentication data is not automatically transmitted by the gateway. In such a situation, gateway P may retransmit the m4 authentication request to device T. Device T must then authenticate itself using a state-of-the-art method.
[0104] It is also advantageous that associations (and in particular authentication data) can be stored locally in the P gateway.
[0105] This method offers significantly better security compared to storing credentials on a remote platform such as the cloud. The cloud presents an attractive target for cyberattacks who can obtain a large amount of authentication data in a single attack. In contrast, the proposed method distributes authentication data across a large number of private devices, making a massive attack far more difficult to execute.
[0106] Furthermore, the proposed solution is more reassuring for users who keep sensitive data in their private homes. Indeed, it is not always well received to transfer sensitive data, such as authentication data, to a third-party platform like the cloud.
[0107] Furthermore, since authentication data is no longer stored and provisioned on the devices themselves (T), theft or hacking of these devices (for example, when the user is away on their mobile device) does not pose a risk to access to the resources (R). This can be important for resources associated with sensitive sites (such as banking sites). The probability of a physical theft of a gateway (P) is much lower than that of a mobile phone.
[0108] Of course, the present invention is not limited to the examples and embodiment described and illustrated, but is defined by the claims. In particular, it is susceptible of numerous variations accessible to those skilled in the art.
Claims
Method for accessing a resource (R) accessible on a server (S) connected to a first telecommunications network (WAN) by a device (T) connected to a second telecommunications network (LAN) linked to said first telecommunications network by a gateway (P), wherein said gateway determines (S1) authentication data for said resource; provides (S2) authentication data to said server (S) upon receipt of an authentication request received from said server (S) and intended for said device; transmits (S3) said resource received from said server (S) to said device (T). A method according to claim 1, wherein said authentication data is determined from an identifier corresponding to said resource transmitted by said equipment during a first request. A method according to the preceding claim in which said gateway (P) stores (S0) an association between identifiers corresponding, respectively, to a set of resources of which said resource R is a part, and said authentication data. A method according to any one of the preceding claims, wherein said gateway subjects access to said resource to an identifier of said equipment (T). A method according to the preceding claim and claim 3, wherein said association is further associated with at least one identifier of an authorized equipment, and wherein, upon receipt of a request to access said resource by said equipment, said gateway checks whether an identifier of said equipment is associated with said resource in order to determine said authentication data. A method according to claim 3 or claim 5 wherein a user can provision said associations by means of an administration interface of said gateway (P). Gateway for access to a resource (R) accessible on a server (S) connected to a first telecommunications network (WAN) by a device (T) connected to a second telecommunications network (LAN) linked to said first telecommunications network by said gateway (P), in which said gateway is adapted to: determine (S1) authentication data for said resource; provide (S2) authentication data to said server (S) upon receipt of an authentication request received from said server (S) and intended for said device; transmit (S3) said resource received from said server (S) to said device (T). Gateway according to the preceding claim, comprising a digital safe for storing said authentication data. Computer program suitable for implementation on a gateway, the program comprising code instructions which, when executed by a processor, carries out the steps of the process defined in claims 1 to 6. Data carrier on which at least one series of program code instructions for the execution of a method according to one of claims 1 to 6 has been stored.
Citation Information
Patent Citations
Systems and methods for protecting passwords
US11095636B1
Methods and systems for completing, by a single-sign on component, an authentication process in a federated environment to a resource not supporting federation
US20120331535A1
Remoting user credential information to a remote browser
US20210318894A1