Two factor authentication

Abstract

A method performed by a permission configuration server (106). The method includes receiving an authentication request message including a first authorization token (authToken) and a phone number. The method further includes retrieving a second authToken, where the retrieving includes retrieving the second authToken using the phone number. The method further includes determining whether the first authToken is valid, where the determining includes determining whether the first authToken is the same as the second authToken. The method further includes sending a verification response message in response to the verification request message, the verification response message indicating whether the first authToken is valid. Further methods, apparatus, computer programs and carriers are also disclosed.

Description

Technical Field

[0001] Disclosed are methods, devices, application servers, servers, authority configuration servers, open functions, computer programs, computer program products and carriers related to authentication. Background Art

[0002] Service providers (e.g., website or application (app) providers) typically use two-factor authentication ("2FA") to authenticate users. Typically, a service provider (e.g., website) generates a random 6-8 digit "one-time password" (OTP) and sends the OTP to a user's device (e.g., smartphone) via a short message service (SMS). When the user receives the OTP, the user manually enters the OTP into the app or web page for authentication.

[0003] The Entitlement Configuration Server (ECS) is a node / device deployed in the Communication Service Provider (CSP) (also known as the Mobile Network Operator (MNO)) network, used to configure device-based services (i.e., local apps built into the device operating system (OS)) during the entitlement verification step of the service or during the activation of the service. Typical device-based services include Voice over Long Term Evolution (VoLTE), Voice over WiFi (VoWiFi), and On-Device Service Activation (ODSA) for companion and primary devices (associated with the requesting device), etc. Most CSPs have deployed ECS in their networks.

[0004] For the protocol between the user's device (commonly referred to as "user equipment (UE)" or "communication device") and the ECS, more and more CSPs and equipment vendors are adopting the protocol specified in the Global System for Mobile Communications (GSM) Association (GSMA) TS.43(1) (e.g., version 8.0). In this GSMA technical specification, in order to support different use cases, device authentication uses an integrated circuit card (ICC) (e.g., a tamper-resistant ICC or an ICC with a tamper-resistant subscriber identity module (SIM)) in the UE, using the Extensible Authentication Protocol with 3rd Generation Authentication and Key Agreement (EAP-AKA) according to Internet Engineering Task Force (IETF) Request for Comments (RFC) 4187 ("RFC 4187"), which is an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution. IETF RFC 4187 has also been updated by IETF RFC 5448 and 9048. The ICC in the UE may be a universal integrated circuit card (UICC) including one or more SIMs, such as a universal SIM (USIM) and / or an Internet Protocol (IP) Multimedia Service Identity Module (ISIM), other memory or any combination thereof. The UICC may be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly referred to as a "SIM card". This authentication is secure and provides mutual authentication between the UE and the network.

[0005] Once the UE has passed EAP-AKA authentication for the ECS, some specific apps (e.g., native apps built into the device OS) may ask the ECS to generate a temporary token, which is then passed to the application server of the specific service to obtain a phone number (e.g., a Mobile Station International Subscriber Identity Number (MSISDN)) from the ECS. This use case is defined in Change Request (CR) 1051 of GSMA TS.43v8.0. Summary of the invention

[0006] There are certain challenges currently. For example, for 2FA, the assumption behind OTP via SMS is that only the user of the UE to which the OTP is sent can receive the OTP and enter it for 2FA. Unfortunately, however, this assumption is not always valid, as there are scenarios where an unauthorized user (eavesdropper or "attacker") can obtain the OTP. For example, SMS messages sent over a GSM network can be intercepted (i.e., an attacker can sniff the OTP over the air). As another example, a security vulnerability in the UE can make it easy for an attacker to obtain the OTP, e.g., a Trojan placed on the UE can receive the OTP and forward it to the attacker's email. Even some common apps that have the privilege of accessing the UE's SMS introduce the risk of OTP leakage if it is hijacked by a criminal.

[0007] In addition to the security risks, some users find it cumbersome and inconvenient to have to receive an OTP and manually enter the OTP every time the user wants to access a service (e.g., a website, a remote app, a resource, etc.). Although some modern OSes have introduced features that automatically read the OTP upon receiving it and automatically fill it in for use, this additional step of entering the OTP is still a bit annoying and increases the risk of OTP leakage.

[0008] Therefore, in one aspect, a method for determining whether to allow a user to access a service (e.g., a website or resource) is provided, the method utilizing a first device running a first app and a second app, wherein the first app is a third-party app used by the user to access the service or a non-third-party app (e.g., an aggregator app or a CSP app) for enabling the user to access the service using a second device separate from the first device. The method includes: the second app receiving an indication that the first app has requested an authentication token; after or before receiving the indication, the second app obtains a first authorization token authToken from an authority configuration server ECS; and after receiving the indication, the second app provides authToken to the first app. The step of obtaining authToken includes the second app performing a first authentication process or a second authentication process. The first authentication process includes: sending a request message including an unexpired second authentication token (e.g., a quick authentication token) to the authority configuration server ECS, so as to enable the ECS to determine that the second app has been previously authenticated (e.g., USIM authentication); and receiving a response message in response to the request message, the response message including authToken. The second authentication process includes: sending a request message including a hidden subscription identifier (e.g., a 5G Subscription Hidden Identifier (SUCI)) to the ECS; after sending the request message, receiving a challenge message from the ECS; generating a challenge response RES using a key stored in the ICC in the first device (e.g., a key encoded in the USIM stored on the ICC); sending a challenge response message in response to the challenge message, the challenge response message including RES; and after sending the challenge response message, receiving a response message in response to the request message, the response message including an authToken and an indication that the second app has been successfully authenticated.

[0009] In another aspect, a method for determining whether a device that a user is using to obtain access to a service is an authorized device (e.g., a device that includes a USIM bound to a phone number registered to the service by a subscriber of the service) is provided by a service provider associated with an application server, the method being performed by a first app running on the device. The method includes: the first app obtaining an authorization token authToken from a second app running on the device; the first app sending an authentication request message including authToken to the application server, the authentication request message also including an identifier and / or phone number associated with the user; and the first app receiving an authentication response message in response to the authentication request message from the application server, wherein the authentication response message indicates whether the device is an authorized device.

[0010] In another aspect, a method for determining whether a device that a user is using to obtain access to a service is an authorized device is provided, the service being provided by a service provider associated with an application server, the method being performed by the application server. The method includes: receiving an authentication request message from a first app running on the device, the authentication request message including an authToken obtained by the first app from a second app running on the device; after receiving the authentication request message, providing the authToken and a phone number to an ECS; receiving an indication that the ECS has determined that the authToken is linked to the provided phone number; and after receiving the indication that the ECS has determined that the authToken is linked to the provided phone number, sending an authentication response message in response to the authentication request message to the first app, wherein the authentication response message indicates that the device is an authorized device.

[0011] On the other hand, a method for determining whether to allow a user of a first device to access a service is provided, the method being performed by a first app running on a second device. The method includes: the first app receiving a first authentication request message, the first authentication request message including a phone number and a message for a user of the second device; after receiving the first authentication request: the first app displays the message to the user of the second device, and after displaying the message, the first app receives an indication indicating whether the user of the second device approves to allow the user of the first device to access the service; and if the indication indicates that the user of the second device approves to allow the user of the first device to access the service, the first app sends a second authentication request message to a remote server (e.g., an aggregator AF or ECS), the second authentication request message including: an authentication token authToken obtained from a second app running on the second device and a phone number.

[0012] In another aspect, a method for determining whether to allow a user of a first device to access a service is provided, the method being performed by an application server associated with the service. The method includes: the application server receiving a message from the first device including information indicating that the user of the first device wants to obtain access to the service; after receiving the message from the first device, the application server sending an authentication request message including a phone number to a second server (e.g., an AF or ECS of an aggregator); and after sending the authentication request message, the application server receiving an authentication response message in response to the authentication request message, wherein the authentication response message indicates that the user of the second device associated with the phone number has authorized the user of the first device to access the service.

[0013] On the other hand, a method for determining whether to allow a user of a first device to access a service is provided, the method being performed by a remote server (AF or ECS of an aggregator) remote from the first device. The method comprises: the remote server receives a first message including a phone number from an application server associated with the service; after receiving the first message, the remote server sends a second message to a first app running on a second device associated with the phone number, the second message including the phone number; after sending the second message to the first app, receiving a third message including an authentication token and the phone number from the first app; in response to receiving the third message, determining whether the authorization token is valid; and if it is determined that the authorization token is valid, the remote server sends a response message in response to the first message to the application server, wherein the response message indicates that the second device is an authorized device and the user of the second device does not object to the user of the first device accessing the service.

[0014] In another aspect, a method performed by an authority configuration server ECS is provided. The method includes: receiving a verification request message including a first authorization token authToken and a phone number; retrieving a second authToken, wherein the retrieval includes retrieving the second authToken using the phone number; determining whether the first authToken is valid, wherein the determination includes determining whether the first authToken is the same as the second authToken; and sending a verification response message in response to the verification request message, wherein the verification response message indicates whether the first authToken is valid.

[0015] In another aspect, a computer program is provided that includes instructions that, when executed by a processing circuit of a device, cause the device to perform any of the methods disclosed herein. In one embodiment, a carrier containing the computer program is provided, wherein the carrier is one of an electrical signal, an optical signal, a radio signal, and a computer-readable storage medium. In another aspect, a computer program product is provided that includes a computer-readable storage medium having a computer program stored thereon. In another aspect, an apparatus configured to perform the methods disclosed herein is provided. The apparatus may include a memory and a processing circuit coupled to the memory.

[0016] The advantages of the embodiments disclosed herein are that they provide a 2FA process that provides higher security than traditional SMS-OTP 2FA. In addition, no OTP needs to be provided to the user, which makes the 2FA process more user-friendly. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate various embodiments.

[0018] Figure 1 A system according to an embodiment is shown.

[0019] Figure 2 A system according to an embodiment is shown.

[0020] Figure 3 A system according to an embodiment is shown.

[0021] Figure 4 is a message flow diagram illustrating an embodiment.

[0022] Figure 5 is a message flow diagram illustrating an embodiment.

[0023] Figure 6 is a message flow diagram illustrating an authentication process for authenticating a local app according to an embodiment.

[0024] Figure 7 is a flow chart illustrating a process according to an embodiment.

[0025] Figure 8 is a flow chart illustrating a process according to an embodiment.

[0026] Fig. 9 is a flow chart illustrating a process according to an embodiment.

[0027] Fig.10 is a flow chart illustrating a process according to an embodiment.

[0028] Fig.11 is a flow chart illustrating a process according to an embodiment.

[0029] Fig.12 is a flow chart illustrating a process according to an embodiment.

[0030] Fig.13 is a flow chart illustrating a process according to an embodiment.

[0031] Fig.14 is a block diagram of a UE according to an embodiment.

[0032] Fig.15 is a block diagram of a base station according to an embodiment.

[0033] Fig.16 is a message flow diagram illustrating an embodiment. DETAILED DESCRIPTION

[0034] Figure 1 A system 100 according to an embodiment is shown. In the illustrated embodiment, the system 100 includes: a UE 102 (the UE 102 may be any type of device capable of communicating with a remote server); a network 114; an ECS 106 (although the ECS 106 is shown as being separate from the network 114, in some embodiments, the ECS 106 is within the network 114, such as within a core network of the network 114); an application server platform (ASP) 108 (e.g., a group of one or more application servers); and an aggregator 112. The network 114 may be any type of network (e.g., the network 114 may include one or any combination of the following: a wireless local area network (WLAN) (e.g., a WLAN based on the IEEE 802.11 standard (also known as WiFi)), a non-wireless network, a 3GPP radio access network (RAN), a 3GPP core network (CN)). As further shown, UE 102 includes an ICC 122 (eg, the UICC described in the background); native apps 124 , which in this example are part of the OS of UE 102 ; and 3rd party apps 126 running on top of the OS of UE 102 .

[0035] The present disclosure utilizes the ICC-based authentication capabilities of the local app 124 and the authentication token (also referred to as "token", or "authToken") generated by the ECS 106 to support Internet services (App-based or web-based) provided by the ASP 108 to perform 2FA authentication in a "silent" mode (i.e., a mode in which the user 101 does not need to enter an OTP). With this new authentication method, security is enhanced. In addition, since the user 101 is unaware that the 2FA process is occurring, the user experience is improved.

[0036] In one embodiment, in order for user 101 to gain access to services provided by ASP 108, the user provides the user's credentials (e.g., username and password) to ASP 108 via app 126 in a conventional manner. That is, app 126 can prompt the user to enter the user's credentials and then forward the credentials to ASP 108 so that ASP 108 can verify the credentials. If the credentials are verified, ASP 108 sends a message to app 126. In one embodiment, the message triggers app 126 to prompt the user to enter the phone number of UE 102 (step (1)). In another embodiment, the message triggers app 126 to request app 124 to provide an authentication token (or simply "token") (step (2)). For example, app 126 can utilize an OS application programming interface (API) to request a token.

[0037] App 124 then sends a request message to ECS 106 via network 114 requesting ECS ​​106 to generate a token (step (3)). ECS 106 generates the token, stores the token in association with the phone number associated with app 124 (e.g., the request message from app 124 includes information (e.g., SUCI) that enables ECS to obtain the phone number associated with app 124), and then provides the generated token to app 124.

[0038] After app 124 obtains the token from ECS 106, app 124 provides the token to app 126. App 126 then sends the token to ASP 108 (step (4)).

[0039] ASP 108 sends a message including the token and the phone number associated with the account that user 101 is trying to access to aggregator 112 (step (5)). Aggregator 112 selects an ECS (in this case, ECS 106) based on the phone number, and then sends a verification request message including the token and phone number to ECS 106 (step (6)).

[0040] The ECS then verifies the received token. That is, for example, the ECS 106 uses the phone number included in the verification request to retrieve a previously generated token (if any) associated with the phone number. If no such previously generated token exists, the received token is invalid. If such a previously generated token exists, the ECS determines whether the previously generated token has expired (e.g., based on a time value stored in association with the previously generated token, the time value indicating the expiration time of the token). If such a previously generated token exists and has not expired, the ECS determines whether the received token is the same as the previously generated token. If so, the received token is valid, otherwise it is invalid.

[0041] If the received token is determined to be valid, ECS 106 sends a positive acknowledgement (ACK) to aggregator 112 to indicate that the token is valid, otherwise a negative ACK (NACK) is sent to indicate an invalid token. Aggregator 112 sends an ACK or NACK to ASP 108 to indicate whether the token is valid. When ASP 108 obtains an ACK, ASP 108 determines that user 101 has been successfully authenticated (i.e., ASP 108 determines that device 102 is an authorized device—i.e., the phone number entered by the user when the user registered for the service is bound to device 102). In this way, ASP provides 2FA that is transparent to user 101.

[0042] Figure 2 A system 200 according to another embodiment is shown. System 200 is similar to system 100, except that user 101 uses another device 202 (e.g., a laptop, desktop computer, tablet computer, etc.) to use services provided by ASP 108. In the illustrated embodiment, user 101 uses a web browser running on device 202 to access the services.

[0043] In this embodiment, user 101 downloads authenticator app 226 and installs it on UE 102. User 101 then accesses the desired service using device 202. For example, user 101 uses device 202 to access a web page provided by ASP 108 and enters the user's credentials in a conventional manner.

[0044] After the user's credentials are verified by ASP 108, ASP 108 initiates the second stage of 2FA. That is, in this example, ASP 108 sends an authentication request to aggregator 112. The request includes a phone number associated with the user's credentials (e.g., stored in a user profile associated with the user's user ID). For example, when a user signs up for a service provided by ASP 108, the user is asked to provide a cellular phone number. The request may also include a user consent message (e.g., "Are you using a web browser on a device located at Falls Church VA to access the service? Yes or No?").

[0045] In response to receiving the request from ASP 108, aggregator 112 sends a message to app 226. The message to app 226 includes a phone number and a user consent message.

[0046] In response to receiving the message from aggregator 112, app 226 displays a user consent message to the user of device 202 (which may be user 101 or another user (e.g., spouse of user 101)) and waits for user input. If the user input indicates that the user of the device does not object to allowing user 101 to access the service (e.g., the user selected the "yes" option), app 226 triggers app 124 to obtain a token and provides the token to app 226. For example, app 226 can utilize an OS application programming interface (API) to request a token from app 124.

[0047] App 124 then sends a request message to ECS 106 via network 114 requesting ECS ​​106 to generate a token. ECS 106 generates the token, stores the token in association with the phone number associated with app 124 (e.g., the request message from app 124 includes information (e.g., SUCI) that enables ECS to obtain the phone number associated with app 124), and then provides the generated token to app 124.

[0048] After app 124 obtains the token from ECS 106, app 124 provides the token to app 226. App 226 then sends the token to aggregator 112 along with the phone number that app 226 received in the request from aggregator 112.

[0049] Aggregator 112 selects an ECS (in this case, ECS 106) based on the phone number and then sends a verification request including the token and the phone number to ECS 106. The ECS then sends a verification request as described above with reference to Figure 1 The illustrated embodiment verifies the received token as described.

[0050] If the received token is determined to be valid, ECS 106 sends a positive acknowledgement (ACK) to aggregator 112 to indicate that the token is valid, otherwise a negative ACK (NACK) is sent to indicate an invalid token. Aggregator 112 sends an ACK or NACK to ASP 108 to indicate whether the token is valid. When ASP 108 obtains an ACK, ASP 108 determines that user 101 has been successfully authenticated (i.e., ASP 108 determines that the user of device 102 does not object to user 101 accessing the service). In this way, ASP provides 2FA that is transparent to user 101.

[0051] Additional details

[0052] Figure 3 Additional details of a system according to some embodiments are shown.

[0053] like Figure 3As shown, the local app 124 (also referred to as the "authority client") resides in the OS 340 of the UE 102, and uses the ICC 122 of the UE to perform authentication for the ECS 106 periodically or as needed (for example, triggered by the Auth App 226 or the third-party App 126), wherein what is stored on the ICC is a subscription identifier (SUI) (for example, a subscription permanent identifier (SUPI), which in some embodiments can be the international user identity (IMSI) of the subscriber assigned to the CSP by the CSP). If the authentication is successful, the ECS 106 generates an "authentication token" (also referred to as "authToken") that is bound to the SUI (for example, associated with a phone number associated with the SUI), and also generates a "fast authentication token" and returns these tokens to the app 124. In some embodiments, the fast authentication token is generated according to RFC 4187.

[0054] Since the authentication using ICC 122 performed between app 124 and ECS 106 is a mature mutual authentication algorithm that does not require any user intervention, and the CSP that distributes the SUI maintains the association between the SUI (e.g., IMSI) stored in the ICC 122 and the phone number bound to the SUI in its core network, the token (authToken) generated by the ECS is linked to the phone number in a secure manner, which can be used by a third-party app 126 or a dedicated auth app 226 to verify the authentication token.

[0055] Whenever App 126 or App 226 needs to perform phone number verification as 2FA for a service, App 126 / 226 can obtain a token from the API exposed by the OS. To enhance security and support multiple simultaneous authentication sessions, App 126 / 226 can also give OTP to App 124, where OTP is used as an authentication session identifier.

[0056] When requesting an auth token, once the app 126 / 226 obtains the auth token and optionally the OTP from the OS, the app 126 / 226 triggers a request for authentication to a server (eg, server 308 of ASP 108, AF 398 of aggregator 112, or ECS 106).

[0057] In one embodiment, if AS 308 obtains a verification request, it contacts an application function (AF) 398 of aggregator 112, which routes the request to the correct ECS for verification, in this case ECS 106. AF 398 determines the address of the correct ECS based on the phone number (e.g., the IP address or domain name of the ECS). That is, using the phone number, AF 398 determines the CSP to which the phone number belongs, and then finds the address of the ECS belonging to the determined CSP based on the configuration information stored for the determined CSP. After AF 398 identifies the ECS, the final verification request is invoked via gateway 399 (e.g., service capability exposure function (SCEF) or network exposure function (NEF)) in accordance with 3GPP Technical Specification (TS) 29.522 V17.6.0 ("TS 29.522").

[0058] Figure 4 is a message flow diagram illustrating the flow of messages according to one embodiment.

[0059] 401: app 126 begins the second stage of the 2FA process by requesting an authToken from app 124. For example, in one embodiment, when user 101 opens app 126, app 126 can authenticate user 101 (e.g., user facial recognition or fingerprint or username / password, etc.), and after app 126 has authenticated the user, app 126 can begin the second stage of 2FA.

[0060] Optionally, an OTP may be introduced. Thus, in some embodiments, when requesting an authToken, app 126 obtains the OTP and provides the OTP to app 124.

[0061] 402: app 124 performs ICC-based authentication with ECS 106. In this example, app 124 performs ICC-based fast authentication (which means that app 124 has previously performed ICC-based full authentication). As is known in the art, after app 124 performs the full authentication process, app 124 obtains a fast authentication token (e.g., a fast authentication token according to the fast reauthentication mechanism / method of RFC 4187) from the ECS, which enables app 124 to subsequently perform fast reauthentication until the fast authorization token expires.

[0062] More specifically, in this step, app 124 sends an authentication request message to ECS 106 including a quick authentication token that app 124 previously obtained from ECS after performing full authentication with ECS (again, if OTP was provided in step 401, OTP is included in the authentication request message). In addition to including the quick authentication token (and OTP, if any), the authentication request message also includes a hidden subscriber identifier (CSUI) (e.g., 5G subscription hidden identifier (SUCI), which is an encrypted version of SUPI). If the quick authentication token is not presented, invalid or expired, ECS needs to perform full authentication based on the credentials stored on ICC 122 and in the CSP core network. The authentication algorithm can be, but is not limited to, EAP-SIM, EAP-AKA, 5G-AKA, EAP-AKA', EAP-TLS (EAP Transport Layer Security), etc.

[0063] In some embodiments, before app 124 performs ICC-based authentication in response to a trigger from app 126 (or after but before providing authToken to app 126), app 124 displays a user consent message on the display of device 102 and waits for user input. The user consent message can say, for example, "Someone tried to use this device to access '[service name]'." Is it you? Yes or no? If the answer is no, the process ends, otherwise app 124 continues. In this embodiment, when app 126 triggers app 124 to obtain a token, app 126 can provide a string containing the service name to app 124.

[0064] 403: The ECS generates an authToken and links the authToken to a telephone number (PN) (e.g., an MSISDN) (and also to an OTP, if an OTP is included), where the PN is determined from information included in the authentication request message. For example, using the SUCI included in the authentication request message, the ECS can obtain the IMSI from the SUCI (e.g., decrypt the SUCI), and then use the IMSI to obtain subscription information associated with the IMSI, which includes the telephone number (thus, the telephone number is bound to the IMSI). A time-to-live value (TTL) is also assigned to the authToken (the TTL indicates the time at which the authToken expires) and is stored with the authToken and the telephone number (and OTP, if present). For example, after generating the authToken, the ECS links the authToken to the PN and TTL (and OTP, if present) by, for example, storing a record in a database having a key field containing the PN or IMSI, a token field storing the authToken, a TTL field storing the TTL value, and an OTP field (if needed) storing the OTP (if any). In some embodiments, the authToken is simply a random number or string generated by the ECS. If an OTP is included, the OTP can be used to generate a random number.

[0065] In some embodiments, the authentication request message is transmitted from app 124 to ECS 106 in one or more IP protocol data units (PDUs) (also referred to as IP packets). In such embodiments, the ECS can extract the source IP address from one IP packet and link the authToken to the extracted IP address. For example, the ECS 106 can store a record in a database having a key field containing the PN or IMSI, a token field storing the authToken, a TTL field storing the TTL value, an IP address field storing the extracted IP address, and an OTP field storing the OTP (if any) (if needed).

[0066] 404: ECS returns the ICC-based authentication result (for example, a quick authentication token) and authToken.

[0067] 405: App 124 returns authToken to App 126.

[0068] 406: App 126 sends a token verification request message including authToken and the user ID (uid) of the user (and OTP, if present) to AS 308. In some embodiments, the verification request message is transmitted from app 126 to AS 308 in one or more IP packets. In such embodiments, AS 306 can extract the source IP address from one IP packet.

[0069] 407: AS uses the user ID to obtain the phone number associated with the user ID. For example, whenever a user creates an account so that the user can use a service, the user provides the account with a phone number of a device with an ICC storing a SUI (e.g., IMSI), the phone number is bound to the SUI (e.g., the CSP's database binds the phone number to the IMSI stored on the ICC), and the phone number is stored in the user's profile, which can be accessed by knowing the user's user ID.

[0070] 408: In the example shown, an aggregator is used, which means that AS 308 does not communicate directly with ECS 106, but communicates with ECS 106 indirectly via AF 398. Therefore, in this embodiment, AS 308 sends a verification request to AF 398, which includes the authToken and the phone number obtained in step 407 (and OTP, if OTP is used for added security). In some embodiments, the verification request sent by AS 308 also includes the IP address extracted by AS 308 from the IP packet used to transmit the verification request message sent by App 126.

[0071] If no aggregator is used, then AS 308 will send only a verification request to ECS 106 .

[0072] 409 : AF 398 routes the authentication request to the correct CSP's ECS for authentication based on the phone number (or based on the phone number and IP address included in the authentication request sent by AS 308 ). For most CSP's deployments, the authentication request is sent via GW 399 .

[0073] 410 and 411: After receiving the verification request, the ECS determines whether the authToken included in the verification request is valid based on the PN (and OTP (if OTP is being used) and / or IP address (if IP address is included in the verification request)) included in the verification request. That is, for example, as previously described, the ECS 106 uses the phone number (or phone number and OTP, if OTP is included) included in the verification request to retrieve a previously generated authToken (if any) associated with the phone number and OTP (if included). If no such previously generated authToken exists, the received authToken is invalid. If such a previously generated authToken does exist, the ECS determines whether the previously generated authToken has expired (e.g., based on the TTL stored in association with the previously generated authToken). In an embodiment where the authToken is linked to an IP address, the ECS 106 determines whether the IP address linked to the authToken matches the IP address (if any) included in the verification request. If such a previously generated authToken exists and has not expired, and the IP address matches, the ECS determines whether the received authToken is the same as the previously generated authToken. If so, the received authToken is valid, otherwise it is invalid.

[0074] 412 : If the authToken is valid, the ECS 106 sends an ACK to the AF 398 (ie, a message indication that the ECS 106 has determined that the authToken is valid), otherwise, the ECS 106 sends a NACK to the AF 398 .

[0075] 413: AF 398 forwards the ACK / NACK to AS 308. If no aggregator is used, ECS 106 will send an ACK / NACK to AS 308. If an ACK is received, this indicates to the AS that the device the user is using to access the service is an "authorized device." That is, the device has the ICC to which the phone number obtained in step 407 is bound (i.e., the ICC stores the SUI (e.g., SUPI) to which the phone number is bound).

[0076] 414: AS 308 sends an authorization result message to app 126, indicating whether user 101 is authorized.

[0077] Figure 5 is a message flow diagram illustrating the message flow according to an embodiment in which a user accesses a service provided by ASP 108 via device 202 .

[0078] 501: Device 202 sends a message to AS 308 to indicate that CSP phone number-based authentication is required. The message includes a user id (e.g., the user id that user 101 entered into device 101 to gain access to the service). The application server then determines the phone number based on the user id.

[0079] 502: In the case where an aggregator is deployed, as in the example shown, the application server contacts the application function (AF) of the aggregator, providing a message including a phone number and a user consent message to request silent authentication. If an aggregator is not used, the AS selects an ECS based on the phone number and sends a message to the selected ECS.

[0080] 503: AF notifies app 226 (which may be owned by an aggregator) to start the silent authentication process, providing a "getAuthToken" message containing a phone number and a user consent message to app 226. In the case where a deployment aggregator is not used, this message is sent by ECS 106 to app 226. App 226 is awakened by the getAuthToken message and displays a user consent message to the user of device 102 (which may be user 101 or another user (e.g., spouse of user 101)), and waits for user input.

[0081] 504: If the user input indicates that the user of the device does not object to allowing user 101 to access the service (e.g., the user selects the "Yes" option), app 226 triggers app 124 to obtain an authToken and provides the authToken to app 226. For example, app 226 can utilize an OS API to request an authToken from app 124. In this step, app 226 can provide an OTP to app 124 as described above.

[0082] 505: app 124 performs ICC-based authentication for ECS106. In this example, app 124 performs fast authentication. More specifically, in this step, app 124 sends an authentication request message to ECS106 including a fast authentication token, which app 124 previously obtained from ECS after performing full authentication with ECS (in addition, if OTP is provided, the OTP is included in the authentication request message). In addition to including the fast authentication token (and OTP, if any), the authentication request message also includes a hidden subscriber identifier (e.g., a 5G subscription hidden identifier). As described above, if the fast authentication token is not presented, invalid or expired, the ECS needs to perform full authentication based on the credentials stored on ICC 122 and in the CSP core network. The authentication algorithm can be, but is not limited to, EAP-SIM, EAP-AKA, 5G-AKA, EAP-AKA', etc.

[0083] 506: The ECS generates an authToken, which is then linked to the telephone number (PN) (e.g., MSISDN) determined from the information included in the authentication request message (and also to the OTP, if an OTP is included). A TTL is also assigned to the authToken and stored with the authToken and telephone number. In addition, as described above with respect to Figure 4 As described in step 403, in some embodiments, the ECS may extract a source IP address from an IP packet used to transmit the authentication request message, and link the authToken with the extracted IP address.

[0084] 507: ECS returns the ICC-based authentication result and authToken.

[0085] 508: app 124 returns authToken to app 226.

[0086] 509: app 226 sends an authToken verification request message to AF 398, which includes the authToken and phone number (and OTP, if present) received from AF 398. If no aggregator is used, the verification request message will be sent by app 226 to ECS 106, thereby bypassing aggregator 112.

[0087] 510: AF 398 routes the verification request to the correct CSP's ECS for verification based on the phone number. For most CSP deployments, the request is sent via GW 399. In some embodiments, the verification request message is transmitted from app 226 to AF 398 in one or more IP packets. In such embodiments, AS 306 can extract the source IP address from one IP packet and add the extracted IP address to the verification request message sent by AF 398 to the ECS.

[0088] 511: After receiving the verification request, the ECS determines whether the authToken included in the verification request is valid. That is, the ECS executes steps 410 and 411 above.

[0089] 512 : If the authToken is valid, the ECS 106 sends an ACK to the AF 398 , otherwise, the ECS 106 sends a NACK to the AF 398 .

[0090] 513: AF 398 forwards the ACK / NACK to AS 308. If no aggregator is used, ECS 106 will send an ACK / NACK to AS 308. If an ACK is received, this indicates to the AS that the device on which app 226 is running is an "authorized device." That is, as an example, the device has a USIM to which the phone number obtained in step 501 is bound.

[0091] AS 308 may then send an authorization result message to device 202 indicating whether user 101 has been authenticated.

[0092] As described above, if the app 124 does not have a valid quick authentication token, it will need to perform a full authentication process. Figure 6 is a message flow illustrating a complete authentication process based on ICC according to an embodiment. More specifically, Figure 6 The EAP-AKA authentication process is shown for illustrative purposes only and not limiting.

[0093] 601: app 124 triggers EAP-AKA authentication (ie, sends an authentication request message including the IMSI stored in ICC 122).

[0094] 602: ECS sends a diameter-based DER request to AAA to start EAP-AKA authentication.

[0095] 603: AAA sends a diameter-based MAR request to HSS / UDM to retrieve the authentication vector based on the IMSI of UE 102 (IMSI is obtained from SUCI).

[0096] 604: HSS / UDM returns authentication credentials to AAA in a diameter-based MAA response for EAP-AKA authentication.

[0097] 605: AAA generates an EAP-AKA challenge payload and returns it to the ECS in a diameter-based DEA response.

[0098] 606 : ECS returns an EAP-AKA challenge to app 124 .

[0099] 607: app 124 contacts the app (eg, USIM) on ICC 122 to authenticate the challenge from the network, calculates an EAP-AKA challenge response for authentication, and sends it back to the ECS.

[0100] 608: ECS forwards the EAP-AKA challenge response from app 124 to AAA via another diameter-based DER request.

[0101] 609: AAA verifies the EAP-AKA challenge response to determine whether the authentication succeeds or fails, and returns the result to the ECS.

[0102] 610 : ECS generates a quick authentication token for the next authentication, and ECS also generates an authToken for silent 2FA, and returns the result to app 124 .

[0103] Fig.16 1601. The message flow diagram of an embodiment of App 126 using authToken to obtain resources. For example, if App 126 possesses a valid authToken, App 126 will be authorized to obtain resources. In the example shown below, App 126 obtains resources from Core Network Function (CNF) 1602 via Open Function (EF) 1699 (e.g., 3GPP Network Open Function (NEF) or Service Capability Open Function (SCEF)). The message flow may start from step 1601.

[0104] 1601: App 126 obtains authToken using the process described above. That is, step 1601 includes steps 401 to 405.

[0105] 1602: After obtaining the authToken, App 126 uses the authToken to try to obtain resources from the CF. For example, in step 1602, App 126 sends a get request message to AS 308, which includes the user ID (uid) of the user, the authToken, and a resource identifier (e.g., a uniform resource identifier) ​​identifying the desired resource.

[0106] 1603: The AS uses the user ID to obtain the telephone number associated with the user ID. This step corresponds to step 407.

[0107] 1604: In the example shown, an aggregator is used, which means that AS 308 does not communicate directly with EF 1699, but communicates with EF 1699 indirectly via AF 398. Therefore, in this embodiment, AS 308 sends a get request to AF 398, which includes the authToken, the phone number obtained in step 1603, and the resource identifier (and OTP, if OTP is used for added security). In some embodiments, the get request sent by AS 308 also includes the source IP address (i.e., the IP address of the device on which app 126 is running) extracted by AS 308 from the IP packet used to transmit the get request message sent by app 126.

[0108] 1605: AF 398 routes the Get Request to the correct CSP's EF based on the phone number (or based on the phone number and IP address included in the Verification Request sent by AS 308). For most CSP's deployments, the Get Request is sent via GW 399.

[0109] 1606: Then, EF 1699 sends a verification request message including authToken and phone number to ECS 106. After receiving the verification request, ECS determines whether the authToken included in the verification request is valid. That is, ECS performs steps 410 and 411 described above. If authToken is valid, ECS 106 sends ACK to EF 1699, otherwise, ECS 106 sends NACK to EF 1699.

[0110] 1607 : If EF 1699 receives ACK from ECS, EF 1699 sends a Get Request message including the resource identifier to CNF 1602 , otherwise, EF 1699 will send NACK to AF 398 , which will then send NACK to AS 308 .

[0111] 1608: In response to receiving the get request message sent by EF 1699, CNF 1602 uses the resource identifier to obtain the resource (for example, CNF can use the resource identifier to retrieve the resource (for example, a file) from the file system or call a process to generate the resource), and then after obtaining the resource, CNF 1602 sends a response message including the resource to EF 1699.

[0112] 1609: EF 1699 then sends a response message including the resources to AF 398.

[0113] 1610: AF 398 forwards the response message to AS 308. In an embodiment where AF is not used, AS 308 will receive the response message sent by EF 1699.

[0114] 1611: AS 308 forwards the response message including the resource to App 126. In this way, App 126 uses the authToken to obtain the resource from the core network function within the core network of the mobile network operator.

[0115] Fig.14 1400 is a block diagram of an apparatus 1400 according to some embodiments. The apparatus 1400 may be used to implement any server disclosed herein (e.g., application server, ECS, remote server, etc.) and any function disclosed herein (e.g., EF, AF, CNF, etc.). When the apparatus 1400 implements EF 1699, the apparatus 1400 may be referred to as EF apparatus 1401. Fig.14As shown, the device 1400 may include: a processing circuit (PC) 1402, which may include one or more processors (P) 1455 (e.g., one or more general-purpose microprocessors and / or one or more other processors, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), etc.), which may be co-located in a single housing or in a single data center, or may be geographically distributed (i.e., the device 1400 may be a distributed computing device); at least one network interface 1448 (e.g., a physical interface or an air interface), which includes a transmitter (Tx) 1445 and a receiver. (Rx) 1447 for enabling the apparatus 1400 to send and receive data to and from other nodes connected to a network 110 (e.g., an Internet Protocol (IP) network) to which the network interface 1448 is (physically or wirelessly) connected (e.g., the network interface 1448 may be coupled to an antenna arrangement including one or more antennas, the antenna arrangement being used to enable the apparatus 1400 to wirelessly send / receive data); and a storage unit (also referred to as a "data storage system") 1408, which may include one or more non-volatile storage devices and / or one or more volatile storage devices. In embodiments where the PC 1402 includes a programmable processor, a computer readable storage medium (CRSM) 1442 may be provided. The CRSM 1442 may store a computer program (CP) 1443 including computer readable instructions (CRI) 1444. The CRSM 1442 may be a non-transitory computer readable medium, such as a magnetic medium (e.g., a hard disk), an optical medium, a memory device (e.g., a random access memory, a flash memory), or the like. In some embodiments, the CRI 1444 of the computer program 1443 is configured such that when executed by the PC 1402, the CRI causes the device 1400 to perform the steps described herein (e.g., the steps described herein with reference to the flowcharts). In other embodiments, the device 1400 may be configured to perform the steps described herein without requiring code. That is, for example, the PC 1402 may consist solely of one or more ASICs. Thus, the features of the embodiments described herein may be implemented in hardware and / or software.

[0116] Fig.15 is a block diagram of a UE 102 according to some embodiments. Fig.15As shown, UE 102 may include: processing circuit (PC) 1502, which may include one or more processors (P) 1555 (e.g., one or more general-purpose microprocessors and / or one or more other processors, such as application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), etc.); communication circuit 1548, which is coupled to an antenna arrangement 1549 including one or more antennas, and includes a transmitter (Tx) 1545 and a receiver (Rx) 1547 for enabling UE 102 to send data and receive data (e.g., wirelessly send / receive data); and a storage unit (also referred to as a "data storage system") 1508, which may include one or more non-volatile storage devices and / or one or more volatile storage devices. In an embodiment where PC 1502 includes a programmable processor, a computer-readable storage medium (CRSM) 1542 may be provided. CRSM 1542 may store a computer program (CP) 1543 including computer-readable instructions (CRI) 1544. CRSM 1542 may be a non-transitory computer-readable medium, such as a magnetic medium (e.g., a hard disk), an optical medium, a memory device (e.g., a random access memory, a flash memory), etc. In some embodiments, CRI 1544 of computer program 1543 is configured such that when executed by PC 1502, CRI causes UE 102 to perform the steps described herein (e.g., the steps described herein with reference to the flowcharts). In other embodiments, UE 102 may be configured to perform the steps described herein without requiring code. That is, for example, PC 1502 may consist of only one or more ASICs. Therefore, the features of the embodiments described herein may be implemented in hardware and / or software.

[0117] Overview of Various Embodiments

[0118] A1. A method for determining whether to allow a user to access a service 700 (see Figure 7), the method utilizes a first device (e.g., UE 102) running a first app and a second app, wherein the first app is a third-party app used by a user to access a service or a non-third-party app (e.g., an aggregator app or a CSP app) for enabling a user to access a service using a second device separate from the first device. The method includes: the second app receives an indication that the first app has requested an authentication token (step s702); after or before receiving the indication, the second app obtains a first authorization token authToken from an authority configuration server ECS (step s704); and after receiving the indication, the second app provides authToken to the first app (step s706). The step of obtaining authToken includes the second app performing a first authentication process or a second authentication process. The first authentication process includes: sending a request message including an unexpired second authentication token (e.g., a fast authentication token, for example, according to a fast reauthentication included in an EAP-AKA mechanism) to an authority configuration server ECS, for enabling the ECS to determine that the second app has been previously authenticated using a universal subscriber identity module (USIM) (e.g., according to EAP-AKA, 5G AKA, EAP-TLS, or EAP-AKA'); and receiving a response message in response to the request message, the response message including authToken. The second authentication process includes: sending a request message including a hidden subscription identifier (e.g., a 5G subscription hidden identifier (SUCI)) to the ECS; after sending the request message, receiving a challenge message from the ECS; generating a challenge response RES using a key stored in an ICC or tamper-proof identification module (e.g., a USIM of a UICC) in the first device; sending a challenge response message in response to the challenge message, the challenge response message including RES; and after sending the challenge response message, receiving a response message in response to the request message, the response message including authToken and an indication that the second app has been successfully authenticated.

[0119] B1. A method 800 for determining whether a device that a user is using to obtain access to a service is an authorized device (e.g., a device that includes a USIM or SIM profile bound to a phone number registered with the service by a subscriber of the service) (see Figure 8), the service is provided by a service provider associated with an application server, and the method is performed by a first app running on a device. Method 800 includes: the first app obtains an authorization token authToken from a second app running on the device (step s802); the first app sends a request message including authToken to the application server, and the authentication request message further includes an identifier and / or a phone number associated with the user (step s804) (the request message may be a get request message also including a resource identifier); and the first app receives a response message from the application server in response to the request message, wherein the response message indicates whether the device is an authorized device, or the response message includes a resource requested by the first app (126) (step s806).

[0120] C 1. A method 900 for determining whether a device that a user is using to obtain access to a service is an authorized device (see Fig. 9 ), the service is provided by a service provider associated with an application server, and the method is performed by the application server. Method 900 includes: receiving an authentication request message from a first app running on a device, the authentication request message including an authToken obtained by the first app from a second app running on the device (step s902); after receiving the authentication request message, providing the authToken and the phone number to the ECS (step s904); receiving an indication that the ECS has determined that the authToken is linked to the provided phone number (step s906); and after receiving the indication that the ECS has determined that the authToken is linked to the provided phone number, sending an authentication response message in response to the authentication request message to the first app, wherein the authentication response message indicates that the device is an authorized device (step s908).

[0121] C2. In some embodiments, providing the authToken and the telephone number to the ECS includes: sending a message including the authToken and the telephone number to the ECS, or sending a first message including the authToken and the telephone number to an application function of the aggregator, wherein the AF is configured to send a second message including the authToken and the telephone number to the ECS.

[0122] D1. A method 1000 for determining whether to allow a user of a first device to access a service (see Fig.10), the method is performed by the second device. Method 1000 includes: receiving a first authentication request message, the first authentication request message including a phone number and a message for a user of the second device (step s1002); after receiving the first authentication request: displaying the message to the user of the second device, and after displaying the message, receiving an indication indicating whether the user of the second device approves to allow the user of the first device to access the service (step s1004); and if the indication indicates that the user of the second device approves to allow the user of the first device to access the service, sending a second authentication request message to a remote server (e.g., aggregator AF or ECS), the second authentication request message including: an authentication token authToken and a phone number (step s1006).

[0123] D2. In some embodiments, the user of the first device and the user of the second device are the same person.

[0124] E1. A method for determining whether to allow a user of a first device to access a service 1100 (see Fig.11 ), the method is performed by an application server associated with the service. Method 1100 includes: the application server receives a message from a first device, the message including information indicating that a user of the first device wants to obtain access to the service (step s1102); after receiving the message from the first device, the application server sends an authentication request message including a phone number to a second server (e.g., an AF or ECS of an aggregator) (step s1104); and after sending the authentication request message, the application server receives an authentication response message in response to the authentication request message, wherein the authentication response message indicates that a user of the second device associated with the phone number has authorized a user of the first device to access the service (step s1106).

[0125] F1. A method for determining whether to allow a user of a first device to access a service 1200 (see Fig.12), the method is performed by a remote server (AF or ECS of the aggregator) remote from the first device. Method 1200 includes: the remote server receives a first message including a phone number from an application server associated with the service (step s1202); after receiving the first message, the remote server sends a second message to a first app running on a second device associated with the phone number, the second message including the phone number (step s1204); after sending the second message to the first app, receiving a third message including an authentication token and a phone number from the first app (step s1206); in response to receiving the third message, determining whether the authorization token is valid (step s1208); and if it is determined that the authorization token is valid, the remote server sends a response message in response to the first message to the application server, wherein the response message indicates that the second device is an authorized device and the user of the second device does not object to the user of the first device accessing the service (step s1210).

[0126] F2. In some embodiments, determining whether the authorization token is valid includes: sending a verification message including the authorization token and the phone number to the ECS; and receiving a response to the verification message from the ECS, wherein the response indicates whether the authorization token is valid.

[0127] F3. In some embodiments, determining whether the authorization token is valid includes: using the phone number to retrieve a previously generated token; and comparing the previously generated token to the authentication token.

[0128] G1. A method 1300 executed by an authority configuration server ECS (see Fig.13 ). The method includes: receiving a verification request message including a first authorization token authToken and a phone number (step s1302); retrieving a second authToken, wherein the retrieval includes retrieving the second authToken using the phone number (step s1304); determining whether the first authToken is valid, wherein the determination includes determining whether the first authToken is the same as the second authToken (step s1306); and sending a verification response message in response to the verification request message, wherein the verification response message indicates whether the first authToken is valid (step s1308).

[0129] G2. In some embodiments, the verification request message also includes a code (e.g., a one-time pass code), and retrieving the second authToken includes retrieving the second authToken using the phone number and the code.

[0130] G3. In some embodiments, the method further includes: generating a second authToken before receiving the verification request message; and storing the second authToken so that the second authToken is associated with the phone number.

[0131] G4. In some embodiments, the second authToken is stored such that the second authToken is associated with both the phone number and the code.

[0132] G5. In some embodiments, determining whether the first authToken is valid further includes: determining whether the second authToken has expired; determining whether the second authToken has been revoked; and / or determining that a subscription identifier associated with the second authToken is associated with a phone number.

[0133] G6. In some embodiments, the method further includes: after determining whether the first authToken is valid, revoking the second authToken (e.g., deleting it from the authToken database).

[0134] H1. A computer program (1443) comprising instructions (1444) which, when executed by a processing circuit (1402) of a device, cause the device to perform a method as described in any one of embodiments C1, C2, E1, F1-F3 or G1-G6.

[0135] H2. A computer program (1543) comprising instructions (1544) which, when executed by a processing circuit (1502) of a UE, cause the UE to perform a method according to any one of claims A1, B1, D1 or D2.

[0136] H3. A carrier containing a computer program according to claim H1 or H2, wherein the carrier is one of an electrical signal, an optical signal, a radio signal and a computer-readable storage medium (1442, 1542).

[0137] I1. A method 1700 performed by EF 1699 (see Fig.17). The method includes: receiving a first acquisition request message including a resource identifier, a telephone number and an authToken (step s1702). The method also includes: in response to receiving the first acquisition request message, sending a verification request message including the authToken and the telephone number to the ECS (step s1704). The method also includes: receiving a confirmation message indicating that the authToken is valid from the ECS (step s1706). The method also includes: in response to receiving the confirmation message, sending a second acquisition request message including the resource identifier to CNF 1602 (step s1708). The method also includes: after sending the second acquisition request message, receiving a first response message in response to the second acquisition request message from the CNF, the response message including the resource obtained by the CNF using the resource identifier (step s1710). The method also includes: after receiving the first response message, sending a second response message in response to the first acquisition request message, the second response message including the resource (step s1712).

[0138] Although various embodiments are described herein, it should be understood that they are presented by way of example only and not limitation. Therefore, the breadth and scope of the present disclosure should not be limited by any of the above exemplary embodiments. In addition, unless otherwise specified herein or clearly contradictory to the context, otherwise, the present disclosure encompasses any combination of the above elements in all possible variations thereof.

[0139] As used herein, sending a message "to" or "towards" an intended recipient includes sending the message directly to the intended recipient or sending the message indirectly to the intended recipient (i.e., one or more other nodes are used to relay the message from the source node to the intended recipient). Similarly, as used herein, receiving a message "from" a sender includes receiving the message directly from the sender or indirectly from the sender (i.e., one or more nodes are used to relay the message from the sender to the receiving node). In addition, as used herein, "a" means "at least one" or "one or more."

[0140] In addition, although the processes described above and shown in the accompanying drawings are shown as a sequence of steps, this is for illustrative purposes only. Therefore, it is expected that some steps can be added, some steps can be omitted, the order of the steps can be rearranged, and some steps can be performed in parallel.

Claims

1. A method (700) for determining whether to allow a user (101) to access a service, the method utilizing a first device (102) running a first application app (126, 226) and a second app (124), wherein: The first app is a third-party app used by the user to access the service, or is a non-third-party app for enabling the user to access the service using a second device (202) separate from the first device, the method comprising: The second app receives (s702) an indication that the first app has requested an authentication token; After or before receiving the instruction, the second app obtains (s704) a first authorization token authToken from the ECS (106); and After receiving the indication, the second app provides (s706) the authToken to the first app, wherein: Obtaining the authToken includes: the second app causes the first device to perform a first authentication process or a second authentication process, The first authentication process includes: Sending a request message including a non-expired second authentication token to an authority configuration server ECS, so as to enable the ECS to determine that the second app has been previously authenticated; and receiving a response message in response to the request message, the response message including the authToken; and the second authentication process includes: Sending a request message including a hidden subscription identifier to the ECS; After sending the request message, receiving a challenge message from the ECS; Generate a challenge response RES using a key stored in i) an integrated circuit card ICC in the first device and / or ii) a tamper-resistant identification module; sending a challenge response message in response to the challenge message, the challenge response message including the RES; and After sending the challenge response message, receiving a response message in response to the request message, the response message including the authToken and an indication that the second app has been successfully authenticated.

2. A method (800) for determining whether a device (102) being used by a user to obtain access to a service is an authorized device, the service being provided by a service provider associated with an application server (308), the method being performed by a first app (126) running on the device, and the method comprising: The first app obtains (s802) an authorization token authToken from a second app (124) running on the device; The first app sends (s804) a request message including the authToken to the application server, the request message further including an identifier and / or a phone number associated with the user; and The first app receives (s806) a response message in response to the request message from the application server, wherein: The response message indicates whether the device is an authorized device, or The response message includes the resource requested by the first app (126).

3. A method (900) for determining whether a device (102) being used by a user (101) to obtain access to a service is an authorized device, the service being provided by a service provider associated with an application server (308), the method being performed by the application server, and comprising: receiving (s902) an authentication request message from a first app (126) running on the device, the authentication request message comprising an authToken obtained by the first app from a second app (124) running on the device; After receiving the authentication request message, providing (s904) the authToken and the phone number to the ECS (106); receiving (s906) an indication that the ECS has determined that the authToken is linked to the provided phone number; as well as After receiving the indication that the ECS has determined that the authToken is linked to the provided phone number, sending (s908) an authentication response message in response to the authentication request message to the first app, wherein the authentication response message indicates that the device is an authorized device.

4. The method according to claim 3, wherein: Providing the authToken and the phone number to the ECS includes: Send a message including the authToken and the phone number to the ECS, or A first message including the authToken and the phone number is sent to an application function of the aggregator, wherein the AF is configured to send a second message including the authToken and the phone number to the ECS.

5. A method (1000) for determining whether a user (101) of a first device (202) is allowed to access a service, the method being performed by a second device (102), and the method comprising: receiving (s1002) a first authentication request message, the first authentication request message comprising a telephone number and a message for a user of the second device; After receiving the first authentication request: displaying (s1004) the message to the user of the second device; as well as After displaying the message, receiving (s1004) an indication indicating whether the user of the second device approves allowing the user of the first device to access the service; as well as If the indication indicates that the user of the second device approves allowing the user of the first device to access the service, a second authentication request message is sent (s1006) to a remote server (398, 106), the second authentication request message comprising: an authentication token authToken and the phone number.

6. The method according to claim 5, wherein: The user of the first device and the user of the second device are the same person.

7. A method (1100) for determining whether a user (101) of a first device (202) is allowed to access a service, the method being performed by an application server (308) associated with the service, and comprising: The application server receives (s1102) a message from the first device, the message comprising information indicating that the user of the first device wants to obtain access to the service; After receiving the message from the first device, the application server sends (s1104) an authentication request message including a telephone number to a second server (398, 106); as well as After sending the authentication request message, the application server receives (s1106) an authentication response message in response to the authentication request message, wherein the authentication response message indicates that a user of a second device (102) associated with the phone number has authorized the user of the first device to access the service.

8. A method (1200) for determining whether a user (101) of a first device (202) is allowed to access a service, the method being performed by a remote server (398, 106) remote from the first device, and comprising: The remote server receives (s1202) a first message including a telephone number from an application server (308) associated with the service; After receiving the first message, the remote server sends (s1204) a second message to a first app (226) running on a second device (102) associated with the phone number, the second message including the phone number; After sending the second message to the first app, receiving (s1206) a third message including an authentication token and the phone number from the first app; In response to receiving the third message, determining (s1208) whether the authorization token is valid; as well as If it is determined that the authorization token is valid, the remote server sends (s1210) a response message in response to the first message to the application server, wherein the response message indicates that the second device is an authorized device and the user of the second device does not object to the user of the first device accessing the service.

9. The method according to claim 8, wherein: Determining whether the authorization token is valid includes: sending a verification message including the authorization token and the phone number to the ECS (106); and A response to the validation message is received from the ECS, wherein the response indicates whether the authentication token is valid.

10. The method according to claim 8, wherein: Determining whether the authorization token is valid includes: using the phone number to retrieve a previously generated token; and The previously generated token is compared to the authentication token.

11. A method (1300) performed by an ECS (106), the method comprising: receiving (s1302) a verification request message including a first authorization token authToken and a telephone number; retrieving (s1304) a second authToken, wherein the retrieving comprises retrieving the second authToken using the phone number; determining (s1306) whether the first authToken is valid, wherein the determining comprises determining whether the first authToken is the same as the second authToken; and A verification response message is sent (s1308) in response to the verification request message, wherein the verification response message indicates whether the first authToken is valid.

12. The method according to claim 11, wherein: The verification request message also includes a code, and Retrieving the second authToken includes retrieving the second authToken using the phone number and the code.

13. The method according to claim 11 or 12, further comprising: Before receiving the verification request message, generating the second authToken; as well as The second authToken is stored such that the second authToken is associated with the phone number.

14. A method according to claim 13 as appended to claim 12, wherein: The second authToken is stored such that the second authToken is associated with both the phone number and the code.

15. The method according to any one of claims 11 to 14, wherein: Determining whether the first authToken is valid further comprises: Determine whether the second authToken has expired; determining whether the second authToken has been revoked; and / or A determination is made that a subscription identifier associated with the second authToken is associated with the telephone number.

16. The method according to any one of claims 11 to 15, further comprising: After determining whether the first authToken is valid, revoking the second authToken.

17. A computer program (1443) comprising instructions (1444) which, when executed by processing circuitry (1402) of an apparatus (1400), causes the apparatus to perform a method according to any one of claims 3, 4, 7 or 8 to 16.

18. A computer program (1543) comprising instructions (1544) which, when executed by a processing circuit (1502) of a UE (102), cause the UE to perform a method according to any one of claims 1, 2, 4 or 5.

19. A carrier comprising a computer program according to claim 17 or 18, wherein: The carrier is one of an electronic signal, an optical signal, a radio signal, and a computer-readable storage medium (1442, 1542).

20. A first device (102), comprising: a memory (1542) storing a first application app (126, 226) and a second app (124), wherein the first app is a third party app used by a user to access a service, or a non-third party app for enabling the user to access the service using a second device (202) separate from the first device; and A processing circuit (1502) is configured to run the first app and the second app, wherein the second app, when run by the processing circuit, causes the first device to perform a method (700) for determining whether to allow the user to access a service, the method comprising: receiving (s702) an indication that the first app has requested an authentication token; After or before receiving the instruction, obtaining (s704) a first authorization token authToken from the ECS (106); and After receiving the indication, providing (s706) the authToken to the first app, wherein: Obtaining the authToken includes performing a first authentication process or a second authentication process, The first authentication process includes: Sending a request message including a non-expired second authentication token to an authority configuration server ECS, so as to enable the ECS to determine that the second app has been previously authenticated; and receiving a response message in response to the request message, the response message including the authToken; and the second authentication process includes: Sending a request message including a hidden subscription identifier to the ECS; After sending the request message, receiving a challenge message from the ECS; generating a challenge response RES using a key stored in i) an integrated circuit card (ICC) in the first device and / or ii) a tamper-resistant identification module; sending a challenge response message in response to the challenge message, the challenge response message including the RES; and After sending the challenge response message, receiving a response message in response to the request message, the response message including the authToken and an indication that the second app has been successfully authenticated.

21. A first device (102), comprising: a memory (1542) storing a first application app (126) and a second app (124), wherein the first app enables a user to access a service; and A processing circuit (1502) is configured to run the first app and the second app, wherein the first app, when run by the processing circuit, causes the first device to perform a method (800), the method comprising: Obtain (s802) authorization token authToken; sending (s804) a request message including the authToken to an application server, the request message also including an identifier and / or a telephone number associated with the user; and receiving (s806) a response message in response to the request message from the application server, wherein: The response message indicates whether the first device is an authorized device, or The response message includes the resource requested by the first app (126).

22. An application server (308) for determining whether a device (102) being used by a user (101) to obtain access to a service is an authorized device, the application server being configured to: receiving (s902) an authentication request message from a first application app (126) running on the device, the authentication request message including an authToken obtained by the first app from a second app (124) running on the device; After receiving the authentication request message, providing (s904) the authToken and the phone number to the ECS (106); receiving (s906) an indication that the ECS has determined that the authToken is linked to the provided phone number; as well as After receiving the indication that the ECS has determined that the authToken is linked to the provided phone number, sending (s908) an authentication response message in response to the authentication request message to the first app, wherein the authentication response message indicates that the device is an authorized device.

23. The application server according to claim 22, wherein: Providing the authToken and the phone number to the ECS includes: Send a message including the authToken and the phone number to the ECS, or A first message including the authToken and the phone number is sent to an application function of the aggregator, wherein the AF is configured to send a second message including the authToken and the phone number to the ECS.

24. A first device (102), comprising: A memory (1542) storing a first application app (226) and a second application (124); as well as A processing circuit (1502) is configured to run the first app and the second app, wherein the first app, when run by the processing circuit, causes the first device to perform a method (1000) for determining whether to allow a user (101) of a second device (202) to access a service, the method comprising: receiving (s1002) a first authentication request message, the first authentication request message comprising a telephone number and a message for a user of the first device; After receiving the first authentication request: displaying (s1004) the message to the user of the first device; and After displaying the message, receiving (s1004) an indication indicating whether the user of the first device approves allowing the user of the second device to access the service; and If the indication indicates that the user of the first device approves allowing the user of the second device to access the service, a second authentication request message is sent (s1006) to a remote server (398, 106), wherein the second authentication request message includes: an authentication token authToken obtained from the second app, and the phone number.

25. An application server (308) for determining whether to allow a user (101) of a first device (202) to access a service, the application server being configured to: receiving (s1102) from said first device a message comprising information indicating that said user of said first device wants to obtain access to said service; After receiving the message from the first device, sending (s1104) an authentication request message including a telephone number to a second server (398, 106); and After sending the authentication request message, receiving (s1106) an authentication response message in response to the authentication request message, wherein: The authentication response message indicates that a user of a second device (102) associated with the phone number has authorized the user of the first device to access the service.

26. A server (398, 106) for determining whether to allow a user (101) of a first device (202) to access a service, the server being configured to: receiving (s1202) a first message including a telephone number from an application server (308) associated with the service; After receiving the first message, sending (s1204) a second message to a first app (226) running on a second device (102) associated with the phone number, the second message including the phone number; After sending the second message to the first app, receiving (s1206) a third message including an authentication token and the phone number from the first app; In response to receiving the third message, determining (s1208) whether the authorization token is valid; as well as If it is determined that the authorization token is valid, a response message in response to the first message is sent (s1210) to the application server, wherein the response message indicates that the second device is an authorized device and the user of the second device does not object to the user of the first device accessing the service.

27. The server according to claim 26, wherein: Determining whether the authorization token is valid includes: sending a verification message including the authorization token and the phone number to the ECS (106); and A response to the validation message is received from the ECS, wherein the response indicates whether the authentication token is valid.

28. The server according to claim 26, wherein: Determining whether the authorization token is valid includes: using the phone number to retrieve a previously generated token; and The previously generated token is compared to the authentication token.

29. An authority configuration server ECS (106), configured to: receiving (s1302) a verification request message including a first authorization token authToken and a telephone number; Retrieve (s1304) a second authToken, where The retrieving includes retrieving the second authToken using the phone number; determining (s1306) whether the first authToken is valid, wherein the determining comprises determining whether the first authToken is the same as the second authToken; and A verification response message is sent (s1308) in response to the verification request message, wherein the verification response message indicates whether the first authToken is valid.

30. The ECS of claim 29, wherein: The verification request message also includes a code, and Retrieving the second authToken includes retrieving the second authToken using the phone number and the code.

31. The ECS of claim 29 or 30, further configured to: Before receiving the verification request message, generating the second authToken; and The second authToken is stored such that the second authToken is associated with the phone number.

32. An ECS according to claim 31 as appended to claim 30, wherein: The second authToken is stored such that the second authToken is associated with both the phone number and the code.

33. An ECS according to any one of claims 29 to 32, wherein: The ECS determines whether the first authToken is valid by executing a process, the process comprising: Determine whether the second authToken has expired; determining whether the second authToken has been revoked; and / or A determination is made that a subscription identifier associated with the second authToken is associated with the telephone number.

34. The ECS according to any one of claims 29 to 33, further configured to: revoke the second authToken after determining whether the first authToken is valid.

35. A method performed by an open function device (1401), the method comprising: Receive a first acquisition request message, wherein the first acquisition request message includes a resource identifier, a telephone number, and an authorization token authToken; In response to receiving the first acquisition request message, sending a verification request message including the authToken and the telephone number to an authority configuration server ECS (106); receiving a confirmation message from the ECS indicating that the authToken is valid; In response to receiving the confirmation message, sending a second acquisition request message including the resource identifier to the core network function CNF (1602); After sending the second acquisition request message, receiving a first response message in response to the second acquisition request message from the CNF, the response message including the resource obtained by the CNF using the resource identifier; as well as After receiving the first response message, a second response message is sent in response to the first acquisition request message, wherein the second response message includes the resource.

36. An open function EF device (1401), the EF device being configured to perform a process comprising: Receive a first acquisition request message, wherein the first acquisition request message includes a resource identifier, a telephone number, and an authorization token authToken; In response to receiving the first acquisition request message, sending a verification request message including the authToken and the telephone number to an authority configuration server ECS (106); receiving a confirmation message from the ECS indicating that the authToken is valid; In response to receiving the confirmation message, sending a second acquisition request message including the resource identifier to the core network function CNF (1602); After sending the second acquisition request message, receiving a first response message in response to the second acquisition request message from the CNF, the response message including the resource obtained by the CNF using the resource identifier; as well as After receiving the first response message, a second response message is sent in response to the first acquisition request message, wherein the second response message includes the resource.

Images