See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/335686500

Securing Web APIs with OAuth 2.0

Article · May 2014

CITATIONS READS

0 490

3 authors, including:

Atallah Khedrane
Rakmana
1 PUBLICATION   0 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Atallah Khedrane on 08 September 2019.

The user has requested enhancement of the downloaded file.

Securing Web APIs with OAuth 2.0
By Atallah khedrane1, Hamza Salmi2, Bernaoui Abdelhamid3.
Reviewed by Mr. Mohamed Salim Meflah4.

Computer Science & IT Department.

University Kasdi Merbah Ouargla, Algeria

1 atallah.khedrane@gmail.com, 2 samihh85@gmail.com
3 hamidbernaoui14@gmail.com 4 , meflah.med.salim@gmail.com

Abstract. In this note we will explore ways to secure APIs after explosion of
internet and the large amount of sensitive data and applications existing in
the web today, we focus on OAuth 2.0, that is a modern standard protocol
based on delegated authorizations, highlighting its mechanism, features,
the different methods of authorizations and when and how to use them. We
built an API server with OAuth integrated in, and a client application that
demonstrate the most common authorization grant type, in order to
simulate the data consuming case and how it affects by OAuth.

Keyword: api, rest, authorization, oauth, security, open platform.

‫ سنبحث في هذه المذكرة سبل تأمين الواجهات البرمجية على الويب بعد التزايد‬.‫خلاصة‬
‫ وسنركز في بحثنا هذا على‬،‫المهول للبيانات الشخصية والتطبيقات على الشبكة‬
‫ والذي يعتمد على مبدأ التفويضات مبرزين‬،OAuth 2.0 ‫البروتوكول الحديث والمعياري‬
‫ وأنجزنا خادم‬.‫ أنواع التفويضات فيه وحالات وكيفية استخدامها‬،‫ خصائصه‬،‫مبدأ عمله‬
‫ وتطبيق زبون يجسد أهم أنواع‬،‫واجهة برمجية على الويب مدمجا به هذا البروتوكول‬
.‫التفويضات فيه لاستعراض عملية استخراج البيانات وتأثيرات البروتوكول على سيرها‬

.‫ منصات مفتوحة‬،‫ أمان‬،‫ أووث‬،‫ تفويض‬،‫ واجهة برمجية‬:‫كلمات مفتاحية‬

1
1. Introduction
Many organizations use multiple software systems for management,
accounting, shipping…etc. Different software systems often need to exchange
data with each other, when these different software might be built with different
programming languages, so there is a need for a method of data exchange that
doesn't depend upon a particular programming language. This need exist in web
applications also, especially in the era of social networks.

By this openness the API born in these systems, which brought to us the ability
to do tasks inside a system via other system without real human intervention,
many technics developed to exchange data between APIs, like WSDL, SOAP and
REST that pattern based on HTTP as data transfer layer, and for that named Web
APIs.

“Web API adoption in both consumer and enterprises has gone beyond
predictions. It has become the coolest way of exposing business functionalities to
the outside world. Both your public and private APIs, need to be protected,
monitored and well managed” - [1].

API also adopted by the large systems, by developing the kernel as API server
that extend with different components and modules via APIs, this design also
known as API-First design, which is very useful on large scale applications
development, and when targeting many platforms like Windows, Linux and iOS,
or many devices (PC, MAC and Mobiles). [2] [3] [4]

Fig. 1. API-First Design example

2
 1.1. How Web API is secured?

The web API changed the interaction from user-web service to become client
application-user-web service. So we have a third party here, which represented
by the client applications. And this expose an old challenges with new complexity,
like authentication & authorization.

In the old school the client application act as real user by using its credentials
for authentication process, so user have to share his password with a third party
applications, this method create some problems and limitations:
 Third-party applications are required the store the user's credentials
for future use, typically a password in clear-text. [5]
 Servers require passwords for API authentication, this prevent the
improvement of user's account security with technologies like
CAPTCHAs or multifactor authentication. [5]
 Client application gain overly broad access to the user's protected
resources, leaving him without any ability to restrict duration or
access to a limited subset of resources. [5]
 Users cannot revoke access to an individual application without
revoking access to all used applications, and must do so by changing
the password. [5]
 Compromise of any client application results in compromise of the
end-user's password and all of the protected data. [5]

For these reasons this simple method has been abandoned in the big IT
companies such as Google & Yahoo. But they were developed their own solutions,
by switching from Authentication between service and User, to a Delegated
Authorization inside the service and granted by User for client application. [6]

 AuthSub from Google [7]

Fig. 2. Google’s AuthSub Flow

3
 “AuthSub has been officially deprecated as of April 20, 2012. It will continue
to work as per our deprecation policy, but we encourage you to migrate to OAuth
2.0 as soon as possible.”- [7].

 BBAuth from Yahoo [8]

Fig. 3. Yahoo’s BBAuth Flow

"You can think of OAuth as a standards-compliant method for achieving what

BBAuth does. While BBAuth is a Yahoo specified method for authorization, OAuth
is widely supported by a number of companies, so you won't have to learn
another proprietary method for authorization. Another key difference between
BBAuth and OAuth is that OAuth supports applications not only on the Web but
also on the desktop and mobile phones, whereas BBAuth only supports Web-
based applications."- [8].

“With these new protocols, an application would redirect users to an

authorization page on the provider's. Users would log in to their accounts and
grant access, and then the application would get a token to use for accessing the
user's data. While this solved some security issues, it also created costs for
developers. Developers integrating with multiple major API providers had to learn
and implement several web-based authorization protocols in their applications.
Startups building new APIs were not comfortable implementing the proprietary
auth schemes, nor developing their own custom schemes, which might introduce
security vulnerabilities. Instead, these startup and major API providers decided
that they needed to create a standard protocol to improve consistency for these
web-based authorization flows”- [9].

4
 1.2. OAuth 1.0

OAuth is open standard for authorization. It make the ability for web services
to provides client applications a secure delegated access to protected resources
on behalf of those resources owner without sharing their credentials. More
generally, OAuth creates a freely-implementable and generic methodology for
API authentication.

Fig. 4. OAuth 1.0 Flow

OAuth aims to unify the experience and implementation of delegated web

service authentication into a single, community-driven protocol. OAuth builds on
existing protocols and best practices that have been independently implemented
by various companies. An open standard, supported by large and small providers
alike, promotes a consistent and trusted experience for both application
developers and the users of those applications. [9]

OAuth Discussion group was created in April 2007 to write the draft proposal
for an open protocol. In October 2007 the OAuth Core 1.0 final draft was released.
And brought to IETF for further standardization work. The OAuth Core 1.0 Revision
‘A’ specification has been published to address a session fixation security flaw
discovered in April 2009 - [10]. The OAuth 1.0 Protocol was published as RFC 5849,
as informational Request for comments in April 2010. [11]

5
 OAuth 1.0 required cryptographic signatures be sent with each API request to
verify the identity and authorization of the client. Cryptography is challenging for
the casual developer to grasp and also challenging for even highly skilled
engineers to master. This led to plenty of developer frustration and, presumably,
less adoption of APIs then could have been achieved with an easier authorization
protocol. [9]

2. OAuth 2.0
OAuth 2.0 is the next evolution of the OAuth protocol, but is not backwards
compatible with OAuth 1.0. OAuth 2.0 focuses on client developer simplicity while
providing specific authorization flows for web applications, desktop applications,
mobile phones, and living room devices. The specification and associated RFCs
are developed by the IETF OAuth working group, the main framework was
published in October 2012 as a draft. [11]

OAuth is an open protocol that allows users to share their private resources
stored on one site with another site without having to hand out their username
and password.

Fig. 5. OAuth 2.0 simplified scheme

6
 OAuth2’s current specification removes signatures, so you no longer need to
use cryptographic algorithms to create, generate, and validate signatures. All the
encryption is now handled by TLS, which is required. [5]

2.1. Differences from OAuth 1.0

OAuth 1.0 was largely based on existing proprietary protocols such as Yahoo's
"BBAuth" and Google's "AuthSub". The result represented the best solution based
on actual implementation experience. However, after several years of working
with the protocol, the community learned enough to rethink and improve the
protocol in three main areas where OAuth 1.0 proved limited or confusing: [9] [6]

 Authentication and Signatures

The majority of developers' confusion and annoyance with OAuth 1.0 was due
to the cryptographic requirements of signing requests with the client ID and
secret. Losing the ability to easily copy and paste cURL examples made it much
more difficult to get started quickly. OAuth 2.0 recognizes this difficulty and
replaces signatures with requiring HTTPS for all communications between
browsers, clients and the API. [9] [5]

 User Experience and Alternative Authorization Flows

OAuth includes two main parts, obtaining an access token, and using the
access token to make requests. OAuth 1.0 works best for desktop web browsers,
but fails to provide a good user experience for native desktop and mobile apps
or alternative devices such as game or TV consoles. OAuth 2.0 supports a better
user experience for native applications, and supports extending the protocol to
provide compatibility with future device requirements. [5]

 Performance at Scale
As larger providers started to use OAuth 1.0, the community quickly realized
the protocol does not scale well. Many steps require state management and
temporary credentials, which require shared storage and are difficult to
synchronize across data centers. OAuth 1.0 also requires that the API server has
access to the application's ID and secret, which often breaks the architecture of
most large providers where the authorization server and API servers are
completely separate.
OAuth 2.0 supports the separation of the roles of obtaining user authorization
and handling API calls. Larger providers needing this scalability are free to
implement it as such, and smaller providers can use the same server for both roles
if they wish. [5]

7
 2.2. Authorization Grant Types

The first step of OAuth 2.0 is to get authorization from the user. For browser-
based or mobile apps, this is usually accomplished by displaying an interface
provided by the service to the user. OAuth 2.0 provides several "grant types" for
different use cases. The grant types defined are:

 Authorization Code (for apps running on a web server): Web server apps
are the most common type of application we encounter when dealing with
OAuth servers. Web apps are written in a server-side language and run on a
server where the source code of the application is not available to the public.
[9] [5]

 Implicit (for browser-based or mobile apps): Browser-based apps run

entirely in the browser after loading the source code from a web page. Since
the entire source code is available to the browser, they cannot maintain the
confidentiality of their client secret, so the secret is not used in this case. [9] [5]

 Password (for logging in with a username and password): OAuth 2.0 also
provides a "password" grant type which can be used to exchange a username
and password for an access token directly. Since this obviously requires the
application to collect the user's password, it should only be used by apps
created by the service itself. For example, the native Twitter app could use this
grant type to log in on mobile or desktop apps. [9] [5]

 Client credentials (for application access): In some cases, applications may

wish to update their own information such as their website URL or application
icon, or they may wish to get statistics about the users of the app. In this case,
applications need a way to get an access token for their own account, outside
the context of any specific user. OAuth provides the client credentials grant
type for this purpose. [9] [5]

8
 2.3. Roles and Flows

OAuth defines four roles:

 Authorization Server (AS)
The server issues the authorization codes and access tokens to the clients for
user's data hosted by resources server. [5]
 Resources Server (API)
The resource server is server hosting user's protected data. This is typically an API
provider that holds and protects data. [5]
 Client (Application)
The client is the application that is attempting to get access to the user's data via
API requests. It needs to get authorization from the user before it can do so. [5]
 User (Resource Owner)
The resource owner is the person who is giving access to some portion of their
data. [5]

Authorization code grant (flow illustrated in Fig. 6) is the most common grant
used by client applications.

Fig. 6. Authorization code Flow in OAuth 2.0

9
3. Implementation
To simulate OAuth 2.0 flow, we used PHP to create an API web server with
built-in OAuth 2.0. This server host users’ accounts. And we built also an API client
application (server-side application) to use it in Authorization code grant type.
The Authorization Code flow is as follows:
1. The Client Application redirects the user to the API server acting as an
Authorization Server to authenticate and authorize the Client Application
to access data on their behalf. [5]
2. After the user approves access (as shown in Fig. 6), the Client Application
receives a callback with an authorization code. [5]
3. After obtaining the authorization code, the Client Application passes back
the authorization code to obtain an access token response. [5]
4. After validating the authorization code, the API server passes back a
token response to the Client Application. [5]
5. After the token is granted, the Client Application requests the protected
data. [5]
6. The API server validates the access token, then serves the request and
respond data to client. [5]

Fig. 7. Authorization Approve Form

10
4. Conclusion
Lot of security experts found that OAuth 2.0 is not safe by-default. That’s
because it’s a framework more than protocol, so OAuth 2.0 implementations are
less likely to be naturally interoperable with any other OAuth 2.0 implementations.
[12] [13] [14]

OAuth 2.0 had strong opposition to dropping requests signing requirement,

including by Eran Hammer-Lahav (editor of the specification). Engineers often
have to strike a delicate balance between security and usability, and this case is
no different. [9] [13]

Despite the specification still draft, the Oauth 2.0 make a revolution in the
web application development, we can take the jolicloud.com as example, which is
web service founded by Tariq Krim (Algerian originally). And integrate (via OAuth)
more than 100 web services in one cloud platform. We can notice that OpenID
Connect (Federated Authentication Protocol) has built upon OAuth 2.0, so it
became a framework for building protocols.

11
 References

[1] P. Siriwardena, Advanced API Security, Springer, 2014.

[2] E. Anuff, "API-Centric Architecture," 8 Mai 2014. [Online]. Available:
https://blog.apigee.com/detail/api_centric_architecture_all_development_is_api_d
evelopment. [Accessed 22 Mai 2014].
[3] IBM, "The API-Driven Business Model," 2013. [Online]. Available:
http://www.ibm.com/systems-of-interaction.
[4] M. v. d. Schee, "API first architecture or the fat vs thin server debate," 13 October
2013. [Online]. Available: http://www.leaseweblabs.com/2013/10/api-first-
architecture-fat-vs-thin-server-debate/. [Accessed 22 Mai 2014].
[5] D. Hardt, "RFC 6749 - The OAuth 2.0 Authorization Framework," October 2012.
[Online]. Available: http://tools.ietf.org/html/rfc6749. [Accessed 20 April 2014].
[6] A. Parecki, "An Introduction to OAuth 2," in Esri International User Conference,
California, 2013.
[7] Google, "AuthSub for Web Applications," [Online]. Available:
https://developers.google.com/accounts/docs/AuthSub. [Accessed 23 April 2014].
[8] Yahoo, "OAuth Compared to BBAuth," [Online]. Available:
https://developer.yahoo.com/oauth/guide/oauth-bbauth.tml. [Accessed 26 April
2014].
[9] R. Boyd, Getting Started with OAuth 2.0, O'reilly Media Inc, 2012.
[10] OAuth Working Group, "OAuth Security Advisory: 2009.1," 23 April 2009.
[Online]. Available: http://oauth.net/advisories/2009-1/. [Accessed 14 Mai 2014].
[11] Wikipedia, "OAuth - Wikipedia, the free encyclopedia," [Online]. Available:
http://en.wikipedia.org/wiki/OAuth. [Accessed 22 April 2014].
[12] E. Homakov, "Egor Homakov: OAuth1, OAuth2, OAuth...?," 1 March 2013.
[Online]. Available: http://homakov.blogspot.jp/2013/03/oauth1-oauth2-
oauth.html. [Accessed 23 April 2014].
[13] E. Hammer, "Eran Hammer-Lahav’s blog:," [Online]. Available:
http://hueniverse.com.
[14] M. Lemos, "Is Your OAuth 2.0 Application Secure? - PHPClasses," 26 Mai 2014.
[Online]. Available: http://www.phpclasses.org/blog/package/7700/post/4-Is-
Your-OAuth-20-Application-Secure.html. [Accessed 26 Mai 2014].
[15] R. Boyd, "Google I/O 2012 - OAuth 2.0 for Identity and Data Access," Google,
Moscone Center, San Francisco, 2012.
[16] L. J. Mitchell, "Implementing OAuth," [Online]. Available: http://lornajane.net.

12

View publication stats