WO2021032912A1 - Service d'autorisation basé sur plmn - Google Patents

Service d'autorisation basé sur plmn Download PDF

Info

Publication number
WO2021032912A1
WO2021032912A1 PCT/FI2020/050534 FI2020050534W WO2021032912A1 WO 2021032912 A1 WO2021032912 A1 WO 2021032912A1 FI 2020050534 W FI2020050534 W FI 2020050534W WO 2021032912 A1 WO2021032912 A1 WO 2021032912A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
response
access token
terminal device
application
Prior art date
Application number
PCT/FI2020/050534
Other languages
English (en)
Inventor
Nagendra Bykampadi
Jos GEORGE
Jeyaraj CHELLAPANDI
Arun MATHEW
Original Assignee
Nokia Technologies Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Technologies Oy filed Critical Nokia Technologies Oy
Publication of WO2021032912A1 publication Critical patent/WO2021032912A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Definitions

  • Embodiments of the present disclosure generally relate to the field of telecommunication, and in particular, to methods, apparatuses and computer readable storage media for authorizing access.
  • the 5G core network (5GC) is designed to be extremely secure. For devices registered to the 5GC, secure communications among them will be facilitated. It would be desired that this inbuilt security features could be reused by an external application connected to the 5GC to obtain authorization from the 5GC (in terms of access tokens) to access terminal devices registered to the 5GC. It would be also desired that this inbuilt security features could be reused by a terminal device registered to the 5GC (in terms of access tokens) to access applications that are using the 5GC.
  • Access tokens from the 5GC can provide an additional mechanism for scoping permissions of the applications or terminal devices. By using access tokens, unauthorized access that may have adverse effects on other entities connected to the 5GC can be prevented. Therefore, it would be desired that the 5GC can provide a service for generating an access token upon request from an application or a terminal device and providing the generated access token to the application or the terminal device securely. However, there is no such service in the 5GC currently.
  • example embodiments of the present disclosure provide methods, apparatuses and computer readable storage media for authorizing access.
  • an apparatus comprising at least one processor; and at least one memory including computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the apparatus to transmit, from an application to an authorization server, a first request for a first access token to be used by the application to access a terminal device; in response to the first request being determined as valid by the authorization server, receive a first response to the first request from the authorization server, the first response comprising the first access token and information about the first access token; transmit, based on the information and to the terminal device, a second request for accessing the terminal device, the second request comprising the first access token; and receive a second response to the second request from the terminal device.
  • an apparatus comprising at least one processor; and at least one memory including computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the apparatus to receive, at an authorization server and from an application, a first request for a first access token to be used by the application to access a terminal device; verify validity of the first request; in response to the first request being valid, generate the first access token and information about the first access token; and transmit, to the application, a first response to the first request, the first response comprising the first access token and the information about the first access token.
  • an apparatus comprising at least one processor; and at least one memory including computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the apparatus to receive, at a terminal device and from an application, a second request for accessing the terminal device, the second request comprising a first access token for accessing the terminal device; verify validity of the first access token; and transmit, to the application, a second response to the second request based on a result of the verification.
  • an apparatus comprising at least one processor; and at least one memory including computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the apparatus to transmit, from a terminal device to an authorization server, a fourth request for a second access token to be used by the terminal device to access an application; in response to the fourth request being determined as valid by the authorization server, receive a fourth response to the fourth request from the authorization server, the fourth response comprising the second access token and information about the second access token; transmit, based on the information and to the application, a fifth request for accessing the application, the fifth request comprising the second access token; and receive a fifth response to the fifth request from the application.
  • an apparatus comprising at least one processor; and at least one memory including computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the apparatus to receive, at an authorization server and from a terminal device, a fourth request for a second access token to be used by the terminal device to access an application; verify validity of the fourth request; in response to the fourth request being valid, generate the second access token and information about the second access token; and transmit, to the terminal device, a fourth response to the fourth request, the fourth response comprising the second access token and the information about the second access token.
  • an apparatus comprising at least one processor; and at least one memory including computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the apparatus to receive, at an application and from a terminal device, a fifth request for accessing the application, the fifth request comprising a second access token for accessing the application; verify validity of the second access token; and transmit, to the terminal device, a fifth response to the fifth request based on a result of the verification.
  • a method comprises transmitting, from an application to an authorization server, a first request for a first access token to be used by the application to access a terminal device; in response to the first request being determined as valid by the authorization server, receiving a first response to the first request from the authorization server, the first response comprising the first access token and information about the first access token; transmitting, based on the information and to the terminal device, a second request for accessing the terminal device, the second request comprising the first access token; and receiving a second response to the second request from the terminal device.
  • a method comprises receiving, at an authorization server and from an application, a first request for a first access token to be used by the application to access a terminal device; verifying validity of the first request; in response to the first request being valid, generating the first access token and information about the first access token; and transmitting, to the application, a first response to the first request, the first response comprising the first access token and the information about the first access token.
  • a method comprises receiving, at a terminal device and from an application, a second request for accessing the terminal device, the second request comprising a first access token for accessing the terminal device; verifying validity of the first access token; and transmitting, to the application, a second response to the second request based on a result of the verification.
  • a method comprises transmitting, from a terminal device to an authorization server, a fourth request for a second access token to be used by the terminal device to access an application; in response to the fourth request being determined as valid by the authorization server, receiving a fourth response to the fourth request from the authorization server, the fourth response comprising the second access token and information about the second access token; transmitting, based on the information and to the application, a fifth request for accessing the application, the fifth request comprising the second access token; and receiving a fifth response to the fifth request from the application.
  • a method comprises receiving, at an authorization server and from a terminal device, a fourth request for a second access token to be used by the terminal device to access an application; verifying validity of the fourth request; in response to the fourth request being valid, generating the second access token and information about the second access token; and transmitting, to the terminal device, a fourth response to the fourth request, the fourth response comprising the second access token and the information about the second access token.
  • a method comprises receiving, at an application and from a terminal device, a fifth request for accessing the application, the fifth request comprising a second access token for accessing the application; verifying validity of the second access token; and transmitting, to the terminal device, a fifth response to the fifth request based on a result of the verification.
  • an apparatus comprises means for transmitting, from an application to an authorization server, a first request for a first access token to be used by the application to access a terminal device; means for in response to the first request being determined as valid by the authorization server, receiving a first response to the first request from the authorization server, the first response comprising the first access token and information about the first access token; means for transmitting, based on the information and to the terminal device, a second request for accessing the terminal device, the second request comprising the first access token; and means for receiving a second response to the second request from the terminal device.
  • an apparatus comprises means for receiving, at an authorization server and from an application, a first request for a first access token to be used by the application to access a terminal device; means for verifying validity of the first request; means for in response to the first request being valid, generating the first access token and information about the first access token; and means for transmitting, to the application, a first response to the first request, the first response comprising the first access token and the information about the first access token.
  • an apparatus comprises means for receiving, at a terminal device and from an application, a second request for accessing the terminal device, the second request comprising a first access token for accessing the terminal device; means for verifying validity of the first access token; and means for transmitting, to the application, a second response to the second request based on a result of the verification.
  • an apparatus comprising means for transmitting, from a terminal device to an authorization server, a fourth request for a second access token to be used by the terminal device to access an application; means for in response to the fourth request being determined as valid by the authorization server, receiving a fourth response to the fourth request from the authorization server, the fourth response comprising the second access token and information about the second access token; means for transmitting, based on the information and to the application, a fifth request for accessing the application, the fifth request comprising the second access token; and means for receiving a fifth response to the fifth request from the application.
  • an apparatus comprising means for receiving, at an authorization server and from a terminal device, a fourth request for a second access token to be used by the terminal device to access an application; means for verifying validity of the fourth request; means for in response to the fourth request being valid, generating the second access token and information about the second access token; and means for transmitting, to the terminal device, a fourth response to the fourth request, the fourth response comprising the second access token and the information about the second access token.
  • an apparatus comprising means for receiving, at an application and from a terminal device, a fifth request for accessing the application, the fifth request comprising a second access token for accessing the application; means for verifying validity of the second access token; and means for transmitting, to the terminal device, a fifth response to the fifth request based on a result of the verification.
  • a computer readable storage medium comprising program instructions stored thereon. The instructions, when executed by an apparatus, cause the apparatus to perform the method according to any of the seventh to twelfth aspects.
  • FIG. 1 illustrates a block diagram of an example environment according to some example embodiments of the present disclosure
  • FIG. 2 is a diagram illustrating an application registering to an authorization server according to some example embodiments of the present disclosure
  • FIG. 3A illustrates an interaction diagram of an example process for authorizing an application to access a terminal device according to some example embodiments of the present disclosure
  • Fig. 3B illustrates an interaction diagram of an example process for an application to access a terminal device by presenting an access token according to some example embodiments of the present disclosure
  • Fig. 3C illustrates an interaction diagram of an example process for verifying an access token by means of an authorization server generating the access token according to some example embodiments of the present disclosure
  • FIG. 4A illustrates an interaction diagram of an example process for authorizing a terminal device to access an application according to some example embodiments of the present disclosure
  • Fig. 4B illustrates an interaction diagram of an example process for authorizing a terminal device to access an application according to some example embodiments of the present disclosure
  • Fig. 4C illustrates an interaction diagram of an example process for a terminal device to access an application by presenting an access token according to some example embodiments of the present disclosure
  • Fig. 4D is a diagram illustrating an authorization server providing a token verification service to an application according to some example embodiments of the present disclosure
  • FIG. 4E illustrates an interaction diagram of an example process for verifying an access token by means of an authorization server generating the access token according to some example embodiments of the present disclosure
  • FIG. 5 shows a flowchart of an example method according to some example embodiments of the present disclosure
  • FIG. 6 shows a flowchart of an example method according to some example embodiments of the present disclosure
  • Fig. 7 shows a flowchart of an example method according to some example embodiments of the present disclosure
  • Fig. 8 shows a flowchart of an example method according to some example embodiments of the present disclosure
  • FIG. 9 shows a flowchart of an example method according to some example embodiments of the present disclosure.
  • Fig. 10 shows a flowchart of an example method according to some example embodiments of the present disclosure
  • Fig. 11 illustrates a simplified block diagram of an apparatus that is suitable for implementing embodiments of the present disclosure
  • Fig. 12 illustrates a block diagram of an example computer readable medium in accordance with some example embodiments of the present disclosure.
  • Fig. 12 illustrates a block diagram of an example computer readable medium in accordance with some example embodiments of the present disclosure.
  • references in the present disclosure to “one embodiment,” “an embodiment,” “an example embodiment,” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an example embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
  • first and second etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and/or” includes any and all combinations of one or more of the listed terms.
  • circuitry may refer to one or more or all of the following:
  • circuit(s) and or processor(s) such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.
  • software e.g., firmware
  • circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware.
  • circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.
  • the term “communication network” refers to a network following any suitable communication standards, such as Long Term Evolution (LTE), LTE -Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), High-Speed Packet Access (HSPA), Narrow Band Internet of Things (NB-IoT), New Radio (NR) and so on.
  • LTE Long Term Evolution
  • LTE-A LTE -Advanced
  • WCDMA Wideband Code Division Multiple Access
  • HSPA High-Speed Packet Access
  • NB-IoT Narrow Band Internet of Things
  • NR New Radio
  • the communications between a terminal device and a network device in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (1G), the second generation (2G), 2.5G, 2.75G, the third generation (3G), the fourth generation (4G), 4.5G, the future fifth generation (5G) communication protocols, and/or any other protocols either currently known or to be developed in the future.
  • Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system.
  • the 5G network As described above, using the 5G network, not only more humans are getting connected for their private and/or public uses, but also machines, robots, cars and/or devices will used the 5G network for their critical communications. To meet all of the requirements, the 5GC is designed to be extremely secure. For devices registered to the 5GC, secure communications among them will be facilitated. It would be desired that this inbuilt security features could be reused by an external application connected to the 5GC to obtain authorization from the 5GC (in terms of access tokens) to access terminal devices registered to the 5GC. It would be also desired that this inbuilt security features could be reused by a terminal device registered to the 5GC (in terms of access tokens) to access applications that are using the 5GC.
  • Access tokens from the 5GC can provide an additional mechanism for scoping permissions of the applications or terminal devices. By using access tokens, unauthorized access that may have adverse effects on other entities connected to the 5GC can be prevented. Therefore, it would be desired that the 5GC can provide a service for generating an access token upon request from an application or a terminal device and providing the generated access token to the application or the terminal device securely. However, there is no such service in the 5GC at present.
  • OAuth 2.0 authorization framework has been proposed to enable a third- party application to obtain limited access to a web service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the web service, or by allowing the third-party application to obtain access on its own behalf.
  • the client may request access to resources controlled by a resource owner and hosted by a resource server and may be issued a different set of credentials from those of the resource owner. Instead of using the credentials of the resource owner to access protected resources, the client may obtain an access token, that is, a string denoting a specific scope, lifetime, and other access attributes.
  • the access token may be issued to the client by an authorization server with the approval of the resource owner.
  • the client may use the access token to access the protected resources hosted by the resource server.
  • the 5GC comprises a lot of network entities, which provide different network functions.
  • the Network Function (NF) Repository Function (NRF) is the network entity in the 5GC which maintains NF profiles and available NF instances. It also provides service registration and discovery function so that NFs can discover each other.
  • the NRF can provide an OAuth 2.0 authorization service to other NFs. It exposes a "Token Endpoint", where a NF service consumer can request an access token to access a NF service producer.
  • the NRF may act as the OAuth 2.0 authorization server, the NF service consumer may act as the OAuth 2.0 client and the NF service producer may act as the OAuth 2.0 resource server.
  • Examples of the NF service consumer may include, but not limited to, Access and Mobility Management Function (AMF), Session Management Function (SMF), Policy Control Function (PCF), Network Exposure Function (NEF), Network Slice Selection Function (NSSF), Short Message Service Function (SMSF) and Authentication Server Function (AUSF).
  • AMF Access and Mobility Management Function
  • SMF Session Management Function
  • PCF Policy Control Function
  • NEF Network Exposure Function
  • NSSF Network Slice Selection Function
  • SMSF Short Message Service Function
  • AUSF Authentication Server Function
  • NFs securely expose capabilities and events to third-party Application Functions (AFs) via the NEF.
  • the NEF also enables secure provision of information on authenticated and authorized AFs.
  • the NEF shall authorize requests from AFs using the OAuth-based authorization mechanism.
  • the NRF that is, the authorization server
  • the NRF is configured to grant an AF (which is the client of the NRF) to access northbound Application Programming Interfaces (APIs) of the NEF.
  • APIs Application Programming Interfaces
  • the Unified Data Repository provides unified data management services to other NFs, such as, AMF, SMF, SMSF, NEF, Gateway Mobile Focation Center (GMFC) and AUSF via the UDM service based interfaces (also referred to as “Nudm interfaces” in the following).
  • the UDM can provide a subscriber data management service, a UE context management service, a UE authentication service, an event exposure service, a parameter provision service and a Non-IP Data Delivery (NIDD) authorization service via the Nudm interfaces.
  • NIDD Non-IP Data Delivery
  • an external application connected to the 5GC can obtain an access token from the 5GC to access a terminal device registered to the 5GC.
  • a terminal device connected to the 5GC can obtain an access token from the 5GC to access an application connected to the 5GC.
  • this solution enables verification of an access tokens by means of the authorization server which generates the access token.
  • Embodiments of the present disclosure can enable the ability to generate access tokens by the 5GC. This will enhance the functionality of the 5GC to perform third-party authorization. This will also create opportunities for government bodies to monitor activities of applications or devices using inbuilt 5GC functionalities like lawful interception gateway.
  • Another advantage with respect to the 5GC doing authorization on behalf of a terminal device is that the terminal device does not need to know authentication credentials of the application. In the event of change in login details of the application, there is no need for the terminal device to reconfigure them in the terminal device, since the 5GC will do authorization on behalf of the terminal device.
  • another advantage with respect to the 5GC doing authorization on behalf of a third-party application is that the third-party application needs not change the authentication credentials in the case of change in device credentials.
  • Access tokens from the 5GC can provide an additional mechanism for scoping permissions of applications or devices. By using access tokens, unauthorized access that may have adverse effects on other entities connected to the 5GC can be prevented, thereby improving security during communications.
  • Fig. 1 illustrates a block diagram of an environment 100 according to some example embodiments of the present disclosure.
  • the environment 100 may include an application 110, a terminal device 120 and an authorization server 130.
  • the structure of the environment 100 is shown only for purpose of illustration, without suggesting any limitation to the scope of the present disclosure. Embodiments of the present disclosure may also be applied to an environment with a different structure.
  • the terminal device 120 may refer to any end device that is capable of wireless communication.
  • the terminal device 120 may also be referred to as a communication device, user equipment (UE), a Subscriber Station (SS), a Portable Subscriber Station, a Mobile Station (MS), or an Access Terminal (AT).
  • UE user equipment
  • SS Subscriber Station
  • MS Mobile Station
  • AT Access Terminal
  • the terminal device 120 may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA), portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), USB dongles, smart devices, wireless customer-premises equipment (CPE), an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like.
  • VoIP voice
  • terminal device 120 is shown in Fig. 1 as a vehicle, it is to be understood that embodiments of the present disclosure are also applicable to other terminal devices than vehicles, such as mobile phones, sensors or so on.
  • terminal device communication device
  • terminal user equipment
  • UE user equipment
  • the application 110 can be any type of application, which may be deployed on any physical computer, server or virtual machine.
  • the application 110 may be a Land Mobile Network (PLMN) registered third-party AF.
  • PLMN Land Mobile Network
  • the authorization server 130 can be implemented in a single device or across a plurality of devices.
  • the authorization server 130 can be implemented as a new NF.
  • the authorization server 130 can be implemented as a standalone NF or co-located with another NF in the 5GC, as will be described in the following.
  • the authorization server 130 can provide an authorization service to the terminal device 120 and/or the application 110.
  • the authorization server 130 can generate an access token for accessing the terminal device 120 and share it with the application 110 per request from the application 110.
  • the authorization server 130 can also generate an access tokens for accessing the application 110 and share it with the terminal device 120 per request from the terminal device 120.
  • the authorization server 130 can also provide a verification service to the terminal device 120 and/or the application 110.
  • the authorization server 130 can verify validity of an access token per request from the terminal device 120 and/or the application 110.
  • the application 110 may request, from the authorization server 130, an access token (also referred to as “first access token” in the following) for accessing the terminal device 120.
  • an access token also referred to as “first access token” in the following
  • the application 110 may request access to the terminal device 120 using the first access token.
  • the terminal device 120 may verify validity of the first access token by itself or by means of the authorization server 130.
  • the terminal device 120 may serve the request from the application 110. Otherwise, the terminal device 120 may discard the request the request from the application 110.
  • the terminal device 120 may request, from the authorization server 130, an access token (also referred to as “second access token” in the following) for accessing the application 110.
  • an access token also referred to as “second access token” in the following
  • the terminal device 120 may request access to the application 110 using the second access token.
  • the application 110 may verify validity of the second access token by itself or by means of the authorization server 130.
  • the application 110 may serve the request from the terminal device 120. Otherwise, the application 110 may discard the request the request from the terminal device 120.
  • the NEF within the 5GC may expose new OAuth based APIs for the application 110 to invoke when it needs an access token.
  • the APIs exposed by the NEF may comprise at least APIs for the application 110 to register with the authorization server 130 and APIs for the application 110 to request an access token from the authorization server 130.
  • the application 110 may register to the authorization server 130 securely using RESTful APIs via the NEF.
  • Fig. 2 is a diagram illustrating an application registering to an authorization server via the NEF according to some example embodiments of the present disclosure.
  • Fig. 2 shows the application 110, the NEF 210 and the authorization server 130.
  • the NEF 210 may provide API(s) 201 to be invoked by the application 110.
  • the NEF 210 may also comprise a plug-in 202, which can implement OAuth related functionality.
  • the application 110 may send a registration request to the NEF 210 by invoking the API(s) 201.
  • the registration request may arrive at the plug-in 202 in the NEF 210.
  • the plug-in 202 may forward the registration request to the authorization server 130 on behalf of the application 110.
  • the authorization server 130 may allocate a client identifier (ID) and a client secret for the application 110 and transmit a registration response including the client ID and the client secret to the plug-in 202 located in the NEF 210.
  • the NEF 210 will in turn provide the registration response to the application 110 on behalf of the authorization server 130 securely.
  • the authorization server 130 may be implemented as a NF co-located with the NRF. That is, the NRF in the 5GC may be enhanced to support generation of the access token for accessing the terminal device connected to the 5GC and provision of the access token to the application via the NEF. To achieve this, the authorization server 130 co-located with the NRF may interact with the UDM via Nudm service based interfaces. For example, the NRF (the authorization server 130) may subscribe to Event Exposure Service in the UDM to get notified when a terminal device is registered to the UDM or when the terminal device is deregistered from the UDM.
  • the authorization server 130 will be authorized to generate an access token for accessing the terminal device and share it with an application (such as, the application 110) per request from the application.
  • an application such as, the application 110
  • the authorization server 130 may be implemented as a NF co-located with the UDM. That is, the UDM in the 5GC may be enhanced to incorporate the functionality of the authorization server 130. If a terminal device (such as, the terminal device 120) is registered to the UDM, the authorization server 130 in the UDM can service an authorization request from an application (such as, the application 110) via the NEF.
  • an application such as, the application 110
  • Fig. 3 A illustrates an interaction diagram of an example process 310 for authorizing an application to access a terminal device according to some example embodiments of the present disclosure.
  • the process 310 may involve the application 110 and the authorization server 130 as shown in Fig. 1.
  • the process 310 may also involve the NEF 210 as shown in Fig. 2 and a UDM 301.
  • the application 110 registered to the 5GC is trying to do a software update to the terminal device 120 (for example, a car using the 5G network) connected to the 5G network.
  • the application 110 may receive a software update request for the terminal device 120 from an application server (not shown in Fig. 3 A) connected to the application 110.
  • the application 110 may then initiate a request for an access token to the authorization server 130.
  • the application 110 may register to the authorization server 130 securely using RESTful APIs via the NEF 210, as shown by 311 in Fig. 3A and as described above with reference to Fig. 2.
  • the application 110 may transmit 312, to the NEF 210, a request (also referred to as “first request”) for a first access token to be used by the application 110 to access the terminal device 120.
  • the NEF 210 (such as, the plug-in 202) may receive the first request from the application 110 and forward 313 the first request to the authorization server 130 on behalf of the application 110.
  • the authorization server 130 may verify 315 validity of the first request. For example, the authorization server 130 may extract, from the first request, the client ID (also referred to as “first identifier” in the following) of the application 110 and determine, based on the first ID, whether the application 110 has been registered to the authorization server 130. The authorization server 130 may also extract an ID of the terminal device 120 for which the first access token is required. For example, the ID of the terminal device 120 can be a Mobile Station International Subscriber Directory Number (MSISDN) or an external ID. The authorization server 130 may obtain device registration information from the UDM 301, as shown by 314 in Fig. 3 A. The authorization server 130 may determine, based on the second ID and the device registration information obtained from the UDM 301 , whether the terminal device 120 has been registered to the UDM 301.
  • MSISDN Mobile Station International Subscriber Directory Number
  • the authorizations server 130 may generate the first access token and information about the first access token, and transmit 316 a first response which includes the first access token and the information about the first access token to the NEF 210.
  • the authorization server 130 may digitally sign the generated first access token based on a shared secret or private key.
  • the first access token may be a JSON Web Token (JWT) and a derivative of long-term secret key K stored in the 5GC Authentication credential Repository and Processing Function (ARPF) can be used to sign the JWT, since the 5GC and the terminal device 120 are sharing the same key. It is to be understood that the terminal device 120 should be able to handle the JWT.
  • JWT JSON Web Token
  • ARPF 5GC Authentication credential Repository and Processing Function
  • the first access token may be an opaque token.
  • the generated information about the first access token may include metadata of the first access token, such as, expiration date, a scope of the token, or so on.
  • the NEF 210 (such as, the plug-in 202) may receive 316 the first response from the authorization server 130 and forward 317 the first response to the application 110 on behalf of the authorization server 130.
  • Fig. 3B illustrates an interaction diagram of an example process 320 for an application to access a terminal device by presenting an access token according to some example embodiments of the present disclosure.
  • the process 320 may be executed subsequent to the process 310.
  • the process 320 may involve the application 110 and the terminal device 120 as shown in Fig. 1.
  • the application 110 may transmit 321, based on the information (such as, the expiration date, the allowed access scope, or so on) and to the terminal device 120, a second request for accessing the terminal device 120.
  • the second request may comprise the first access token received from the authorization server 130.
  • the terminal device 120 may verify 322 validity of the first access token.
  • the first access token may be a self-contained JWT.
  • the terminal device 120 may verify validity of the first access token by itself.
  • the first access token may be an opaque token.
  • the opaque token is a random sequence of alphanumeric characters that contains no inherent meaning.
  • the terminal device 120 may verify validity of the first access token by means of the authorizations server 130, as will be described below with reference to Fig. 3C.
  • the terminal device 120 may transmit 323, to the application 110, a second response to the second request based on a result of the verification.
  • the terminal device 120 in response to the first access token being valid, may transmit the second response to the application 110 for enabling the application 110 to access the terminal device 120.
  • the terminal device 120 in response to the first access token being invalid, may transmit the second response to the application 110 for disabling the application 110 to access the terminal device 120.
  • the authorization server 130 in order to provide a token verification service to the terminal device 120, can be enhanced with a software functionality to determine the active state of an access token and to determine the metadata of the token.
  • the metadata may include, for example, the expiration time of the token (indicating whether the access token is currently active), the scope of the token, or so on.
  • This token verification ability of the authorization server 130 can be used by the terminal device 120 to query, verify and get information about the access token regardless of whether or not the information is carried by the access token itself.
  • Fig. 3C illustrates an interaction diagram of an example process 322 for verifying an access token by means of an authorization server generating the access token according to some example embodiments of the present disclosure.
  • the process 322 can be considered as an example implementation of the action 322 as shown in Fig, 3B.
  • the process 322 may involve the terminal device 120, the authorization server 130 and an AMF 302 within the 5GC.
  • the terminal device 120 may transmit 331, to the AMF 302, a third request for verifying the first access token.
  • the terminal device 120 may have been registered to the 5G network.
  • the terminal device 120 may incorporate the third request into a service request and transmit the service request to Radio Access Network (RAN).
  • the RAN may forward the third request to the AMF 302 in N2 message.
  • the AMF 302 may have a connection to the authorization server 130 and may forward 332 the third request to the authorization server 130.
  • the authorization server 130 may verify 333 validity of the first access token and transmit 334, to the AMF 302, a third response to the third request.
  • the third response may include the metadata of the first access token, such as, the expiration date, the scope of the token, or so on.
  • the AMF 302 may forward 335 the third response to the terminal device 120.
  • the AMF 302 may transmit the third response to the RAN in N2 message.
  • the RAN may incorporate the third response in a service accept message and forward the service accept message to the terminal device 120.
  • the terminal device 120 may verify 336, based on the third response, validity of the first access token.
  • the terminal device 120 may extract, from the second request, first information about the first access token, such as, the date of requested access, the scope of the requested access, or so on.
  • the terminal device 120 may also extract, from the third response, second information about the first access token, such as, the expiration data, the scope of the token, or so on. Then, the terminal device 120 may determine whether the first information matches the second information. In response to the first information matching the second information, the terminal device 120 may determine the first access token as valid. Otherwise, the terminal device 120 may determine the first access token as invalid.
  • embodiments of the present disclosure enable the ability to generate and verify access tokens by the 5GC. This will enhance the functionality of the 5GC to perform third-party authorization. This will also create opportunity for government bodies to monitor activities of a third-party application using inbuilt 5GC functionalities like lawful interception gateway. Another advantage with respect to the 5GC doing authorization on behalf of a third-party application is that the third-party application needs not change the authentication credentials in the case of change in device credentials. Access tokens from the 5GC can provide an additional mechanism for scoping permissions of the terminal device. By using access tokens, unauthorized access that may have adverse effects on other entities connected to the 5GC can be prevented, thereby improving security during communications.
  • the authorization server could be from a company which will then handle authorization of terminal devices of that company and authorization would not be controlled by the network operator.
  • the token verification ability of the authorization server can be used by the terminal device to query, verify and get information about the access token regardless of whether or not the information is carried by the access token itself.
  • the terminal device 120 may also request, from the authorization server 130, a second access token for accessing the application 110.
  • the terminal device 120 may request access to the application 110 using the second access token.
  • the application 110 may verify validity of the second access token by itself or by means of the authorization server 130.
  • the application 110 may serve the request from the terminal device 120. Otherwise, the application 110 may discard the request the request from the terminal device 120.
  • the terminal device 120 may request the second access token from the authorization server 130.
  • the application 110 may be a Land Mobile Network (PLMN) registered third- party AF.
  • PLMN Land Mobile Network
  • the second access token may be generated and included in the registration accept message.
  • the generated access token can be targeted to one or more AFs, as will be described below with reference to Fig. 4A.
  • the AMF may interact with the authorization server 130 using well-defined APIs to obtain the generated access token.
  • Fig. 4A illustrates an interaction diagram of an example process 410 for authorizing a terminal device to access an application according to some example embodiments of the present disclosure.
  • the process 410 may involve the terminal device 120 and the authorization server 130 as shown in Fig. 1.
  • the process 410 may also involve the NEF 210 as shown in Fig. 2, the UDM 301 as shown in Fig. 3A and the AMF 302 as shown in Fig. 3C.
  • the process 410 may also involve an AUSF 401 and a PCF 402 within the 5GC.
  • the terminal device 120 (for example, a car using the 5G network) is trying to report a software bug and ask for software update from the application 110 connected to the 5G network.
  • the terminal device 120 may initiate a request for an access token to the authorization server 130.
  • the terminal device 120 may incorporate a request (also referred to as “fourth request” in the following) for an access token (such as, the second access token) to be used by the terminal device 120 to access one or more applications (such as, the application 110) into a registration request to be transmitted to the AMF 302.
  • the terminal device 120 may incorporate a new parameter for requesting the second access token in its registration request message towards the AMF 302.
  • the terminal device 120 may transmit 411, to the AMF 302, the registration request.
  • identity such as, Subscriber Concealed Identifier (SUCI)
  • SUCI Subscriber Concealed Identifier
  • the AMF 302 may select 415 a UDM 301 and register 416 to the UDM 301.
  • the UDM 301 may notify 417 the authorization server 130 of an event that the terminal device 120 is registered to the UDM 301.
  • the 302 may retrieve 418 the Access and Mobility Subscription data from the UDM 301.
  • the subscription data for the terminal device 120 will include a list of applications (such as, the application 110) for which the terminal device 120 is authorized to get the access token. It is to be understood that, for each terminal device, which has signed up for the PLMN based authorization service, is provisioned with a list of AFs that they are authorized to access in the UDM. The UDM may return this list to the AMF, as shown by 418 in Fig. 4A.
  • the AMF 302 may transmit 420, to the authorization server 130, a request for getting an access token (such as, the second access token) to access the applications (such as, the application 110) to which the terminal device 120 is interested to communicate.
  • the request may include the list of AFs obtained 418 from the UDM 301.
  • the authorization server 130 may optionally verify validity of the request.
  • the authorization server 130 may check whether the terminal device 120 has been authenticated to the network. This can be done based on a notification that the authorization server 130 received 417 from the UDM 301 when the terminal device 120 is authenticated.
  • the authorization server 130 may further check availability of the application 110 based on application registration information obtained 419 from the NEF 210. It is to be understood that, the interaction between the authorization server 130 and the NEF 210 have been described above with reference to Fig. 2.
  • the authorizations server 130 may generate an access token (such as, the second access token) and related information, and transmit a fourth response which includes the second access token and the information about the second access token to the AMF 302, as shown by 420 in Fig. 4A.
  • the authorization server 130 may include the list of AFs (such as, the application 110) in the generated second access token, which determines the scope of access for the terminal device 120.
  • the authorization server 130 may digitally sign the generated second access token based on a shared secret or private key.
  • the second access token may be a JSON Web Token (JWT) and a common shared secret between the application 110 and the 5GC can be used to sign the JWT.
  • JWT JSON Web Token
  • the application 110 should be able to handle the JWT.
  • the second access token may be an opaque token.
  • the generated information about the second access token may include metadata of the second access token, such as, expiration date, a scope of the token, or so on.
  • the AMF 302 may select 421 an associated PCF 402. Then, a procedure of access and mobility policy association may be performed between the AMF 302 and the PCF 402, as shown by 422 in Fig. 4A.
  • the AMF 302 may include the second access token as well as related information as part of a registration accept message and transmit 423 the registration accept message to the terminal device 120.
  • the terminal device 120 gets the second access token, the terminal device 120 can use the second access token to access the application 110 if necessary.
  • the list of AFs in the access token will determine which AFs the terminal device 120 is authorized to access.
  • the terminal device 120 may request the second access token as part of a session establishment procedure.
  • the generated access token can be targeted to one or more AFs.
  • the terminal device 120 may include intended applications in the request, such that the generated access token is targeted to those intended applications.
  • the SMF may interact with the authorization server 130 to obtain the second access token specific to the application 110 and provide it to the terminal device 120.
  • Fig. 4B illustrates an interaction diagram of an example process 430 for authorizing a terminal device to access an application according to some example embodiments of the present disclosure.
  • the process 430 may involve the terminal device 120 and the authorization server 130 as shown in Fig. 1.
  • the process 430 may also involve the NEF 210 as shown in Fig. 2 and the UDM 301 as shown in Fig. 3.
  • the process 410 may also involve the AMF 302, a SMF 403, a UPF 404 an AUSF 401 and a PCF 402 within the 5GC.
  • the terminal device 120 (for example, a car using the 5G network) is trying to report a software bug and ask for software update from the application 110 connected to the 5G network.
  • the terminal device 120 may initiate a request for an access token to the authorization server 130.
  • the terminal device 120 may incorporate a request (also referred to as “fourth request” in the following) for an access token (such as, the second access token) to be used by the terminal device 120 to access one or more applications (such as, the application 110) into a session establishment request to be transmitted to the AMF 302.
  • the terminal device 120 may incorporate a new parameter for the second access token in its Packet Data Unit (PDU) session establishment Non-Access Stratum (NAS) message towards the AMF 302.
  • PDU Packet Data Unit
  • NAS Non-Access Stratum
  • the terminal device 120 may transmit 431, to the AMF 302, the PDU session establishment request.
  • the AMF 302 may select 432 an associated SMF 403.
  • a subsequent session management (SM) context request transmitted from the AMF 302 to the SMF 403 the fourth request to obtain the second access token is forwarded by the AMF 302 to the SMF 403, as shown by 433 in Fig. 4B.
  • the SMF 403 may register subscriber (for example, identity of the terminal device 120 and identity of the PDU session) to the UDM 301 and retrieve the subscription data for the terminal device 120, as shown by 435 in Fig. 4B.
  • the SMF 403 may inform 436 successful creation of SM context for the PDU session to the AMF 302.
  • the SMF 403 may select the Data Network Name (DNN) corresponding to the terminal device which initiates the PDU session. Based on DNN settings in the SMF 403, the SMF 403 may connect with the authorization server 130 to obtain the second access token.
  • DNN Data Network Name
  • the SMF 403 may forward 437 the fourth request for the second access token to the authorization server 130.
  • the authorization server 130 may optionally verify validity of the fourth request. For example, the authorization server 130 may check if the terminal device 120 has been registered with the UDM 301. In addition, the authorization server 130 may also check, based on application registration information obtained 434 from the NEF 210, if the application 110 which the terminal device 120 requests to access has been registered with the NEF 210. It is to be understood that, the interaction between the authorization server 130 and the NEF 210 have been described above with reference to Fig. 2.
  • the authorizations server 130 may generate an access token (such as, the second access token) and related information, and transmit a fourth response which includes the second access token and the information about the second access token to the SMF 403, as shown by 437 in Fig. 4B.
  • the authorization server 130 may include the list of AFs (such as, the application 110) in the generated second access token, which determines the scope of access for the terminal device 120.
  • the authorization server 130 may digitally sign the generated second access token based on a shared secret or private key.
  • the second access token can be a JSON Web Token (JWT) and a common shared secret between the application 110 and the 5GC can be used to sign the JWT.
  • JWT JSON Web Token
  • the application 110 should be able to handle the JWT.
  • the second access token may be an opaque token.
  • the generated information about the second access token may include metadata of the second access token, such as, expiration date, a scope of the token, or so on.
  • the SMF 403 may select 438 an associated PCF 402, and then a procedure of SM policy association may be performed between the AMF 302 and the PCF 402, as shown by 439 in Fig. 4B.
  • the SMF 403 may select 440 an associated UPF 404, and then a procedure of SM policy association modification may be performed between the AMF 302 and the PCF 402, as shown by 441 in Fig. 4B.
  • Configurations may be forwarded from the SMF 403 to the UPF 404, as shown by 442 in Fig. 4B.
  • the SMF 403 is ready to reply back the required information to the terminal device 120.
  • the SMF 403 may forward 443 the second access token and the related information to the AMF 302 in Nl, N2 SM message transfer and the AMF 302 may forward 444 the second access token and the related information to the terminal device 120.
  • the terminal device 120 gets the second access token, the terminal device 120 can use the access token to access the application 110 if necessary.
  • the list of AFs in the access token will determine which AFs the terminal device 120 is authorized to access.
  • Fig. 4C illustrates an interaction diagram of an example process 450 for a terminal device to access an application by presenting an access token according to some example embodiments of the present disclosure.
  • the process 450 may be executed subsequent to the process 410 or 430.
  • the process 450 may involve the application 110 and the terminal device 120 as shown in Fig. 1.
  • the terminal device 120 may transmit 451, based on the information (such as, the expiration date, the allowed access scope, or so on) and to the application 110, a fifth request for access the application 110.
  • the fifth request may comprise the second access token received from the authorization server 130.
  • the application 110 may verify 452 validity of the second access token.
  • the second access token may be a self-contained JWT.
  • the application 110 may verify validity of the second access token by itself.
  • the second access token may be an opaque token.
  • the application 110 may verify validity of the second access token by means of the authorizations server 130, as will be described below with reference to Figs. 4D and 4E.
  • the application 110 may transmit 453, to the terminal device 120, a fifth response to the fifth request based on a result of the verification.
  • the application 110 in response to the second access token being valid, may transmit the fifth response to the terminal device 120 for enabling the terminal device 120 to access the application 110.
  • the application 110 in response to the second access token being invalid, may transmit the fifth response to the terminal device 120 for disabling the terminal device 120 to access the application 110.
  • the authorization server 130 in order to provide a token verification service to the application 110, can be enhanced with a software functionality to determine the active state of an access token and to determine the metadata of the token.
  • the metadata may include, for example, the expiration time of the token (indicating whether the access token is currently active), the scope of the token, or so on.
  • This token verification ability of the authorization server 130 can be used by the application 110 to query, verify and get information about the access token regardless of whether or not the information is carried by the access token itself.
  • new APIs can be introduced in the authorization server 130 that provides the token authorization service.
  • the application 110 may use the new APIs for token verification via the NEF.
  • the NEF also need to be enhanced with equivalent northbound APIs.
  • Fig. 4D is a diagram illustrating an authorization server providing a token verification service to an application via the NEF according to some example embodiments of the present disclosure.
  • Fig. 4D shows the application 110, the NEF 210 and the authorization server 130.
  • the NEF 210 may provide API(s) 203 for providing a token verification service to the application 110.
  • the NEF 210 may also comprise a plug-in 204, which can implement token verification functionality.
  • the application 110 may transmit a sixth request for verifying the second access token to the NEF 210 by invoking the API(s) 203.
  • the sixth request may arrive at the plug-in 204 in the NEF 210.
  • the plug-in 204 may forward the sixth request to the authorization server 130 on behalf of the application 110.
  • the authorization server 130 may verify validity of the second access token and transmit, to the plug-in 204 located in the NEF 210, a sixth response to the sixth request.
  • the sixth response may include the metadata of the second access token, such as, the expiration date, the scope of the token, or so on.
  • the NEF 210 will in turn provide the sixth response to the application 110 on behalf of the authorization server 130 securely.
  • Fig. 4E illustrates an interaction diagram of an example process 452 for verifying an access token by means of an authorization server generating the access token according to some example embodiments of the present disclosure.
  • the process 452 can be considered as an example implementation of the action 452 as shown in Fig. 4C.
  • the process 452 may involve the application 110, the authorization server 130 and the NEF 210 as shown in Fig. 4D.
  • the application 110 may transmit 461 a sixth request for verifying the second access token to the NEF 210.
  • the application 110 may have been registered to the NEF 210.
  • the NEF 210 (such as, the plug-in 204) may receive the sixth request from the application 110 and forward 462 the sixth request to the authorization server 130 on behalf of the application 110.
  • the authorization server 130 may verify 463 validity of the second access token and transmit 464, to the NEF 210, a sixth response to the sixth request.
  • the sixth response may include the metadata of the second access token, such as, the expiration date, the scope of the token, or so on.
  • the NEF 210 may forward 465 the sixth response to the application 110 on behalf of the authorization server 130 securely.
  • the application 110 may verify 466, based on the sixth response, validity of the second access token.
  • the application 110 may extract, from the fifth request, third information about the second access token, such as, the date of requested access, the scope of the requested access, or so on.
  • the application 110 may also extract, from the sixth response, fourth information about the second access token, such as, the expiration data, the scope of the token, or so on. Then, the application 110 may determine whether the third information matches the fourth information. In response to the third information matching the fourth information, the application 110 may determine the second access token as valid. Otherwise, the application 110 may determine the second access token as invalid.
  • embodiments of the present disclosure enable the ability to generate access token by the 5GC. This will enhance the functionality of the 5GC to perform third-party authorization. This will also create opportunity for government bodies to monitor activities of a terminal device using inbuilt 5GC functionalities like lawful interception gateway.
  • Another advantage with respect to the 5GC doing authorization on behalf of a terminal device is that the terminal device does not need to know authentication credentials of the application. In the event of change in login details of the application, there is no need for the terminal device to reconfigure them in the terminal device, since the 5GC will do authorization on behalf of the terminal device. Access tokens from the 5GC can provide an additional mechanism for scoping permissions of the application.
  • the token verification ability of the authorization server can be used by the application to query, verify and get information about the access token regardless of whether or not the information is carried by the access token itself.
  • Fig. 5 shows a flowchart of an example method 500 according to some example embodiments of the present disclosure.
  • the method 500 can be implemented at the application 110 as shown in Fig. 1. It is to be understood that the method 500 may include additional blocks not shown and/or may omit some shown blocks, and the scope of the present disclosure is not limited in this regard.
  • the application 110 transmits, to the authorization server 130, a first request for a first access token to be used by the application 110 to access the terminal device 120.
  • the application 110 receives a first response to the first request from the authorization server 130, the first response comprising the first access token and information about the first access token.
  • the application 110 transmits, based on the information and to the terminal device 120, a second request for accessing the terminal device 120, the second request comprising the first access token.
  • the application 110 receives a second response to the second request from the terminal device 120.
  • transmitting the first request comprises transmitting, via a NEF, the first request to the authorization server 130.
  • receiving the first response comprises receiving, via the NEF, the first response from the authorization server 130.
  • the method 500 further comprises prior to transmitting the first request, registering the application 110 to the authorization server 130 via a NEF.
  • Fig. 6 shows a flowchart of an example method 600 according to some example embodiments of the present disclosure.
  • the method 600 can be implemented at the authorization server 130 as shown in Fig. 1. It is to be understood that the method 600 may include additional blocks not shown and/or may omit some shown blocks, and the scope of the present disclosure is not limited in this regard.
  • the authorization server 130 receives, from the application 110, a first request for a first access token to be used by the application 110 to access the terminal device 120.
  • the authorization server 130 verifies validity of the first request.
  • the authorization server 130 in response to the first request being valid, the authorization server 130 generates the first access token and information about the first access token.
  • the authorization server 130 transmits, to the application 110, a first response to the first request, the first response comprising the first access token and the information about the first access token.
  • receiving the first request comprises receiving, via a NEF, the first request from the application 110.
  • transmitting the first response comprises transmitting, via the NEF, the first response to the application 110.
  • verifying validity of the first request comprises extracting, from the first request, a first identifier of the application 110 and a second identifier of the terminal device 120; determining, based on the first identifier, whether the application 110 has been registered to the authorization server 130; determining, based on the second identifier and device registration information obtained from a UDM, whether the terminal device 120 has been registered to the UDM; in response to determining that the application 110 has been registered to the authorization server 130 and the terminal device 120 has been registered to the UDM, determining the first request as valid; and in response to determining that the application 110 has not been registered to the authorization server 130 or the terminal device 120 has not been registered to the UDM, determining the first request as invalid.
  • the method 600 further comprises receiving, from the terminal device 120, a third request for verifying the first access token; and transmitting, to the terminal device 120, a third response to the third request, the third response comprising the information about the first access token.
  • receiving the third request comprises receiving, via an AMF, the third request from the terminal device 120.
  • transmitting the third response comprises transmitting, via the AMF, the third response to the terminal device 120.
  • Fig. 7 shows a flowchart of an example method 700 according to some example embodiments of the present disclosure.
  • the method 700 can be implemented at the terminal device 120 as shown in Fig. 1. It is to be understood that the method 700 may include additional blocks not shown and/or may omit some shown blocks, and the scope of the present disclosure is not limited in this regard.
  • the terminal device 120 receives, from the application 110, a second request for accessing the terminal device 120, the second request comprising a first access token for accessing the terminal device 120.
  • the terminal device 120 verifies validity of the first access token. [00135] At block 730, the terminal device 120 transmits, to the application 110, a second response to the second request based on a result of the verification.
  • verifying validity of the first access token comprises transmitting, to the authorizations server 130 generating the first access token, a third request for verifying the first access token; receiving, from the authorization server 130, a third response to the third request; and verifying validity of the first access token based on the third response.
  • transmitting the third request comprises incorporating the third request into a service request to be transmitted to an AMF; and transmitting, via RAN, the service request to the AMF, such that the AMF forwards the third request to the authorization server 130.
  • receiving the third response comprises in response to the AMF receiving the third response from the authorization server 130, receiving, via the RAN and from the AMF, a service accept message comprising the third response.
  • verifying validity of the first access token based on the third response comprises extracting, from the second request, first information about the first access token; extracting, from the third response, second information about the first access token; in response to the first information matching the second information, determining the first access token as valid; and in response to the first information not matching the second information, determining the first access token as invalid.
  • transmitting the second response comprises in response to the first access token being valid, transmitting the second response for enabling the application 110 to access the terminal device 120; and in response to the first access token being invalid, transmitting the second response for disabling the application 110 to access the terminal device 120.
  • Fig. 8 shows a flowchart of an example method 800 according to some example embodiments of the present disclosure.
  • the method 800 can be implemented at the terminal device 120 as shown in Fig. 1. It is to be understood that the method 800 may include additional blocks not shown and/or may omit some shown blocks, and the scope of the present disclosure is not limited in this regard.
  • the terminal device 120 transmits, to the authorization server 130, a fourth request for a second access token to be used by the terminal device 120 to access the application 110.
  • the terminal device 120 receives a fourth response to the fourth request from the authorization server 130, the fourth response comprising the second access token and information about the second access token.
  • the terminal device 120 transmits, based on the information and to the application 110, a fifth request for accessing the application 110, the fifth request comprising the second access token.
  • the terminal device 120 receives a fifth response to the fifth request from the application 110.
  • transmitting the fourth request comprises incorporating the fourth request into a registration request to be transmitted to an AMF; and transmitting the registration request to the AMF, such that the AMF registers the terminal device 120 to a UDM and forwards the fourth request to the authorization server 130.
  • receiving the fourth response comprises in response to the AMF receiving the fourth response from the authorization server 130, receiving a registration response to the registration request from the AMF, the registration response comprising the fourth response.
  • transmitting the fourth request comprises incorporating the fourth request into a session establishment request to be transmitted to an AMF; and transmitting the session establishment request to the AMF, such that the AMF forwards the fourth request to the authorization server 130 via a SMF.
  • receiving the fourth response comprises in response to the AMF receiving the fourth response from the authorization server 130 via the SMF, receiving a session establishment response to the session establishment request from the AMF, the session establishment response comprising the fourth response.
  • Fig. 9 shows a flowchart of an example method 900 according to some example embodiments of the present disclosure.
  • the method 900 can be implemented at the authorization server 130 as shown in Fig. 1. It is to be understood that the method 900 may include additional blocks not shown and/or may omit some shown blocks, and the scope of the present disclosure is not limited in this regard.
  • the authorization server 130 receives, from the terminal device 120, a fourth request for a second access token to be used by the terminal device 120 to access the application 110.
  • the authorization server 130 verifies validity of the fourth request.
  • the authorization server 130 in response to the fourth request being valid, the authorization server 130 generates the second access token and information about the second access token.
  • the authorization server 130 transmits, to the terminal device 120, a fourth response to the fourth request, the fourth response comprising the second access token and the information about the second access token.
  • receiving the fourth request comprises receiving, via an AMF, the fourth request from the terminal device 120.
  • transmitting the fourth response comprises transmitting, via the AMF, the fourth response to the terminal device 120.
  • receiving the fourth request comprises receiving, via a SMF, the fourth request from the terminal device 120.
  • transmitting the fourth response comprises transmitting, via the SMF, the fourth response to the terminal device 120.
  • verifying validity of the fourth request comprises extracting, from the fourth request, a first identifier of the application 110 and a second identifier of the terminal device 120; determining, based on the first identifier and application registration information obtained from a NEF, whether the application 110 has been registered to the NEF; determining, based on the second identifier and device registration information obtained from a UDM, whether the terminal device 120 has been registered to the UDM; in response to determining that the application 110 has been registered to the NEF and the terminal device 120 has been registered to the UDM, determining the fourth request as valid; and in response to determining that the application 110 has not been registered to the NEF or the terminal device 120 has not been registered to the UDM, determining the fourth request as invalid.
  • the method 900 further comprises receiving, from the application 110, a sixth request for verifying the second access token; and transmitting, to the application 110, a sixth response to the sixth request, the sixth response comprising the information about the second access token.
  • receiving the sixth request comprises receiving, via a NEF, the third request from the application 110.
  • transmitting the sixth response comprises transmitting, via the NEF, the sixth response to the application 110.
  • Fig. 10 shows a flowchart of an example method 1000 according to some example embodiments of the present disclosure.
  • the method 1000 can be implemented at the application 110 as shown in Fig. 1. It is to be understood that the method 1000 may include additional blocks not shown and/or may omit some shown blocks, and the scope of the present disclosure is not limited in this regard.
  • the application 110 receives, from the terminal device 120, a fifth request for accessing the application 110, the fifth request comprising a second access token for accessing the application 110.
  • the application 110 transmits, to the terminal device 120, a fifth response to the fifth request based on a result of the verification.
  • verifying validity of the second access token comprises transmitting, to the authorizations server 130 generating the second access token, a sixth request for verifying the second access token; receiving, from the authorization server 130, a sixth response to the sixth request; and verifying validity of the second access token based on the sixth response.
  • transmitting the sixth request comprises transmitting, via a NEF, the sixth request to the authorization server 130.
  • receiving the sixth response comprises receiving, via the NEF, the sixth response from the authorization server 130.
  • verifying validity of the second access token based on the sixth response comprises extracting, from the fifth request, third information about the second access token; extracting, from the sixth response, fourth information about the second access token; in response to the third information matching the fourth information, determining the second access token as valid; and in response to the third information not matching the fourth information, determining the second access token as invalid.
  • transmitting the fifth response comprises in response to the second access token being valid, transmitting the fifth response for enabling the terminal device 120 to access the application 110; and in response to the second access token being invalid, transmitting the fifth response for disabling the terminal device 120 to access the application 110.
  • an apparatus capable of performing the method 500 may comprise means for performing the respective steps of the method 500.
  • the means may be implemented in any suitable form.
  • the means may be implemented in a circuitry or software module.
  • the apparatus capable of performing the method 500 comprises: means for transmitting, from an application to an authorization server, a first request for a first access token to be used by the application to access a terminal device; means for in response to the first request being determined as valid by the authorization server, receiving a first response to the first request from the authorization server, the first response comprising the first access token and information about the first access token; means for transmitting, based on the information and to the terminal device, a second request for accessing the terminal device, the second request comprising the first access token; and means for receiving a second response to the second request from the terminal device.
  • the means for transmitting the first request comprises means for transmitting, via a Network Exposure Function, the first request to the authorization server.
  • the means for receiving the first response comprises means for receiving, via the Network Exposure Function, the first response from the authorization server.
  • the apparatus capable of performing the method 500 further comprises means for prior to transmitting the first request, registering the application to the authorization server via a Network Exposure Function.
  • an apparatus capable of performing the method 600 may comprise means for performing the respective steps of the method 600.
  • the means may be implemented in any suitable form.
  • the means may be implemented in a circuitry or software module.
  • the apparatus capable of performing the method 600 comprises: means for receiving, at an authorization server and from an application, a first request for a first access token to be used by the application to access a terminal device; means for verifying validity of the first request; means for in response to the first request being valid, generating the first access token and information about the first access token; and means for transmitting, to the application, a first response to the first request, the first response comprising the first access token and the information about the first access token.
  • the means for receiving the first request comprises: means for receiving, via a Network Exposure Function, the first request from the application.
  • the means for transmitting the first response comprises means for transmitting, via the Network Exposure Function, the first response to the application.
  • the means for verifying validity of the first request comprises: means for extracting, from the first request, a first identifier of the application and a second identifier of the terminal device; means for determining, based on the first identifier, whether the application has been registered to the authorization server; means for determining, based on the second identifier and device registration information obtained from a Unified Data Repository, whether the terminal device has been registered to the Unified Data Repository; means for in response to determining that the application has been registered to the authorization server and the terminal device has been registered to the Unified Data Repository, determining the first request as valid; and means for in response to determining that the application has not been registered to the authorization server or the terminal device has not been registered to the Unified Data Repository, determining the first request as invalid.
  • the apparatus capable of performing the method 600 further comprises: means for receiving, from the terminal device, a third request for verifying the first access token; and means for transmitting, to the terminal device, a third response to the third request, the third response comprising the information about the first access token.
  • the means for receiving the third request comprises: means for receiving, via an Access and Mobility Management Function, the third request from the terminal device.
  • the means for transmitting the third response comprises: means for transmitting, via the Access and Mobility Management Function, the third response to the terminal device.
  • an apparatus capable of performing the method 700 may comprise means for performing the respective steps of the method 700.
  • the means may be implemented in any suitable form.
  • the means may be implemented in a circuitry or software module.
  • the apparatus capable of performing the method 700 comprises: means for receiving, at a terminal device and from an application, a second request for accessing the terminal device, the second request comprising a first access token for accessing the terminal device; means for verifying validity of the first access token; and means for transmitting, to the application, a second response to the second request based on a result of the verification.
  • the means for verifying validity of the first access token comprises: means for transmitting, to an authorizations server generating the first access token, a third request for verifying the first access token; means for receiving, from the authorization server, a third response to the third request; and means for verifying validity of the first access token based on the third response.
  • the means for transmitting the third request comprises: means for incorporating the third request into a service request to be transmitted to an Access and Mobility Management Function; and means for transmitting, via Radio Access Network, the service request to the Access and Mobility Management Function, such that the Access and Mobility Management Function forwards the third request to the authorization server.
  • the means for receiving the third response comprises: means for in response to the Access and Mobility Management Function receiving the third response from the authorization server, receiving, via the Radio Access Network and from the Access and Mobility Management Function, a service accept message comprising the third response.
  • the means for verifying validity of the first access token based on the third response means for extracting, from the second request, first information about the first access token; means for extracting, from the third response, second information about the first access token; means for in response to the first information matching the second information, determining the first access token as valid; and means for in response to the first information not matching the second information, determining the first access token as invalid.
  • the means for transmitting the second response comprises: means for in response to the first access token being valid, transmitting the second response for enabling the application to access the terminal device; and means for in response to the first access token being invalid, transmitting the second response for disabling the application to access the terminal device.
  • an apparatus capable of performing the method 800 may comprise means for performing the respective steps of the method 800.
  • the means may be implemented in any suitable form.
  • the means may be implemented in a circuitry or software module.
  • the apparatus capable of performing the method 800 comprises: means for transmitting, from a terminal device to an authorization server, a fourth request for a second access token to be used by the terminal device to access an application; means for in response to the fourth request being determined as valid by the authorization server, receiving a fourth response to the fourth request from the authorization server, the fourth response comprising the second access token and information about the second access token; means for transmitting, based on the information and to the application, a fifth request for accessing the application, the fifth request comprising the second access token; and means for receiving a fifth response to the fifth request from the application.
  • the means for transmitting the fourth request comprises: means for incorporating the fourth request into a registration request to be transmitted to an Access and Mobility Management Function; and means for transmitting the registration request to the Access and Mobility Management Function, such that the Access and Mobility Management Function registers the terminal device to a Unified Data Repository and forwards the fourth request to the authorization server.
  • the means for receiving the fourth response comprises: means for in response to the Access and Mobility Management Function receiving the fourth response from the authorization server, receiving a registration response to the registration request from the Access and Mobility Management Function, the registration response comprising the fourth response.
  • the means for transmitting the fourth request comprises: means for incorporating the fourth request into a session establishment request to be transmitted to an Access and Mobility Management Function; and means for transmitting the session establishment request to the Access and Mobility Management Function, such that the Access and Mobility Management Function forwards the fourth request to the authorization server via a Session Management Function.
  • the means for receiving the fourth response comprises: means for in response to the Access and Mobility Management Function receiving the fourth response from the authorization server via the Session Management Function, receiving a session establishment response to the session establishment request from the Access and Mobility Management Function, the session establishment response comprising the fourth response.
  • an apparatus capable of performing the method 900 may comprise means for performing the respective steps of the method 900.
  • the means may be implemented in any suitable form.
  • the means may be implemented in a circuitry or software module.
  • the apparatus capable of performing the method 900 comprises: means for receiving, at an authorization server and from a terminal device, a fourth request for a second access token to be used by the terminal device to access an application; means for verifying validity of the fourth request; means for in response to the fourth request being valid, generating the second access token and information about the second access token; and means for transmitting, to the terminal device, a fourth response to the fourth request, the fourth response comprising the second access token and the information about the second access token.
  • the means for receiving the fourth request comprises: means for receiving, via an Access and Mobility Management Function, the fourth request from the terminal device.
  • the means for transmitting the fourth response comprises: means for transmitting, via the Access and Mobility Management Function, the fourth response to the terminal device.
  • the means for receiving the fourth request comprises: means for receiving, via a Session Management Function, the fourth request from the terminal device.
  • the means for transmitting the fourth response comprises: means for transmitting, via the Session Management Function, the fourth response to the terminal device.
  • the means for verifying validity of the fourth request comprises: means for extracting, from the fourth request, a first identifier of the application and a second identifier of the terminal device; means for determining, based on the first identifier and application registration information obtained from a Network Exposure Function, whether the application has been registered to the Network Exposure Function; means for determining, based on the second identifier and device registration information obtained from a Unified Data Repository, whether the terminal device has been registered to the Unified Data Repository; means for in response to determining that the application has been registered to the Network Exposure Function and the terminal device has been registered to the Unified Data Repository, determining the fourth request as valid; and means for in response to determining that the application has not been registered to the Network Exposure Function or the terminal device has not been registered to the Unified Data Repository, determining the fourth request as invalid.
  • the apparatus capable of performing the method 900 further comprises: means for receiving, from the application, a sixth request for verifying the second access token; and means for transmitting, to the application, a sixth response to the sixth request, the sixth response comprising the information about the second access token.
  • the means for receiving the sixth request comprises: means for receiving, via a Network Exposure Function, the third request from the application.
  • the means for transmitting the sixth response comprises: means for transmitting, via the Network Exposure Function, the sixth response to the application.
  • an apparatus capable of performing the method 1000 may comprise means for performing the respective steps of the method 1000.
  • the means may be implemented in any suitable form.
  • the means may be implemented in a circuitry or software module.
  • the apparatus capable of performing the method 1000 comprises: means for receiving, at an application and from a terminal device, a fifth request for accessing the application, the fifth request comprising a second access token for accessing the application; means for verifying validity of the second access token; and means for transmitting, to the terminal device, a fifth response to the fifth request based on a result of the verification.
  • the means for verifying validity of the second access token comprises: means for transmitting, to an authorizations server generating the second access token, a sixth request for verifying the second access token; means for receiving, from the authorization server, a sixth response to the sixth request; and means for verifying validity of the second access token based on the sixth response.
  • the means for transmitting the sixth request comprises: means for transmitting, via a Network Exposure Function, the sixth request to the authorization server.
  • the means for receiving the sixth response comprises: means for receiving, via the Network Exposure Function, the sixth response from the authorization server.
  • the means for verifying validity of the second access token based on the sixth response comprises: means for extracting, from the fifth request, third information about the second access token; means for extracting, from the sixth response, fourth information about the second access token; means for in response to the third information matching the fourth information, determining the second access token as valid; and means for in response to the third information not matching the fourth information, determining the second access token as invalid.
  • the means for transmitting the fifth response comprises: means for in response to the second access token being valid, transmitting the fifth response for enabling the terminal device to access the application; and means for in response to the second access token being invalid, transmitting the fifth response for disabling the terminal device to access the application.
  • Fig. 11 is a simplified block diagram of a device 1100 that is suitable for implementing embodiments of the present disclosure.
  • the terminal device 120 and/or the authorization server 130 as shown in Fig. 1 can be implemented by the device 1100.
  • the application 110 as shown in Fig. 1 can be implemented at the device 1100.
  • the device 1100 includes one or more processors 1110, one or more memories 1120 coupled to the processor 1110, and one or more communication modules 1140 coupled to the processor 1110.
  • the communication module 1140 is for bidirectional communications.
  • the communication module 1140 has at least one antenna to facilitate communication.
  • the communication interface may represent any interface that is necessary for communication with other network elements.
  • the processor 1110 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non- limiting examples.
  • the device 1100 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.
  • the memory 1120 may include one or more non-volatile memories and one or more volatile memories.
  • the non-volatile memories include, but are not limited to, a Read Only Memory (ROM) 1124, an electrically programmable read only memory (EPROM), a flash memory, a hard disk, a compact disc (CD), a digital video disk (DVD), and other magnetic storage and/or optical storage.
  • ROM Read Only Memory
  • EPROM electrically programmable read only memory
  • flash memory a hard disk
  • CD compact disc
  • DVD digital video disk
  • the volatile memories include, but are not limited to, a random access memory (RAM) 1122 and other volatile memories that will not last in the power-down duration.
  • RAM random access memory
  • a computer program 1130 includes computer executable instructions that are executed by the associated processor 1110.
  • the program 1130 may be stored in the ROM 1124.
  • the processor 1110 may perform any suitable actions and processing by loading the program 1130 into the RAM 1122.
  • the embodiments of the present disclosure may be implemented by means of the program 1130 so that the device 1100 may perform any process of the disclosure as discussed with reference to Figs. 5-10.
  • the embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.
  • the program 1130 may be tangibly contained in a computer readable medium which may be included in the device 1100 (such as in the memory 1120) or other storage devices that are accessible by the device 1100.
  • the device 1100 may load the program 1130 from the computer readable medium to the RAM 1122 for execution.
  • the computer readable medium may include any types of tangible non-volatile storage, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like.
  • Fig. 12 shows an example of the computer readable medium 1200 in form of CD or DVD.
  • the computer readable medium has the program 1130 stored thereon.
  • NFV network functions virtualization
  • a virtualized network function may comprise one or more virtual machines running computer program codes using standard or general type servers instead of customized hardware. Cloud computing or data storage may also be utilized.
  • radio communications this may mean node operations to be carried out, at least partly, in a central/centralized unit, CU, (e.g. server, host or node) operationally coupled to distributed unit, DU, (e.g. a radio head/node). It is also possible that node operations will be distributed among a plurality of servers, nodes or hosts. It should also be understood that the distribution of labour between core network operations and base station operations may vary depending on implementation.
  • the server may generate a virtual network through which the server communicates with the distributed unit.
  • virtual networking may involve a process of combining hardware and software network resources and network functionality into a single, software-based administrative entity, a virtual network.
  • Such virtual network may provide flexible distribution of operations between the server and the radio head/node.
  • any digital signal processing task may be performed in either the CU or the DU and the boundary where the responsibility is shifted between the CU and the DU may be selected according to implementation.
  • a CU-DU architecture is implemented.
  • the apparatus 1100 may be comprised in a central unit (e.g. a control unit, an edge cloud server, a server) operatively coupled (e.g. via a wireless or wired network) to a distributed unit (e.g. a remote radio head/node).
  • the central unit e.g. an edge cloud server
  • the distributed unit may be stand-alone apparatuses communicating with each other via a radio path or via a wired connection. Alternatively, they may be in a same entity communicating via a wired connection, etc.
  • the edge cloud or edge cloud server may serve a plurality of distributed units or a radio access networks.
  • at least some of the described processes may be performed by the central unit.
  • the apparatus 1100 may be instead comprised in the distributed unit, and at least some of the described processes may be performed by the distributed unit.
  • the execution of at least some of the functionalities of the apparatus 1100 may be shared between two physically separate devices (DU and CU) forming one operational entity. Therefore, the apparatus may be seen to depict the operational entity comprising one or more physically separate devices for executing at least some of the described processes.
  • CU-DU architecture may provide flexible distribution of operations between the CU and the DU.
  • any digital signal processing task may be performed in either the CU or the DU and the boundary where the responsibility is shifted between the CU and the DU may be selected according to implementation.
  • the apparatus 1100 controls the execution of the processes, regardless of the location of the apparatus and regardless of where the processes/functions are carried out.
  • various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representations, it is to be understood that the block, apparatus, system, technique or method described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.
  • the present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer readable storage medium.
  • the computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target real or virtual processor, to carry out the methods 500, 600, 700, 800, 900 and/or 1000 as described above with reference to Figs. 5- 10.
  • program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types.
  • the functionality of the program modules may be combined or split between program modules as desired in various embodiments.
  • Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.
  • Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowcharts and/or block diagrams to be implemented.
  • the program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.
  • the computer program codes or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above.
  • Examples of the carrier include a signal, computer readable medium, and the like.
  • the computer readable medium may be a computer readable signal medium or a computer readable storage medium.
  • a computer readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD- ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Des modes de réalisation de la présente invention concernent des procédés, des appareils et des supports d'informations lisibles par ordinateur permettant de partager des données. Un procédé est décrit selon des modes de réalisation illustratifs de l'invention. Le procédé consiste à transmettre, d'une application à un serveur d'autorisation, une première demande pour un premier jeton d'accès devant être utilisé par l'application afin d'accéder à un dispositif terminal; en réponse à la détermination du fait que la première demande est valide par le serveur d'autorisation, à recevoir une première réponse à la première demande provenant du serveur d'autorisation, la première réponse comprenant le premier jeton d'accès et des informations concernant le premier jeton d'accès; à transmettre, sur la base des informations et au dispositif terminal, une seconde requête d'accès au dispositif terminal, la seconde requête comprenant le premier jeton d'accès; et à recevoir une seconde réponse à la seconde demande provenant du dispositif terminal.
PCT/FI2020/050534 2019-08-21 2020-08-18 Service d'autorisation basé sur plmn WO2021032912A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN201941033672 2019-08-21
IN201941033672 2019-08-21

Publications (1)

Publication Number Publication Date
WO2021032912A1 true WO2021032912A1 (fr) 2021-02-25

Family

ID=74660199

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FI2020/050534 WO2021032912A1 (fr) 2019-08-21 2020-08-18 Service d'autorisation basé sur plmn

Country Status (1)

Country Link
WO (1) WO2021032912A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018013925A1 (fr) * 2016-07-15 2018-01-18 Idac Holdings, Inc. Structure d'autorisation adaptative pour réseaux de communication
US20180302391A1 (en) * 2017-04-12 2018-10-18 Cisco Technology, Inc. System and method for authenticating clients
US20190251241A1 (en) * 2018-02-15 2019-08-15 Nokia Technologies Oy Security management for service authorization in communication systems with service-based architecture

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018013925A1 (fr) * 2016-07-15 2018-01-18 Idac Holdings, Inc. Structure d'autorisation adaptative pour réseaux de communication
US20180302391A1 (en) * 2017-04-12 2018-10-18 Cisco Technology, Inc. System and method for authenticating clients
US20190251241A1 (en) * 2018-02-15 2019-08-15 Nokia Technologies Oy Security management for service authorization in communication systems with service-based architecture

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security architecture and procedures for 5G system (Release 15)", 3GPP TS 33.501 V15.5.0, 13 June 2019 (2019-06-13), XP051754085, Retrieved from the Internet <URL:https://www.3gpp.org/ftp/Specs/archive/33_series/33.501/33501-f50.zip> [retrieved on 20201106] *
"The OAuth 2.0 Authorization Framework", RFC 6749, October 2012 (2012-10-01), Retrieved from the Internet <URL:https://tooIs.ietf.org/pdf/rfc6749.pdf> [retrieved on 20201106] *

Similar Documents

Publication Publication Date Title
CN111107543B (zh) 蜂窝服务账户转移和认证
US10194320B1 (en) Method and apparatus for assignment of subscription electronic SIM credentials via local service brokers
US11706617B2 (en) Authenticating radio access network components using distributed ledger technology
CN103503407B (zh) 用于多sso技术的sso框架
US20160127331A1 (en) Method and system for encrypted communications
US20210176250A1 (en) Network Service Control for Access to Wireless Radio Networks
US8931068B2 (en) Authentication process
CN113784343B (zh) 保护通信的方法和装置
US8990555B2 (en) Centralized key management
US9130919B2 (en) Hosted IMS instance with authentication framework for network-based applications
WO2022073213A1 (fr) Mécanisme d&#39;autorisation dynamique
US20170325092A1 (en) Discovery mechanism for service server connection
US20230232228A1 (en) Method and apparatus for establishing secure communication
WO2021219385A1 (fr) Identification sécurisée d&#39;une fonction de réseau
WO2021160386A1 (fr) Service d&#39;autorisation pour fournir un contrôle d&#39;accès
US11818102B2 (en) Security enhancement on inter-network communication
CN112672336A (zh) 实现外部认证的方法、通信装置及通信系统
WO2022147827A1 (fr) Gestion de jetons d&#39;accès pour une communication indirecte
WO2022000155A1 (fr) Contrôle d&#39;accès de cadre de gestion à base de service
WO2021056448A1 (fr) Procédé de traitement de communication et appareil de traitement de communication
US11283884B2 (en) Methods for the sharing of location data between a source device of a user and a third party&#39;s destination device, corresponding server, source device of a user, third party&#39;s destination device, and computer program
US20220360586A1 (en) Apparatus, methods, and computer programs
WO2021032912A1 (fr) Service d&#39;autorisation basé sur plmn
US20230370525A1 (en) Terminal device authorization for requesting analytics
US20230413052A1 (en) Access token revocation in security management

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20855327

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20855327

Country of ref document: EP

Kind code of ref document: A1