Abstract
Internet of Things will connect millions of things to the Internet to make our lives more convenient. However, Internet of Things security is an essential factor. OAuth is one of the most successful authentication and authorization protocols on the Internet. This article proposes push OAuth and personal OAuth authorization server by expanding OAuth for a secure access to the information on Internet of Things devices. In personal OAuth, the smartphones that communicate with remote servers to deliver information on Internet of Things devices can be the OAuth authorization server. Hospitals (OAuth client) that intend to access the information on Internet of Things devices cannot know millions of OAuth authorization server when the smartphone becomes the OAuth authorization server. This article proposes the push OAuth that changes the OAuth protocol and issues the OAuth token when the OAuth authorization server registers to the OAuth client first. Personal OAuth authorization server is far more trustworthy than using a third-party OAuth authorization server to authenticate because users directly control access to the information generated by Internet of Things devices. The personal OAuth authorization server and push OAuth suggested here are expected to create a more secure Internet of Things environment as users can directly authenticate the OAuth client that can access the information on their Internet of Things devices.
Introduction
Internet of Things (IoT) has rapidly become one of the most popular research areas. IoT is closely applied to everyday life in various areas, such as wearable, smart homes, connected cars, smart hospitals, factories, smart electricity meter, 1 and traffic, and various markets are created using it.2,3 IoT would be able to make our lives more efficient and more convenient. However, various technologies are studied to prevent a variety of security threats as the IoT environment is directly related to the major social infrastructures and everyday lives. 3 Security is required for everyone to enjoy the convenience of IoT securely. Designing efficient and secure authentication and authorization schemes is a big challenge issue.
OAuth is an authentication and authorization protocol that is widely used on the Internet. As a result, there have been studies to apply OAuth to the IoT environment as shown in Cirani et al. 2 and Emerson et al. 4 However, previous researches assign third parties to serve as the authorization server (AS). When IoT is applied to healthcare for a band worn on the wrist to measure the pulse or a cardiograph that measures the heartbeat, however, the healthcare information is very sensitive and it is not suitable to assign a third party for authentication and authorization, or it may not be easy to find a third party that is trustworthy enough to assign.
When a pulse band’s information is transmitted to a remote server, it will go through a smartphone. Therefore, this article proposes using a smartphone to authenticate and authorize an entity that accesses the healthcare information. In other words, it suggests using smartphones as the OAuth AS. Therefore, each individual carries an OAuth AS.
Also, the existing OAuth assigns big-sized service providers such as Facebook or Google to serve as the OAuth ASs and the many small-sized web services that need to register with Facebook or Google as the OAuth clients. Also, OAuth client requests the OAuth tokens from the OAuth AS and uses the OAuth tokens received to access information. However, this article proposes using smartphones as OAuth ASs. In other words, there will be millions of small-sized OAuth ASs and a few large-sized band manufacturers or hospitals will serve as the OAuth clients. It will be completely opposite to the existing OAuth system. Also, the large-sized manufacturers or hospitals cannot identify each of millions of smartphones that serve as the OAuth ASs, and the IP address of smartphone that OAuth client has to register changes constantly. Therefore, this article proposes the push OAuth where smartphones register with the OAuth clients first to push the OAuth tokens.
This article discusses the related studies in section “Related work.” Section “Problem description” defines the problem to solve, and section “personal OAuth authorization server (POAS) and push OAuth” introduces the proposed schemes. Section “Implementation” discusses the implementation for proof of concept, and section “Security and performance consideration” discusses the security considerations. Finally, section “Conclusion” concludes the article.
Related work
OAuth
In a traditional client–server authentication model, the client presents his or her credential ID and password for authentication to access the resources stored on the server. As the Internet developed, different web services have cooperated to create mash-up services. In this case, a resource holder should be authenticated by the server that stores the resource, and a third-party web application should be authorized for their access to the resource.
OAuth is the most widely used protocol that resolves the aforementioned problem without having a third party, and a resource owner (RO) shares the credentials. It allows RO to share their private resources such as photos stored in one web server with another web server without sharing the credentials. In case of OAuth, OAuth 1.0 was standardized in 2010 by IETF RFC 5894 5 and OAuth 2.0 was standardized in 2012 by IETF RFC 6749. 6 This article applies OAuth 2.0 to IoT. The basic terms of OAuth 7 are listed in Table 1.
OAuth terms.
To request an access token, the client obtains authorization from the AS. The authorization is expressed in the form of an authorization grant, which the client uses to request the access token. OAuth defines four grant types as given in Table 2. 6
OAuth grant type.
Figure 1 shows the authorization code grant’s OAuth transaction. 7 Transaction will communicate safely through transport layer security (TLS): 8
RO (user) requests a client’s web service;
Client redirects user agent to AS;
User types ID/password to AS;
AS authenticates the user;
AS redirects user agent to client and includes authorization code;
Client use authorization code to request access token form AS;
AS authenticates the client, validates authorization code, and issues access token.
Authorization code grant’s transaction.
In the seventh stage, a response will be received in the following JavaScript Object Notation (JSON) format. This article will modify the access token, so this article will call it the OAuth ticket to distinguish it from the access token. Refer to OAuth 2.06 for further definition of each item (access_token, token_type, expires_in, and refresh_token).
What is notable on OAuth 2.0 is that the stage where the client is registered is defined as out of scope on the standards. 6 Generally, a client visits the web page of AS such as Google or Facebook to register as a client and receive a client_id and a client_secret. Most scenarios for using the OAuth entail a few AS with multiple clients and multiple RO as shown in Figure 2. For example, Google becomes the OAuth AS and Google Calendar becomes the resource. The Google uses OAuth in order for the client to access Google Calendar. In other words, the resource will be stored in the centralized server. This article calls it the centralized OAuth environment.
Centralized OAuth environment.
Other related works
Cirani et al. 2 suggested an IoT-OAS framework that a third-party AS authorizes the client based on OAuth to reduce a resource-constrained IoT device’s process load in a way that IoT devices do not have the authorization logic. Cirani et al. 2 demands third-party AS to be highly trustworthy. However, it is not suitable to assign a third-party server to handle access policies for sensitive information such as physical information.
Emerson et al. 4 suggested requesting an outside service provider to access the IoT network based on OAuth. However, it is still not suitable to have an outside service provider to authorize access to sensitive information such as body measurement information.
Problem description
Application scenarios
Healthcare is one of the areas where IoT is used most widely.9,10 For example, it is or is expected to be used for various devices such as the bands that are worn on the wrist to measure the pulse and the cardiograph. The pulse band’s information will be transmitted to the band manufacturer and the information obtained by a cardiograph to the cardiograph manufacturer or the hospital. In other words, physical information will be transmitted to various sites and IoT healthcare devices will transmit the physical information to smartphones to transmit it to remote servers. That is, smartphones serve as the relay to transmit the physical information.
Physical information will be transmitted to a hospital or a healthcare device manufacturer regularly, 10 but in urgent cases, the other hospital should be able to collect it from the IoT healthcare devices on demand. 9 Also, it would be necessary for the other hospital to read the information stored in the hospital or the manufacturer. For example, the information regularly transmitted to and stored by a healthcare device manufacturer could be read by the hospital to use for diagnosis. This is shown in Table 3. Real-time information can be transmitted to the hospital regularly or read in urgently. Stored information can be read by the other hospital in urgent cases. As regular transmitting stored information to a third party, such as the other hospital, may not be suitable for security purposes, this article does not consider such scenarios. Stored information can be read by third parties only when necessary.
Information type.
Problem definition
Physical information is very sensitive and private, and it is a critical issue to protect it securely as it is sometimes collected and sold for malicious purposes, 11 so only authenticated or authorized servers can collect physical information. For this purpose, OAuth can be used that is most widely used on Internet.
When OAuth is used, it should be considered whom OAuth AS should be. As suggested by Cirani et al., 2 a third party could be assigned as an AS. However, it is still questionable as to whether it is trustworthy to have a third party authorize the client to access physical information which is very sensitive. Also, it should be considered whether it is possible to assign as an AS, a healthcare device manufacturer or a hospital. Assigning a smartphone that is possessed and directly controlled by a user as an AS is more trustworthy and can resolve the lock-in problem. Therefore, this article defines smartphones as AS. This type of AS is personally possessed, so it is called POAS. Also, a hospital or a healthcare device manufacturer becomes the client.
In this case, there are millions of ASs as shown in Figure 3, unlike the existing OAuth, and relatively fewer clients. This article calls it the decentralized OAuth environment.
Decentralized OAuth environment.
In the above decentralized OAuth environment, the client cannot identify each POAS. Moreover, POAS’ IP address changes constantly, and it is very hard for hospitals or healthcare device manufacturers to register with POAS as clients. Therefore, this article proposes that POAS registers with a client and POAS issues a ticket when registering with a client. In the existing OAuth, the client requests AS to issue an OAuth token; this article proposes a system where POAS pushes an OAuth ticket to the client without a client’s request, so this article calls it the push OAuth.
Let us discuss how to apply the four grant types of OAuth discussed in section “OAuth.” In the implicit grant type, the client is the browser. A hospital or a healthcare device manufacturer cannot be a browser. Therefore, it is not suitable. The RO password credentials grant type uses the client as the operating system or a highly reliable application program. Therefore, it is not suitable for a server-based OAuth. The client credentials grant type provides credentials to the client, but it is not suitable for a client to request information as sensitive as physical information using his or her credentials. Finally, the authorization code grant type would be suitable, because the client is authorized by AS after the RO is authenticated by AS. However, all grant types need the client to request the OAuth access token and the client cannot identify each POAS. Therefore, it is difficult to apply the authorization code grant type as is, but it should be altered for POAS to issue the OAuth ticket.
Finally, the OAuth 2.0 authorization framework 6 does not define methods that a client registers with AS. Therefore, this article proposes a method that POAS is registered with the client under the decentralized OAuth environment.
Augmented OAuth for decentralized environment
OAuth provides the privacy protection somehow in a way that the RO does not reveal his or her credential to the OAuth client from where the RO wants to get service. OAuth seems to be suitable for server–client model, where the big company such as Twitter operates huge servers and OAuth AS. In such case, the resources are stored in the server and the RO allows the client to access the resources through OAuth AS.
In the case of decentralized computing environment, the RO has the resources in his or her computers such as PC, the smartphone, or IoT device. Existing OAuth seems to be not suitable for such decentralized environment, since the resources are distributed and stored not in a big server. Also, there is no reason to entrust a trusted third party with issuing OAuth token, and there is no such totally trustworthy third party. For decentralized environment, this article proposes personally possessed OAuth AS which is wholly controlled by the RO, individual person; the RO does not need to hand over his or her access controller to the third party. In such a way, the augmented OAuth can improve the privacy of the RO. In such case, huge number of OAuth ASs existed, so this article proposes the modification of OAuth called push OAuth.
This article discusses the POAS in IoT environment and uses the smartphone as POAS. IoT environment is an example of decentralized environment. Also, the smartphone OAuth AS is a use case of POAS. Therefore, proposed scheme is not limited in the IoT environment and POAS is not limited in the smartphone.
POAS and push OAuth
Architecture
The overall architecture of issuing the push OAuth ticket is shown in Figure 4. Push OAuth, as with OAuth 2.0, uses TLS for the security. POAS pushes the OAuth ticket to the client for real-time information. For the stored information, POAS pushes the OAuth ticket to the client (OAuth Client B) and B delivers the OAuth ticket to OAuth Client A to acquire stored information. This study calls the client that collects and stores information regularly, the primary client, and the client that reads information from the primary client, the secondary client.
Push OAuth architecture.
Figure 5 shows using the access token issued by POAS for the primary client to request the information from POAS and using the access token for the secondary client to request stored information from the primary client after receiving OAuth ticket.
Access token flows.
When the primary client presents the access token to POAS, the existing HTTP cannot be used as the client’s IP changes constantly. Therefore, a messaging service such as the Google Cloud Messaging (GCM) could be used to deliver the access token to POAS.
Procedure and message formats
Figure 6 shows the procedure of how the primary push OAuth (PPOAuth) ticket is issued to the primary client to provide information. First, the URL where PPOAuth should be issued should be known by AS. This article proposes the scheme that POAS pushes OAuth ticket to the client, since the client cannot know the IP address of the smartphone which is constantly changed. Moreover, the GCM registration ID is too long for human to memorize. There is no changeable value that is the domain name of the client, so the POAS can handover the GCM registration ID to the client’s URL. For reducing the number of protocol paths, when POAS handovers the GCM registration ID, the POAS pushes OAuth ticket with GCM registration ID.
Primary push OAuth ticket flows.
In order for POAS to know URLs, this article proposes the quick response (QR) code as an example. Figure 7 shows the procedure. First, a primary client or a secondary client generates QR code with attributes listed in Table 4. Also, the user has an IoT device and installed AS application. Second, the primary client or the secondary client publishes the QR code in his or her websites. Other way to deliver the QR code to AS is that the primary client or the secondary client prints the QR code and physically handovers the printed QR code to RO. For example, the printed QR code is enclosed in the package with IoT device, or the personnel of the primary client or the secondary client gives the printed QR code. For example, the nurse handovers the printed QR code to the guardian of the patient. Once the user of AS, the smartphone, obtains the QR code, the user executes the AS application and selects the primary client or the secondary client. Then, the user makes the AS application read the QR code. The AS application will parse the QR code to obtain the attributes of QR code and store the attributes of QR code into the local database (DB). Table 4 shows the attributes of QR code.
Push OAuth architecture.
QR code attributes.
The formats of OAuth ticket are listed in Table 5. The client_id, client_secret, info_type, and redirect_url fields are added for the push OAuth and the rest is the same as the OAuth standards. The grant type of push OAuth ticket is the authorization code grant in this article, since the client is generally a web server such as a hospital web server. As listed in Table 3, it does not consider having the secondary client read the stored information regularly and there should not be a refresh_token when issuing an OAuth ticket to a secondary client.
Ticket attributes.
Table 6 lists the payload format of JSON Web Token (JWT). 12 The field added to push OAuth is resource ID (rID) and the rest complies with the JWT standards.
JWT token attributes.
As found in IETF RFC 7519, the JWT token should include a JWT header and transmitted with a signature affixed using JSON Web Signature 13 for security. The JWT header for this is {“typ”: “JWT”, “alg”: “HS256”}. JWT token applies the Header.Payload.Signature format. It shows the following JWT token format.
JWT token = ASCII(BASE64URL(UTF8(JWS Protected Header)). BASE64URL(JWS Payload)). HMAC(ASCII(BASE64URL(UTF8(JWS Protected Header)). BASE64URL(JWS Payload))). Here, ASCII() is the function to convert to the ASCII code and BASE64URL is the URL safe Base64 encoding. Also, HMAC used SHA-256 HMAC14,15 and the key is primary client’s client secret. Therefore, when an OAuth ticket is issued for the primary client, the primary client will use its client secret for verification. Also, when the secondary client presents a JWT token to access the stored information in the primary client, the primary client can use its client secret to verify whether JWT is intended to issue for him or her.
Figure 8 shows the procedure of how a secondary push OAuth (SPOAuth) ticket is issued to the secondary client and the secondary client reads the stored information from the primary client.
Secondary push OAuth ticket flows.
Implementation
To demonstrate the feasibility of the proposed push OAuth, we implemented the primary client and the secondary client using Spring Framework 3.1 and Java 1.6. Also, the POAS server is implemented using Android 6.0 (API level 23 Marshmallow). The server implements RESTful API. Primary client and secondary client communicate using the JSON format. The client and POAS exchange messages using the JSON format and use GCM 9.2.0 for the messaging service. This article uses Google messaging service which is a stable service in terms of performance and security. The analysis of Google messaging service is out of scope. The primary clients send the following GCM message regularly, and the smartphone transmits the information of the corresponding IoT device to the primary client when a GCM message is received. Table 7 shows the format of GCM message.
Messaging format.
Figure 9 shows the pages of POAS app. The first screenshot is the registration page where QR code provided by the primary client or secondary client can be read.
Screenshots of implemented personal OAuth authentication server: (a) screenshot of QR code registration for primary or secondary client, (b) screenshot of the list of registered client and IoT device, (c) screenshot of issuing PPOAuth or SPOAuth, and (d) screenshot of selecting the company for SPOAuth.
The second screenshot is the list of registered primary client or secondary client, and the third screenshot opens when the registered primary client or secondary client is clicked.
The “Issue PPOAuth” button can be clicked on the third screenshot to issue a PPOAuth ticket. When the “Issue SPOAuth” button is clicked to issue a SPOAuth ticket, the fourth screenshot opens. The fourth screenshot is where one can choose the secondary client to be issued a SPOAuth ticket.
When a client received a PPOAuth ticket or SPOAuth ticket through the registerURL, it is processed as shown in Figure 10 and should be processed as follows.
Client procedure.
Here, A.b refers to the property b of object A.
Step 1. Receive a ticket from the register URL.
Step 2. Decode the JWT Token.
Step 3. Verify whether JWT.iat + JWT.exp is greater than the current time.
Step 4. If greater, proceed to Step 5, and if smaller, close; proceed to Step 5 if the JWT token has not expired.
Step 5. Verify whether JWT.nbf is smaller than the current time.
Step 6. If smaller, proceed to Step 6, and if greater, close; proceed to Step 6 if the JWT token’s start time has passed.
Step 7. If Ticket.info_type is RealTime, proceed from Step 8.1; if StoredInfo, proceed to Step 9.1.
Step 8.1. Check whether JWT.sub is equal to the client’s realTimeInfoURL; if it is the JWT token issued to the client.
Step 8.2. Close if it is not issued to the client; if it is issued to the client, proceed to Step 8.3.
Step 8.3. Verify the signature using the Ticket.client_secret; if it is correct, proceed to Step 8.4, and if not, close.
Step 8.4. Check whether Ticket.client_id is in DB; if it is, proceed to Step 8.5 as it has already been issued and JWT token has been reissued. If not, proceed to Step 8.6.
Step 8.5. Update the existing JWT token in DB into the new JWT token and proceed to Step 8.7.
Step 8.6. Save the ticket on DB.
Step 8.7. Read ticket whose info_type is RealTime from DB.
Step 8.8. If JWT.iat + JWT.exp of ticket read from DB is greater than the current time, transmit the GCM message {code: JWT, client_id, token: JWT token} to Ticket.redirect_url. If not, transmit the GCM message {code: Refresh, client_id, token: refresh_token} and close.
Step 9.1. Check whether JWT.sub is the client’s own IP; if yes, it is issued to himself or herself, and if not, close.
Step 9.2. Attempt to communicate with Ticket.redirect_url through HTTPS.
Step 9.3. Transmit the JWT token to redirect_url.
Step 9.4. Read the result value of HTTPS communication (the result value is the stored information in the JSON format).
Step 9.5. Save the stored Info on DB.
When POAS app receives a GCM message, it should be processed as follows, as shown in Figure 11:
Step 1. Check whether the code is JWT; if yes, proceed to Step 2.1 and if not, proceed to Step 3.1.
Step 2.1. Decode a JWT token.
Step 2.2. Read the JWT token from DB using client_id.
Step 2.3. Compare whether the JWT token read matches the JWT token received.
Step 2.4. If it does not match, close as the JWT token has been altered; if it does, proceed to the next step.
Step 2.5. Check whether JWT.iat + JWT.exp is greater than the current time; if greater, proceed as it is a valid JWT token, and if not, close.
Step 2.6. Check whether JWT.nbf is smaller than the current time; if smaller, proceed as it is a valid JWT token, and if not, close.
Step 2.7. Read the client_secret with the matching client_id on DB.
Step 2.8. Check whether the signature is valid; if yes, proceed, and if not, close.
Step 2.9. Read the information that matches JWT.rID on DB to transmit information to JWT.sub and delete the existing information of the IoT device (information is read and stored from IoT device regularly).
Step 3.1. Read the refresh_token using client_id on DB.
Step 3.2. Proceed and close if the received refresh_token matches the refresh_token stored on DB.
Step 3.3. registerURL is read from DB using client_id to transmit the new JWT token to registerURL.
POAS procedure.
Security and performance consideration
Security consideration
IoT is a new technology and may encounter various security threats. Refer to Garcia-Morchon et al. 16 with regard to these.
This article will analyze first the security of PPOAuth ticket. Figure 6 shows the four following steps:
Reading QR code. The client who will receive OAuth ticket is identified through the QR code. When an IoT device manufacturer is the client, the QR code will be included in a package with the IoT device when it is purchased. When a hospital is the client, it will provide the QR code. Therefore, it can be assumed that the QR code is received from a trustworthy provider. Considering the security of QR code, the QR code can be electronically signed and a public key can be received from the hospital, or a public key can be downloaded from an IT manufacturer’s homepage. Therefore, the QR code cannot be altered and can be provided the origin authentication.
Pushing PPOAuth ticket. Pushing PPOAuth ticket can be done through TLS which provides the confidentiality of PPOAuth and the authentication of the client. What differences with OAuth 2.0 are that client_id, client_secret, info_type, and redirect_url are added to the OAuth 2.0 format for PPOAuth ticket. These fields themselves do not weaken the OAuth 2.0. Finally, the access_token is delivered with JWT signature.
Sending access token through GCM. The access_token is not protected by TLS. Considering the confidentiality of the code and the token, therefore, they would be encrypted when they sent through messaging service. It would be even secure if a message authentication code is attached for the integrity. In other words, the format can be Message = {client_id, Enc(code, token, H(code||token))}. Here, Enc refers to the secure symmetric cryptography and the key can be derived from client_secret or client_secret. Also, H is a hash function as safe as SHA-256 and || represents concatenation.
Sending information to the realTimeInfoURL. The information can be transported through TLS which provides the confidentiality of information, the message authentication of information, and the authentication of the client. Moreover, information can be attached with the signature of information, such as SHA-256 with the client secret for the authentication of the POAS.
The security of SPOAuth is analyzed as follows:
Reading QR code. It is the same as PPOAuth case.
Pushing SPOAuth ticket: The security of it is the same as PPOAuth case.
Sending access token to the primary OAuth client. It can be done through TLS. It provides the message authentication, the confidentiality of the message, and the origin authentication of the primary OAuth client. The secondary client is identified by the IP address (subject) in the JWT token.
Sending stored information. It will use TLS for authentication and confidentiality.
Performance issue
The smartphone is much powerful than constrained IoT device, so our approach can take the advantage. Also, the server which handles a lot of POAS is much more powerful than the smartphone and can be scaled out, if necessary.
The differences of our proposal with OAuth 2.0 are (1) reading QR code to get the URLs of the client, (2) pushing OAuth token, and (3) delivering access token by GCM. Sending information of IoT devices to the server is the same as just Internet communication of server–client model.
The performance of reading QR code does not show much difference with general QR code reader which reads and parses QR code except verifying the signature of QR code based on a public key cryptography, if necessary. Therefore, the performance of reading QR code is the performance of QR code reader plus the performance of the one-signature verification. Modern smartphone can easily perform the one-signature verification.
Generating OAuth token and JWT token in the smartphone is rarely done, and there is no much difference with OAuth token generation except adding additional attributes: client_id, client_secret, info_type, and redirect_url. Generating client_id needs one hash operation, and generating client_secret requires one random number generation.
When receiving the primary OAuth ticket, the client requires one JWT parsing, four comparisons, one signature validation based on HMAC, and two DB queries for getting Ticket.client_id and for saving OAuth ticket.
When receiving JWT token, the smartphone does one parsing JWT, three comparisons, three queries to local DB, and a verification of HMAC. It does not take much time in our evaluation as shown in Table 8. However, the battery of the smartphone is consumed by these operations. Therefore, the interval of sending GCM must be considered applying in the real world.
Performance evaluation.
This article evaluates the performance of the smartphone and the primary client (the server). The smartphone is Galaxy 4 with 2GB RAM, Quad-core 2.3 GHz, and Android 6.0. The primary client is 2GB RAM, Intel Xeon CPU X5670(2.93 GHz), and Centos 6.4. The result of the performance evaluation is shown in Table 8. The evaluations are the average time in seconds of 10 experimentations. The generation time of PPOAuth is measured from clicking PPOAuth generation button to just before sending PPOAuth to the primary server. The processing time to store PPOAuth into DB is measured by the time taken from receiving PPOAuth token to store PPOAuth into DB. The processing time to send information is measured by the time taken from receiving GCM message just before sending information to the primary server. The evaluations show that our approach does not decrease the performance much.
Conclusion
This article proposed POAS and push OAuth that expand OAuth 2.0 for users to manage the authorization for the client to access information generated by their IoT devices without a third-party AS server. The proposed push OAuth and POAS can improve IoT security as users can manage their own information. Also, POAS and push OAuth were implemented to check the feasibility. As discussed in the “Implementation” section, the OAuth ticket can be issued conveniently using the POAS app and easy to use in everyday life. Finally, the security of the proposed scheme was analyzed to discuss the security.
The contributions of this article are as follows: (1) first, proposing POAS for more trustworthy IoT environment and solving lock-in problem by third-party AS, (2) identifying decentralized OAuth environment, (3) proposing push OAuth to apply OAuth to decentralized OAuth environment, (4) proposing the utilization of messaging service to solve the problem that POAS’ IP address is always changing, and (5) implementing the proposed scheme to check the feasibility.
The proposed POAS and push OAuth will increase the trust and the security of IoT.
Footnotes
Academic Editor: Minglu Jin
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 supported by the MSIP (Ministry of Science, ICT and Future Planning), Korea, under the ITRC (Information Technology Research Center) support program (IITP-2016-H8501-16-1008) supervised by the IITP (Institute for Information & communications Technology Promotion). And this work was supported by the Institute for Information & communications Technology Promotion (IITP) grant funded by the Korean Government (MSIP; no. R-20160222-002755, Cloud-based Security Intelligence Technology Development for the Customized Security Service Provisioning).