Key Differences between the OpenID and OAuth: Method to an Enhancement of the Trust in OpenID

OpenID comparison with OAuth2.0 and enhancement of the proof-of-rightful-possession limitation

Abstract—

The most used Authentication and Authorization protocols/frameworks nowadays are OAuth and OpenID. Both could provide to unrelated servers and services an Authentication and Authorization services that ensure the security and privacy of the user to avoid identity threats and the privacy of the Identity which is a critical principle that needs to be ensured in any Identity and Access Management system. Each protocol has a main focus on a particular service rather than the other, which implies confusion to differentiate between the two protocols in the implementation practices. In this paper will focus in three main parts, firstly present an explanation of both protocols/frameworks which will derive to the key differences between the OpenID and OAuth. Secondly a contribution of the paper is to define the limitations of both protocols/frameworks, Lastly briefly recommend a method to an enhancement of the trust in OpenID.

Keywords—OAuth, OpenID, Authentication, Authorization, Privacy.

Introduction

The Identity and Access Management is the main base of Privacy in providing the control of granting and revoking the permission of the access to a resource. The main goal of implementing the Identity and Access Management is to ensure the confidentiality of the entity and to prevent the unauthorized access as well as limiting the access to only “need to know” principle and other privacy principles.

In traditional client-server authentication model the user’s credentials has to be provided to the third-party application in order to access the a resource which will create a critical risks related to the identity and privacy such as storing the user credential in the third-party server, There is no limitation of the resource access, The access could not be revoked anytime by the user, And any risks related to the third-party will be inherited to the user identity.

In order to address these related issues a Federated Identity management has been developed. Oauth and OpenID are the most popular example of a federated identity management for Authentication and Authorization services.

This paper is divided into four sections. The first section is an Introduction of the paper which explained the purpose in general and our approach of the paper. The second section contains the Background which will discuss the basics of the discussed terminologies. The third section contains a Analysis which include the results and the work of the paper. Finally, section four have a Conclusion and discussion of the future direction of the paper.

Background

Federated Identity

Federated Identity is the ability to use a single identity across several identity management systems by allowing participated entities to facilitate authentication requests and share particular identity attributes.

It support that the SP-issued identity to be linked with the Idp-issued identity which provide a single sign on to the user that allowed the use to access multiple services with no further logins within a Circle of Trust (CoT).

The Identity not considered to be referred to only people, it could be an identity of any object in the system, and an Identity Federation is linked with the entity which could be used to authenticate in one domain and access multiple domains that have a mutual trust.

Most major Federated protocols are OAuth and OpenID which will be discussed in this paper.

Oauth protocol

Oauth is “An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.”.

Oauth is an Authorization framework that act as a key provided from the resource owner for a third-party application to obtain a specific access to an HTTP service on behalf of the resource owner either by a direct approval from the resource owner to the HTTP service or allowing the application itself to obtain the access. This key called “Access Token” which will be used by the third-party application to access the resource. This Access Toke doesn’t provide any information about who the owner is and how its authenticated, it act as a delegation the a the resource owner “Delegator” delegates a right to access specific resources to a third-party application “Delegatee” by the Access Token that provided by the Identity provider.

OAuth general protocol flow have three main components and they’re Client (third-party application), Resource Owner (The user), Authorization Server which include the Resource Server (Identity Provider).

The Client will request an Authorization Request from the Resource Owner, which could be directly or indirectly through Authorization Server (intermediary).

The Resource Owner will provide the Authorization Grant which is a credential representing the resource owner and expressed using one of the below grant types:

• Authorization code: The grant use of authorization server as an intermediary between the client and resource owner.
• Implicit: The grant use an implemented client’s browser using a scripting language such as JavaScript.
• Resource owner password credentials: The resource owner credentials.
• Client credentials: The client credentials (The client is also the resource owner).

Extension mechanism for defining additional grant types.

• The Client will provide the Authorization Grant to the Authorization Server after authenticating in order to request and Access Token.
• The Authorization Server will authenticate the Client and validate the Authorization Grant to provide the Authentication Token.
• The Client will request the resource from the Resource Server using the provided Access Token.
• The Resource Server will validate the Access Token, and if it is valid will provide the requested resource to the Client.

OpenID protocol

OpenID “allows you to use an existing account to sign in to multiple websites, without needing to create new passwords”.

Due to the high use of the Internet in various areas of life. As most of the people in the world use many web services such as e-mail and access to government, non- government, commercial and other sites to obtain the services provided to them. This increase in the use of web services led to the need to provide more user authentication services to identify the real user and provide a high degree of confidentiality of his identity. Therefore, it has become very popular to use passwords associated with usernames to accurately identify users of web services. Due to the fact that most of the web services are from different sources, this has led to the user having many passwords and user names, which in turn leads to many problems, including choosing easy-to-remember passwords or typing them in places easily accessible by others. By using an OpenId, central user identity management is done in many services, where an OpenId provides a central authentication process by a trusted party by users and service providers, usually known as the Idp.

OpenID permits users utilizing same password to access many resources (e.g. websites) as Single Sign On (SSO). The identity provider is responsible for detecting malicious websites that hack the customer’s identity. The customer simply communicates his cardinalities to the website to the provider. It is also considered a standard mechanism for decentralization authentication developed by the OpenID Foundation [, ,]. So the user logs into applications without entering a username and password. Users have various passwords for various websites, therefore the user needs an effective management system to deal with these passwords for related websites.

The first version of OpenID was produced in 2005, by the OpenID company. Then after two years, the foundation produced the second version of OpenID in which it was released, the latest being 2.0. The OpenID Foundation cooperates with many companies supporting this project (e.g., IBM, Microsoft, Google, PayPal, and VeriSign) [ ]

There are several using for OpenID in securing applications such as [ ].

OpenID in Mobile Information Management and bring-your-own-device (BYOD).

OpenID in IOT the Internet of Things.

Management a list of account and passwords.

The framework for Open ID consists of the following components:

• User – a user using OpenID to access Internet applications
• Service Provider (SP) – website requested by the end user who called the server provider
• Identity Provider (IdP) – where the cardinality for user is stored

User request to Access a service or resource in Service Provider or (or RP) to access a specific website

Service Provider or (or RP) requires user Authentication and asks for the user’s OpenID identifier.

So the Service Provider or (or RP) shows the OpenID login page for the User.

Then the Service Provider or (or RP) discover the IdP through the OpenID user login page.

The Service Provider or (or RP) redirects the authentication request for user to the IdP site by using HTTP.

The User are then Authenticated by the IdPAfter that, the IdP redirects the authentication response for user to the Service Provider or (or RP) site by using HTTP.

Then the Service Provider or (or RP) verifying the response

Finally, the RR (or SP) Authenticate the User and granting the user permission for the requested service.

Analysis

OAuth

OAuth provides a layer of Authorization and separate the unauthorized access to the application. More specifically OAuth works based on the implementation of Delegation based on the concept of the Scopes and these scopes are used to request the claims and it’s not used to validate an access, And in OAuth the identity of the user will be provided by the Authorization server.

Using OAuth as an Authentication layer is an invalid practice to do as the Access Token is not intended to validate the user identity and the token does not have a security measures which ensure the validity of the user and instead of that, its responsible to provide an authority to use a particular resource without referring to the identity of the requester identity.

Since OAuth is responsible to grant a resource access without referring to the identity. Therefore, there is no use of Pseudonyms.

The OAuth based on Scopes which could be requested by the Client. Which used to limit the access to a resources and the Client could request one or more Scopes.

OAuth is considered a Federated Identity as its allowing participated entities for requesting to share particular identity attributes between multiple domains within a Circle of Trust (CoT).

But as it’s providing a delegation framework which focuses on Authorization, it’s not providing a Single Sing On (SSO).

The message format using in OAuth is through JSON files.

And it provide a single Proof-of rightful possession which is Bearer.

OpenID

OpenID provides a layer of Authentication that allow the user to have a global identity which can be used to access multiple services providers. And it supports the entity to request an access website by verifying the identity of the entity by the Identity Provider. OpenID allows entities to login in different websites with the same referred identity and password. Moreover, OpenID could support the use of authorization by providing attribute exchange framework which allow two main operations fetch (for requesting an attribute) and store (for updating an attribute).

OpenID help the user to manage its credentials for different websites through a single OpenID identity, which the SP and Idp are referred to. Therefore, there no use of Pseudonym.

OpenID is based on the claims of the user that provided to the authentication process.

OpenID could be partially considered a Federated Identity as it’s allowing participated entities to facilitate authentication requests across multiple domains within a Circle of Trust (CoT). Which derived that its provide a Single Sign On (SSO).

The communication message format used in OpenID is through JSON files.

OpenID does not provide any Proof-of-rightful-possession which considered as a critical limitation.

OpenID Connect

As OAuth considered to be an Authorization service and OpenID is an Authentication protocol. A combination of the two protocols have been integrated as OpenID connect on top of the Oauth to provide bot Authentication and Authorization.

OpenID Connect allows a service provider (Relying Party) to select identity providers in two ways. First selecting from registered identity providers or allowing RP to discover it. In OpenID connect the security communication between OP and SP through a secure token which is stored in JSON file.

The framework for Open ID consists of the following components:

• End user – a user using OpenID to access Internet applications
• Relying party (RP) – website requested by the end user who called the server provider
• OpenID Provider (OP) – where the cardinality for user is stored.

The Relying party (RP) will request an Authentication for the End-User from the OpenID Provider (OP)

The OpenID Provider (OP) will perform an End-User Authentication based on Relying party (RP) request and take out the Authorization.

The OpenID Provider (OP) will provide an Authentication Response to The Relying party (RP) with the Token.

The Relying party (RP) by will request (with Token) the UserInfo for the End-User from the OpenID Provider (OP)

Finally, the OpenID Provider (OP) will provide an UserInfo Response (contain claims) to The Relying party (RP).

OAuth and OpenID comparison

As an OAuth and OpenID both could considered as a Federated Identity protocols and they’re both provide Authentication and Authorization or could work together to provide both services which create a difficulties to distinguish between them.

In this section the paper will consider some of the confused criteria’s to differentiate between these protocols/frameworks.

And to summarize above analysis, below table provide the differences between the OAuth and OpenID:

Comparison OAuth OpenID

Main service Authorization Authentication

Pseudonym No No

Based on Scopes Claims

Federated Identity Yes Yes

Single Sign On (SSO) No Yes

Message format JSON file JSON file

Proof-of-rightful-possession bearer Not supported

.. .. The Limitations of OAuth and OpenID

The limitations of OAuth can be described as follow:

Does not support Authentication and SSO.

A malicious Client (Third-party application) could redirect the Resource Owner (User) to a fake Authorization Server (IdP).

In implicit grant type, the access token is transmitted in the URI, which can exposed. Also it depends on browser using a scripting language which have many security vulnerabilities.

In Resource owner password credentials grant type, The client has access to user credentials.

In Public Client type, There is no secrets, URL hijacking could happen.

OpenID has several security flaws and disadvantages [ ]. Typically, end-users, RR and IDP are adversely monitored to falsify their data and information in order to obtain security information. Moreover, if the token is stolen or sniffed, it will be replayed [ ]. We can summarize the limitations as follows:

The man in the middle (attacker) can keep track for RP, OpenID provider and user behavior through authentication requests and response which lead to violate the security of user. Also fake RP can lead or redirect the user to malicious websites. Also, in OpenID document has vulnerability in declaring universal unique identifier, this leads to a violation of privacy.

Users have several distinct attributes from different provider, these attributes can be aggregate to enable user to enter multiple resource, the OpenID not support full aggregation so each session required Idp.

The proof-of-rightful possession is not supported by OpenID, increasing the probability for stolen token and then compromise the RR and IdP.

Proof-of-rightful possession

As an OpenID is an authentication protocol that depends on the security token, it has a main limitation which was discussed earlier that it does not support any proof-of-rightful-possession methods, which increasing the risk of an attacker to use a stolen security token to log-in to an SP.

Our recommendation of improvement in this protocol/framework the level of trust from the user and Identity provider point of views which is to use a signed certificate by a Certificate Authority (CA) that ensure the user and the Idp by a mutual authentication cryptography keys.

The Certificate Authority (CA) is an entity that responsible to issue a digital certificate. And the owner of this certificate will have a public key that the CA could certified its identity.

In this method the user will have a public key that could be used to proof its rightful to the domains in circle of trust by a third party Certificate Authority which avoid the potential risk of an attacker to stole the access token.

Conclusion

To conclude, there’re two main services in Identity and Access Management protocols/frameworks which they’re Authentication and Authorization.

The most popular protocols/frameworks which were discussed are OAuth and OpenID.

OAuth more focus on Authorization rather than Authentication as it provide a delegation mechanism to allow an entity to provide an authority of access it’s resources.

While OpenID is more focused on Authentication but it provide an Authorization service but not as a common practice.

And to provide a complete Identity and Access management protocol/framework for Authentication as well as Authorization, an OpenID connect developed to provide Authentication on top of the OAuth.

OAuth and OpenID have a similarity in some aspects and differences of the main provided service as well as other criteria.

Both protocols/frameworks have a current limitations and security vulnerabilities that could be enhanced in the future. One of the main limitation has been discussed is the proof-of-rightful possession which has a potential enhancement by using a certificate authority to provide a level of trust of the user to avoid any stolen token.