TBAS: Token-based authorization service architecture in Internet of things scenarios

Abstract

Internet of things refers to billions of interconnected devices that are generally equipped with sensors and communication devices. How to make Internet of things become a smart terminal is an important topic. By connecting cloud services, the devices can receive more accurate information so as to be applied in people’s daily life. However, the smart terminal devices access the cloud services via Representational State Transfer (RESTful) application programming interfaces, and how the cloud server authenticates and authorizes billions of devices is an immense challenge. Additionally, individual use of smart terminal devices is accompanied by such problems as privacy data or security. This article presents a token-based authorization service framework. The devices can have a safer access to cloud services through the token. Token is released by a third-party authentication center to improve its reliability and security and is featured by a high degree of privacy that sensitive data are not easily leaked. Furthermore, the token is valid only within a period of time or it will not work after the token count exceeds the threshold defined by the system, thereby lowering the devices’ risk of being hacked. The framework proposed in this article is applied to medical wearable devices. The advantages of this framework are practical and secure which are explained in the experimental chapter.

Keywords

Token OpenID OAuth authorization Internet of things

Introduction

The Internet of things (IoT) devices are generally characterized by low power consumption, limited storage space, and processing capacity, but limited in reliability, computing performance, security, and confidentiality. Hence, the IoT and cloud computing are perfectly complementary. Due to the mature cloud platform technology, the storage space of the cloud services is virtually not restricted. The distributed and parallel computing capabilities can process the large amounts of perceptual data of the ubiquitous wireless sensors. Many studies have discussed this topic and published numerous papers concerning the integration between the design of cloud computing and cloud services.^1–4 The integration of cloud computing and IoT makes software services and consumption available anywhere and anytime. Hence, how the cloud server authenticates and authorizes billions of devices is an immense challenge. The contribution of this article is that we design a token-based authorization service (TBAS). The devices have a safer access to cloud services through the token.

The interoperability between cloud services and IoT devices is realized by Web services. Specifically, RESTful API (application programming interface)⁵ is the most common way to realize this in the services of many well-known companies (including Google and Facebook). RESTful systems usually have communication through HTTP (Hypertext Transfer Protocol). In the communication practice of IoT, the constrained application protocol (CoAP)⁶ is often used as a Web universal communication protocol. The RESTful API allows the cloud server to authenticate each client through cookies or HTTP sessions. Nevertheless, hackers can easily steal identification information. For example, they may steal the identification information by tapping broadcast message or providing a pseudo-agent. The hackers may masquerade as an authenticated client using a stolen identity and communicate and connect with the cloud services. Worse still, the cloud services may be used as a springboard for attackers, hence contributing to information security hazards.

This article proposes a TBAS framework and provides privacy access control and an authorization framework which is integrated by invoking an external TBAS. The design obtains a token based on the RESTful API request on HTTP/HTTPS (Hypertext Transfer Protocol Secure). Each token is issued by a third-party verification center, and it has timeliness and count limits. Each access to the cloud services will be counted once. When the token reference count exceeds the system set value, the token becomes invalid and receives the notice of requesting a new token issued by the system. Long-time non-use of the token will result in token time expiration. When the token uses the cloud services again, it receives the notice of requesting a new token issued by the system. As a result, the IoT devices’ risk of being hacked will be lowered. Each use of the IoT devices is recorded by the token, which can effectively take information security protection measures through such record. For instance, if the token increases rapidly in a short time, it may be used as a springboard for attackers to carry out distributed denial of service (DDoS) attack. In other cases, if the IoT devices attempt to access other services or data illegally, such attempts can be tracked by observing the token’s behaviors.

Moreover, the network information security monitoring aims at the token, so the privacy of the devices can be protected. The system can only know whether the token is valid or not or has the right to access what kinds of services and data, but cannot know the true identity of the devices. Furthermore, the token can be employed to integrate a vast range of cloud services so that the application of the token is not only restricted to the platforms developed by the developers, but can produce more innovative applications and greater safety. Therefore, the developers need not to worry about the privacy of their products.

The experimental scenarios in this article are applied to medical wearable devices. A wearable device for monitoring heart rate requests services from a cloud platform through a mobile phone or gateway. The users’ medical information is concerned with personal privacy, so token can offer users a high degree of privacy and security and prevent data from being leaked. Additionally, the medical devices are associated with care or emergency issues, so this experiment will include such issues into the token design to enable the token to be effectively applied in the medical cloud services.

The rest of the article is organized as follows. In section “Related works,” the related works are discussed. Then, the TBAS architecture will be discussed in section “The proposed authorization framework.” In section “Experimental result,” we will demonstrate our experimental result. Finally, conclusions are given in section “Conclusion.”

Related works

OpenID

OpenID⁷ is a user-centric digital identification framework and is open, decentralized, and free. It is created based on the concept of identifying a website or user’s identity through URI (Uniform Resource Identifier)⁸ or URL (Uniform Resource Locator). Currently, the vast majority of websites authenticate the user identity by means of account and password, so you need to register an account on each website. By contrast, on the websites supporting OpenID, users need not to remember such traditional authentication tags as user account and password. Instead, the users only need to register on a website as an OpenID Provider (OP) in advance. Users can log in all Relying Party (RP) websites supporting OpenID authentication and need not to register a new account and set the corresponding password. Some RPs require the users to fill in additional data. OpenID is decentralized, so any website can use OpenID as a way of users’ login and can act as the OP. As a result, the problem of confirming digital identities via centralized websites is solved.

OpenID is one of the ways to realize Single Sign-On.⁹ Single Sign-On means that users can quickly log in a number of website systems using a set of account passwords. Therefore, OpenID can tackle the problem that the users need to repeatedly enter the account password and other authentication data when using different services. The use of OpenID requires no additional hardware and software, and the authentication is simply completed through web browser and server-side communication. OpenID is applicable to the network services based on the frameworks HTTP/HTTPS and the use scenario of Web2.0,¹⁰ and the mode of operation is user-centric and combines authentication, identification, trust, authorization, and other service concepts. Add to this, OpenID provides a proxy authentication mechanism, so users may use such a mechanism to integrate the identities on the network, enhance the authenticity of personal identity, and reduce the chance of being impersonated by others. As a result, the domain of e-Health also employs OpenID for identity authentication as referred in Bughin and Manyika.¹¹ The OpenID implementation flow is shown in Figure 1.

Figure 1.

The communication flow of OpenID.

OAuth

In the traditional client–server framework, client needs to present account password to the resource owner in order to access the protected resource. To allow third-party applications to obtain these resources, the resource owner needs to give the account password to the third-party applications, which results in the following problems and limitations: (1) the third-party applications must store the resource owner’s account password usually in plain text. (2) The server must support password authentication. (3) The third-party applications will get the nearly complete permission and access the protected resources, which the resource owner cannot restrict the timeliness and scope of third-party applications’ access to the resources. (4) The resource owner cannot withdraw the access right of a single third-party only and can only withdraw such right by changing password. (5) If any third-party application is compromised, all data about using such password will be compromised and stolen.

OAuth^12,13 solves these problems by introducing an authorization layer and separating the roles of the client and the resource owner. In OAuth, the client will first request the access right to resources to access the resources by the resource owner. These resources will be stored in the resource server, and the client will obtain a set of credentials different from those owned by the resource owner. The client will get an Access Token to access the protected resources rather than using the resource owner’s account password. Access Token is a string that records the specific access scope, timeliness, and other information. It is obtained from the authorization server, before which it needs to obtain the resource owner’s permission. The client uses this Access Token to access the protected resources stored in the resource server. Nevertheless, data transmission on the network will be seen, so it is required that Transport Layer Security (TLS)¹⁴ should be used throughout the transmission. Hence, OAuth uses HTTPS. The role definition of OAuth 2.0 is resource owner can authorize others to access the protected resource. If this role is human, it means the end user. The resource server where the protected resource is stored can accept the request of the protected resource according to the Access Token. The client means the applications where the resource owner accesses the protected resource. The term “Client” does not refer to any particular implementation methods (which can be implemented on servers, general PCs, mobiles, or other devices). The authorization server will approve and issue the Access Token’s server after authenticating the resource owner and obtaining its permission. The implementation flow of OAuth 2.0 is shown in Figure 2.

Figure 2.

The communication flow of OAuth.

IoT-OAS (OAuth-based authorization service)¹⁵ is based on an authorization service framework proposed by OAuth and applied in IoT. It is in essence similar to OAuth and requires the permission of the resource owner. In IoT services, the resource owner is often the device itself and such a framework needs to have the functions of a proxy. The token presented in this article is to simplify the process of authentication and authorization while retaining the advantages of OpenID and OAuth.

Privacy protection

In respect of medical IoT, patient information, like data about physiological characteristics, location, and activities, is private and hence needs to have appropriate privacy protection. Presently, the protection means of privacy¹⁶ are divided into the following: (1) from the perspectives of privacy information protection by organizations and institutions, digital identity authentication, access control and physical security, and other means are the most widely used privacy protection technologies. (2) From the personal point of view, information hiding technology, anonymous technology, encryption and decryption, and other means are adopted to protect the security of personal private information.

In terms of key management and authentication technology, due to the heterogeneity of IoT’s composition, IoT currently has two major key management and authentication methods in Wang et al.¹⁷ and ISAKMP (Internet Security Association and Key Management Protocol):¹⁸ centralized management and heterogeneous network-centric distributed management. Centralized management means that the trust and security center is responsible for the key’s generation, distribution, update, and other management as well as message authentication and identity authentication. Regarding distributed management, owing to the limited resources of IoT devices, the key management and authentication problems can be easily solved using the Internet and mobile communication network. Presently, there are tons of studies on key management schemes of wireless sensing network. One of the classic schemes is Tiny Sec¹⁹ running on TinyOS. This is a management scheme of symmetric key, on the basis of which SPINS (Security Protocols for Sensor Networks) security protocol^20,21 is developed.

With regard to privacy protection means, apart from using the key to encrypt or decrypt information, the token mechanism²² can also be employed to protect the privacy data. The token mechanism is often used to protect the security of payment data, including credit card accounts and passwords or online trading accounts and passwords. Token is used to replace the privacy data and for identity authentication, so the privacy data will not be leaked in the operation to ensure privacy and security. Compared with the key encryption and decryption mechanism, token mechanism has a number of advantages. Specifically, unlike the key encryption and decryption mechanism, it does not require the devices to have certain computing resources and storage resources for encrypting and decrypting ciphertext and storing key. Instead, the token mechanism imposes no requirement on the devices’ computing resources and storage resources, so it is very suitable for devices and environments with limited resources. Furthermore, using the key for encryption and decryption will consume energy, which does not meet the IoT’s characteristics of low power consumption. Besides, the token is also irreversible, which means that even if a token is obtained by a malicious attacker through technical means, the original privacy data cannot be cracked. A way of regarding token as service is proposed to ensure the user’s privacy security,²³ and the token is applicable to GUISET (Grid-based Utility Infrastructure for Small, Micro, and Medium Enterprises Enabling Technology),²⁴ provides a means of safely processing the users’ sensitive information and hence lowers the risk of data leakage.

Although OpenID and OAuth perform quite well in authentication and license management and are applied in a myriad of network services, this article focuses on proposing a generic authentication and authorization service for IoT. Given the limited resources of IoT and limited computing and storage capacity, to reduce human intervention, through the development of standards, an IoT authentication and authorization service framework is provided which can flexibly and effectively integrate a vast range of services, generates more innovative applications, and is safer.

The proposed authorization framework

TBAS

Hundreds of millions of IoT devices access diverse cloud services through the network communication capacity. There are tons of IoT devices, and to ensure that each device is legally authorized to access the cloud resources, an authentication and authorization platform is needed. In this article, we proposed a TBAS framework and provided privacy access control and an authorization framework which is integrated by invoking an external TBAS. TBAS generates a set of tokens as requested by the devices and will check the reasonableness and legitimacy when the token is generated. Token has timeliness and count limits and can effectively take information security protection measures through such record. For ease of presentation, the used acronyms are summarized as follows:

D: Device.

SP: Service Provider.

DT: Device Token.

TBAS: Token-Based Authorization Service.

A standard TBAS operation process is presented in Figure 3. The implementation flow is as follows:

A device does not use the token to access services on the cloud.

The device is stopped by the authorization check layer and is requested to use token for authentication and authorization.

The device requests a token from TBAS.

TBAS checks the reasonableness and legitimacy of the request and grants a token.

The device re-requests the services from the service provider. The authorization check layer approves the authentication.

The device may use the service for a certain period of time and within a certain number of times.

Figure 3.

The flow of TBAS.

Authorization check layer

The token has timeliness and count limits and each access to the cloud services will be counted once. When the token reference count exceeds the system set value, the token will become invalid and will receive the notice of requesting a new token issued by the system. Long-time non-use of the token will result in token time expiration. When the token uses the cloud services again, it will receive the notice of requesting a new token issued by the system. These actions are achieved by the authorization check layer. The use of the IoT devices will be recorded by the token, which can effectively take information security protection measures through such record. For example, if the token increases rapidly in a short time, it may be used as a springboard for attackers to carry out DDoS attack. Additionally, if the IoT devices attempt to access other services or data illegally, such attempts can be tracked by observing the token’s behaviors. Besides, the network information security monitoring aims at the token, so the privacy of the devices can be protected. The authorization check layer can only know whether the token has the right to access what kinds of services and data, but cannot know the true identity of the devices. As a result, the devices can use a wide range of services on the cloud without worrying about privacy.

Generating a token

Tokenization²³ has been used in many fields, such as network communication, information security, credit cards, third-party authentication, and other areas. The IoT devices can be mapped to a token which is a reference (identifier) without external significance or use value and used for sensitive data protection, secure storage, auditing, authentication and authorization, and services. TBAS generates a set of tokens based on the device’s machine ID, user ID, service categories and request time-stamp, and through the hash algorithm²⁵ in SHA-2 or SHA-3.

DT = Hash(MID+UID+Type+RT)

MID: Machine ID

UID: User ID

Type: Service Type

RT: Request Time-stamp

Granting a token

In the use of cloud services, the IoT device must first obtain a token through registration. The operation flow to grant a token to a device is shown in Figure 4. The steps are as follows:

The device requests a token from the TBAS.

TBAS checks the reasonableness and legitimacy and then grants a token.

The device uses the token to request the cloud service. The authorization check layer records tokens and assigns additional information to the token, such as duration, reference counter, degree, and priority.

The authorization check layer notifies the service provider and requests consent.

The service provider consents to the device’s access to services.

The authorization check layer responses to the device.

The device may use the service for a certain period of time and within a certain number of times.

Figure 4.

The flow of granting a token.

Mobile device binding

In the application scenarios of the IoT, the communication capabilities of IoT devices are often confined to local area network out of consideration of low power consumption. Thus, the devices do not have the ability to communicate directly with the cloud network. Generally speaking, the devices often have external communication through a gateway or Fog computing²⁶ framework.

This article proposes a mobile IoT-based application scenario where mobile devices are used as a communication relay station. When the mobile device and service provider offer services, they communicate safely only through the authentication and authorization mechanism of token. Therefore, this article provides binding of the mobile device and the device, and the flow is shown in Figure 5. The steps are as follows:

The mobile device requests a binding from the device.

The device gives a token and carries out binding.

The mobile device requests binding authentication and authorization from the authorization check layer, which means that the mobile device will offer related services on behalf of the device.

The authorization check layer notifies TBAS and requests permission.

TBAS permits the device with such a token to apply for a proxy.

The authorization check layer notifies the service provider and requests its permission.

The service provider gives its permission.

The authorization check layer notifies the mobile device of the request result.

The mobile device may use the services on behalf of the device for a certain period of time and within a certain number of times.

Figure 5.

The flow of binding between mobile and device.

It is obvious that in the flow design of this article, the entire binding procedure must be completed by obtaining the permissions and authentication of both TBAS and service provider. Such repeated authentication process is to ensure the safety of communication and to reduce the risk of being hacked. This is especially important for some of highly private data transmissions.

Experimental result

Application scenario

This article proposes the architecture of TBAS for wearable medical devices. A medical cloud-integrated service scenario is implemented. The application scenarios are divided into pregnant woman and animal (pig) experiments, cooperating with the Prenatal Management Center and National Laboratory Animal Center, respectively. The wearable medical device is a wearable device which can capture heartbeat, as shown in Figure 6. Table 1 shows the heart rates of chest signals in our previous work.²⁷ The average heart rate calculated is very close to the reference heart rate, and the measurement error is 1%–2%. The communication capability is provided with bluetooth 4.0 communication protocol. It is connected to the smart phone to communicate with the cloud management platform. The pregnant woman and pig wear the device, and the smart phone sends data to the cloud management platform through token. The information extracted from the pregnant woman is personal privacy, such as location and heart rate. This experiment will be combined with Prenatal Management Center in the future, a copy of the data is maintained by the Prenatal Management Center, and the data are sent to the third-party medical research center to analyze the data about pregnant women. Therefore, the pregnant women management center cares about the protection of their customer information. The IoT device is mapped to a token in this article, and it is a reference without external meaning or utility value (identifier), applicable to protection, secure storage, and authentication and authorization of sensitive data, and the remote server of the third-party medical research center is integrated effectively. The pregnant women protection cloud application scenario is described in the next section.

Figure 6.

The wearable device for monitoring heart rate.

Table 1.

Chest heart rate calculation comparison.

Record number	Proposed algorithm	Medical instrument oximeter	Percentage error (%)
Chest1	93.36	93.00	0.39
Chest2	91.83	92.00	–0.18
Chest3	93.72	96.00	–2.4
Chest4	92.06	92.00	0.07
Chest5	93.24	93.00	0.26
Chest6	94.94	96.00	–1.1
Chest7	95.69	94.00	1.8
Chest8	89.35	89.00	0.39

Platform deployment and network environment topology

This article implements a medical cloud-integrated service scenario. The TBAS and cloud management platform system are built, and Prenatal Management Center and research center are integrated using token. The platform deployment environment configuration is shown in Table 2. The network environment topology is shown in Figure 7. The medical information is all managed by our cloud server. The third-party cooperative unit shall access information according to the token mechanism. The performance of data transfer rate is about 3.52 MB/s between cloud management platform and a wearable device. This is shown in Figure 8.

Table 2.

The configuration of environment.

	Cloud server	TBAS
Processor	Intel(R) i7	Intel(R) i5
RAM	16 G	8 G
Operating system	Linux	Linux
Back-end	Apache 2.4	Apache 2.4
Database	Postgresql 9.3	Postgresql 9.3

TBAS: token-based authorization service.

Figure 7.

Platform deployment and network environment topology.

Figure 8.

The performance of data transfer rate.

Token request and generation of wearable medical device

In this experimental application scenario, the mobile phone is bound to the device. The mobile phone and the device are paired up successfully by the communication capability of bluetooth low energy (BLE) (bluetooth 4.0). As the device has no token information when it is used for the first time, the device sends its machine ID to the mobile phone. The mobile phone sends the machine ID of the device, its own user ID, service type (healthcare), and request time-stamp to the cloud server and requests to be a proxy for wearable device.

The authorization check layer is implemented in the cloud server. The main job is to check the token timeliness and frequency limitation, and the information of token is recorded and tracked, such as the access time and cycle, which services and data are accessed. The information is secured by this record. Because of the proxy of mobile device, the authorization check layer forwards the information (MID+UID+Type+RT) to TBAS, requesting for the token of proxy service. The process is shown in Figure 5.

How the TBAS checks the rationality and legality is one of the security protection means. In our experimental situation, the definition of machine ID uses the medium access control (MAC) address in the device and uses the target service number, service type, serial number, and check code to combine a new machine ID which is shown in Figure 9. Using the generation combination rule of this machine ID (this rule is built on TBAS), the TBAS checks the rationality and legality based on the rule of combination of machine ID, so as to decide whether or not to issue token. The TBAS is flexible in checking rationality and legality, and there are different ways for different applications. This article provides our method as reference.

Figure 9.

The information of machine ID.

Token security and data privacy protection

The token generation rule is mastered by TBAS. The communication request service is established on a secure channel (HTTPS), and the probability of embezzlement is very low. Added to this, the token has timeliness and frequency limitation, and the security can be enhanced by limiting the valid time cycle and frequency reasonably. If a hacking occurs, the authorization check layer detects whether there is exception or not according to the access domain and access frequency of token. Once an exception occurs, this token is blocked, and the device is required to request for token again. If a hacker has used token to steal data successfully, the data only contain heart rate and location information, the data cannot correspond to any device because the token is irreversible.

In the usage scenario of Prenatal Management Center, the location, electric quantity, and heart rate are extracted from the device. The cloud management platform designs the emergency notification algorithm according to the aforesaid information, helping the wearer use this device effectively. For example, too high or too low heart rate, low battery of device, the LBS (location-based service) information feedback are given according to location. However, besides calculating the heart rate, the possible prenatal complications of pregnant women are detected. The customers are concerned about using their physiological signals to detect or study other diseases. In addition, our application scenario sends the location of device to the back-end management center, and the personal location is tracked and monitored. Therefore, we use token to persuade customers that any data transmission process cannot correspond to personal information directly. The data provided for research center only contain data and serial numbers, only the Prenatal Management Center can obtain the real customer corresponding data. Therefore, our service can be easily extended to other application scenarios.

Differences among token, OpenID, and OAuth

The OpenID is mainly used for authentication. In the protected data management, it is too late once the login data are hacked. The token mechanism is quite close to the concept of OAuth. The roles of client and resource owner are separated, and the protected resources are accessed using the access token mechanism instead of the account and password of resource owner. However, the process of OAuth is simplified; as shown in Figure 2, we do not have the process of communication between resource owner and client. Therefore, the registration process is completed automatically without the intervention of other client or resource owner. In the mobile phone binding process, there are merely pairing and data transfer behaviors. Afterward, the TBAS and authorization check layer take the reins, and the security and reliability of token are administered by TBAS and authorization check layer. Therefore, the token is regarded as the simplified edition and changed edition of OAuth for IoT subject.

Features of management platform

Figure 10 shows the home page of the management platform. Figure 11 shows the page that the cloud management platform system administrator logs in the system. Figure 12 shows the page that the administrator enters, including the current online status of the wearable device, the definition of API, and the data of the administrator’s account. Each medical wearable device will have a name, registration date, timeliness, and current status. Servicing indicates that the device is currently communicating with the cloud management platform. Serviced suggests that the device is currently offline. The administrator can click on any device to see more details. Figure 13 displays the detailed information about the device, including the name, location, token, priority, time limit, service type, security level, power, and heart rate. Such information is updated by the device to the cloud management platform via the TBAS mechanism. Figure 14 shows a list of the RESTful APIs currently available on the platform. The security and privacy of the integrated medical cloud service are enhanced through the authentication license management of the TBAS.

Figure 10.

The home page of website.

Figure 11.

The login page of website.

Figure 12.

The management page of website.

Figure 13.

The detailed information of device in website.

Figure 14.

The API list page of website.

Conclusion

This article presents a TBAS framework. The devices can have a safer access to cloud services through the token. Token is released by a third-party authentication center to improve its reliability and security and is featured by such a high degree of privacy that sensitive data are not easily leaked. Given the limited resources of IoT and limited computing and storage capacity, this article proposes an authentication and authorization service framework for the IoT scenario. An experiment of integrated medical cloud services is achieved through medical wearable devices, which lends support to the viewpoints of this article.

Footnotes

Academic Editor: Fei Yu

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This research was financially supported by the Ministry of Science and Technology of Taiwan (under grant nos 104-2221-E-006-119-MY3, 103-2221-E-006-145-MY3, and 104-3115-E-194-001).

References

Rui

Danpeng

. Architecture design of the Internet of Things based on cloud computing. In: Proceedings of the 2015 seventh international conference on measuring technology and mechatronics automation (ICMTMA), Nanchang, China, 13–14 June 2015.

Zhou

Leppanen

Harjula

. CloudThings: a common architecture for integrating the Internet of Things with cloud computing. In: Proceedings of the 2013 IEEE 17th international conference on computer supported cooperative work in design (CSCWD), Whistler, BC, Canada, 27–29 June 2013.

Bai

TDP

Rabara

. Design and development of integrated, secured and intelligent architecture for Internet of Things and cloud computing. In: Proceedings of the 2015 3rd international conference on future Internet of Things and cloud (FiCloud), Rome, 24–26 August 2015.

Botta

de Donato

Persico

. On the integration of cloud computing and Internet of Things. In: Proceedings of the 2014 international conference on future Internet of Things and cloud (FiCloud), Barcelona, 27–29 August 2014.

Benslimane

Dustdar

Sheth

Services mashups: the new generation of web applications. IEEE Internet Comput 2008; 12: 13–15.

Shelby

Hartke

Bormann

The constrained application protocol (CoAP). RFC 7252, June 2014. Fremont, CA: Internet Engineering Task Force.

OpenID, http://openid.net/specs/openid-authentication-2_0.html

URI, https://www.w3.org/TR/uri-clarification/

Gross

. Security analysis of the SAML single sign-on browser/artifact profile. In: Proceedings of the 19th annual computer security applications conference, Las Vegas, NV, 8–12 December 2003, pp.298–307. New York: IEEE.

10.

Domenech

Comunello

Wangham

. Identity management in e-Health: A case study of web of things application using OpenID connect. In: Proceedings of the 2014 IEEE 16th international conference on e-Health networking, applications and services (Healthcom), Natal, Brazil, 15–18 October 2014, pp.219–224. New York: IEEE.

11.

Bughin

Manyika

How businesses are using web 2.0: a McKinsey global survey (McKinsey Quarterly Web Exclusive). New York: McKinsey & Company, 2007.

12.

Hammer-Lahav

. The OAuth 1.0 protocol. RFC 5849, April 2010. Fremont, CA: Internet Engineering Task Force, http://www.ietf.org/rfc/rfc5849.txt

13.

Hardt

. The OAuth 2.0 authorization framework. RFC 6749, October 2012. Fremont, CA: Internet Engineering Task Force, http://www.ietf.org/rfc/rfc6749.txt

14.

Dierks

Rescorla

. The transport layer security (TLS) protocol (version 1.2). RFC 5246, August 2008. Fremont, CA: Internet Engineering Task Force, http://www.ietf.org/rfc/rfc5246.txt

15.

Cirani

Picone

Gonizzi

. IoT-OAS: an OAuth-based authorization service architecture for secure services in IoT scenarios. IEEE Sens J 2015; 15(2): 1224–1234.

16.

Görlach

Heinemann

Terpstra

WW.

Survey on location privacy in pervasive computing. In: Robinson

Vogt

Wagealla

(eds) Privacy, security and trust within the context of pervasive computing. New York: Springer, 2005, pp.23–34.

17.

Wang

Bao

. Research on security management for Internet of Things. In: Proceedings of the 2010 international conference on computer application and system modeling, Taiyuan, China, 22–24 October 2010.

18.

ISAKMP, https://en.wikipedia.org/wiki/Internet_Security_Association_and_Key_Management_Protocol

19.

Karlof

Sastry

Shankar

. TinySec: a link layer security architecture for wireless sensor networks. In: Proceedings of the 2nd international conference on embedded networked sensor systems (SenSys’04), Baltimore, MD, USA, 3–5 November 2004, pp.162–175. New York, NY: ACM.

20.

Perrig

Szewczyk

Tygar

. SPINS: security protocols for sensor networks. Wirel Netw 2002; 8(5): 521–534.

21.

Delgosha

Ayday

Fekri

. MKPS: a multivariate polynomial scheme for symmetric key-establishment in distributed sensor networks. In: Proceedings of the international conference on wireless communications and mobile computing, Honolulu, HI, 12–16 August 2007, pp.236–241. New York: IEEE.

22.

Conway

. How enterprises can use tokenization to reduce risk and minimize the cost of PCI DSS compliance. PCI DSS Tokeization Buyer’s Guide, White Paper, August 26, 2011.

23.

Nxumalo

Tarwireyi

Adigun

. Towards privacy with tokenization as a service. In: Proceedings of the 6th international conference on adaptive science and technology, Ota, Nigeria, 29–31 October 2014, pp.1–6. New York: IEEE.

24.

Babafemi

Sanjay

Adigun

. Towards developing grid-based portals for e-Commerce on-Demand services on a utility computing platform. IERI Procedia 2013; 4: 81–87.

25.

Housley

. A 224-bit one-way Hash function: SHA224. RFC 3874, September 2004. Fremont, CA: Internet Engineering Task Force.

26.

Bonomi

Milito

Zhu

. Fog computing and its role in the Internet of Things. In: Proceedings of the first edition of the MCC workshop on mobile cloud computing, Helsinki, 17 August 2012, pp.13–16. New York: ACM.

27.

Lee

Yang

. Intelligent heart rate monitoring using empirical algorithm and dynamic time wrapping. Int J Innov Comput I 2017; 7(1): 1–18.