Personal OAuth authorization server and push OAuth for Internet of Things

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, ¹ 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. ³ 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. ² and Emerson et al. ⁴ 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 ⁵ and OAuth 2.0 was standardized in 2012 by IETF RFC 6749. ⁶ This article applies OAuth 2.0 to IoT. The basic terms of OAuth ⁷ are listed in Table 1.

Table 1.

OAuth terms.

Client	The third-party service to access the restricted resource and asking for authorization.
Resource owner (RO)	The entity that owns the resource the client access. This is usually the web user.
Resource server (RS)	The service that provides access to the resource requested from the client.
Authorization server (AS)	The service that authenticates the resource owner and performs the authorization checks. This may be the same as RS.
Access token (AT)	A piece of data the AS issues that lets the client request access from the RS.

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. ⁶

Table 2.

OAuth grant type.

Authorization code grant	The client is a third-party web service and the client request access to the restricted resource on behalf of RO.
Implicit grant	The client is typically implemented in a browser using a scripting language such as JavaScript.
Resource owner password credentials grant	This type is suitable in cases where the resource owner has a trust relationship with the client, such as the device operating system or a highly privileged application
Client credentials grant	The client can request an access token using only its client credentials. In this case, the client might be an application.

Figure 1 shows the authorization code grant’s OAuth transaction. ⁷ Transaction will communicate safely through transport layer security (TLS): ⁸

1. RO (user) requests a client’s web service;

2. Client redirects user agent to AS;

3. User types ID/password to AS;

4. AS authenticates the user;

5. AS redirects user agent to client and includes authorization code;

6. Client use authorization code to request access token form AS;

7. AS authenticates the client, validates authorization code, and issues access token.

Figure 1.

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.0⁶ 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. ⁶ 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.

Figure 2.

Centralized OAuth environment.

Other related works

Cirani et al. ² 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. ² 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. ⁴ 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, ¹⁰ but in urgent cases, the other hospital should be able to collect it from the IoT healthcare devices on demand. ⁹ 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.

Table 3.

Information type.

	Transmitted regularly	Transmitted urgently
Real-time information	O	O
Stored information	X	O

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, ¹¹ 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., ² 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.

Figure 3.

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 ⁶ 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.

Figure 4.

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.

Figure 5.

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.

Figure 6.

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.

Figure 7.

Push OAuth architecture.

Table 4.

QR code attributes.

CompanyName	Name of hospital or healthcare device manufacturer
CompanyType	Primary for primary client and secondary for secondary client
registerURL	URL to push OAuth ticket
realTimeInfoURL	URL to transmit real-time information when access token is received through GCM
storedInfoURL	URL to send stored information from the primary client when secondary client requests the primary client
ResourceID	IoT device’s identifier; not contained in the QR code of the secondary client

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.

Table 5.

Ticket attributes.

client_id	The identifier to identify a client that follows the OAuth standards. This article applied the hash (client’s URL | resource ID)
client_secret	The secret key to authenticate the client that follows the OAuth standards
token_type	Token type can be the bear type that follows the OAuth standards
access_token	This article uses the JSON Web Token (JWT) token
expires_in	The valid time shown in seconds that follows the OAuth standards
refresh_token	The token used to reissue the access_token when it is expired; follows the OAuth Standards
info_type	A field added as it is not in the OAuth standards; it has values called “RealTime” to acquire real-time information and “Stored” for stored information
redirect_url	A messaging identifier such as GCM registration ID for the primary push OAuth ticket; in the secondary push OAuth ticket, the URL to be used by secondary client to request stored information from the primary client

Table 6 lists the payload format of JSON Web Token (JWT). ¹² The field added to push OAuth is resource ID (rID) and the rest complies with the JWT standards.

Table 6.

JWT token attributes.

iss (issuer)	The ID that identifies the issuer
sub (subject)	The subject that reads the information. It is the realTimeInfoURL value when issued to the primary client and the IP address of secondary client when issued to the secondary client
aud (audience)	Aud is the receiver of the JWT token. POAS’ ID is the audience when issued to the primary client and the primary client’s storedInfoURL becomes the audience when issued to the secondary client
exp (expiration time)	The valid time from the time of issue in seconds
nbf (not before)	JWT token is not valid before the valid time
iat (issued at)	The time JWT is issued
jti (JWT ID)	JWT identifier
rID (Resource ID)	The ID of IoT device that generates information

As found in IETF RFC 7519, the JWT token should include a JWT header and transmitted with a signature affixed using JSON Web Signature ¹³ 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 HMAC^14,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.

Figure 8.

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.

Table 7.

Messaging format.

Code	JWT or Refresh
client_id	client_id
Token	JWT token or refresh_token

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.

Figure 9.

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.

Figure 10.

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.

Figure 11.

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. ¹⁶ with regard to these.

This article will analyze first the security of PPOAuth ticket. Figure 6 shows the four following steps:

1. 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.

2. 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.

3. 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.

4. 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:

1. Reading QR code. It is the same as PPOAuth case.

2. Pushing SPOAuth ticket: The security of it is the same as PPOAuth case.

3. 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.

4. 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.

Table 8.

Performance evaluation.

Process	Average time (s)
Generation time of PPOAuth	0.1605
Upon receiving PPOAuth, processing time to store it in DB	0.0262
Upon GCM processing time before sending information	0.02

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.