Security Analysis on Development of an

Application using Open Authorization (OAuth)

1st Raghu Vardhan Chakali 2nd Sai Sandeep Ponna 3rd Sri Janani Ramesh
Master of Computer Science Master of Computer Science Master of Computer Science
University of New Brunswick University of New Brunswick University of New Brunswick
raghuvardhan.chakali@unb.ca saisandeep.ponna@unb.ca sri.janani.ramesh@unb.ca

4th Venkata Sai Abhishek Regulagedda

Master of Computer Science
University of New Brunswick
rvsabhi.99@unb.ca

Abstract—"Open Authorization" (OAuth) enables a website
or application to utilize users’ credentials to access resources
of other applications. Proper Encryption standards are needed
to exchange the access tokens between the servers. In this
project, We propose a solution for an android application to
communicate with the resource owner to get the third-party
tokens via the Application Programmable Interface (API) key.
While transferring the key between the resource owner and client
it is necessary to encrypt and decrypt it. In order to provide
security, We added Encrypted shared preferences instance to
secure the data stored in shared preferences.
Index Terms—API key, end-to-end encryption, Secure OAuth
I. I NTRODUCTION
The Open Authorization 1.0 protocol is identified through
RFC5848 [6] and the Open Authorization 2.0 protocol
is identified through RFC6749 [6] which obsoletes its
predecessor that allows an application to access a resource
usually an entity owned by a human user and authorizes a
third-party to access protected resources. OpenID Connect
is an extension of OAuth that adds an authentication
layer using identity details. OAuth 2.0 requires roles to
complete the protocol which can be achieved by involving
interactions between both OAuth 2.0 and OpenID connect
that require a pre-established trust establishment while
the protocol operates. OpenID Connect requires human
interaction because of the identity layer. This identity
information is transferred through JavaScript Object Notation
(JSON) Web Token (JWT) [1]. OAuth 2.0 specification
does not mandate resource server and authorization
server exist separately, they can exist in a single system.
Verifiable credentials (VC) [5] are used to provide tamper-
proof credentials that can be verified cryptographically. VCs
have strong encoding properties, but their functionality is
limited because of the lack of standards in exchanging VCs.
Open Authorization is a kind of token-based authentication
that helps organizations to share information across third-party
websites without exposing their users’ credentials. OAuth
ensures that the website requesting the information has the
right permissions to access the user’s data. VCs issue can
be resolved by incorporating OAuth tokens into them. VC
encoding will be done by JSON Web Tokens (JWT) and uses
JWT –based mechanisms for proving VC possession. Open
Authorization 2.0 is like OAuth that is used to access resources
in a resource server. The authorization decisions are made by a
trusted entity known as the authorization server. In most cases,
the authorization server and the resource server are controlled
under the same administrative authority, hence it is sufficient
to encode authorization decisions in opaque bearer tokens and
enforce them using simple Access Control Lists (ACL). For
instance, take the authorization server as a social networking
website and the resource can be a profile of a specific user.
Web Application Programmable Interfaces APIs enable
data and resource sharing with various third-party, web,
cloud and mobile applications [8]. Open Authorization and
API keys are used to manage the authorization aspects
of such integrations. Due to their static nature in design,
coarse and context-insensitive capabilities cause issues
with some security aspects. To overcome these issues, it
is important to make use of a framework that supports
transparent externalization of authorization functionality
for access control of web API resources. This framework
[8] uses the notion of a knowledge graph, which is a
dynamic database, and applies an integral, model-based
view that has a combination of service descriptions,
data formats, security policies, and service interactions.
Many websites provide APIs for accessing the stored
user Information on their site, hence for additional security
OAuth protocol generates an access code that the user
can pass on to the clients which could be used to
authenticate when the user tries to access the Intended
Information this Is known as delegated authorization.
In mobile applications, desktop applications, and client-
server web applications OAuth 2.0 specify the handling of
delegated authorization. To handle specific client needs the
OAuth 2.0 defines much authorization flows [9]. To name
some, authorization code flow, Implicit Grant flow, resource
owner password credentials flow, and client credentials flow.
Irrespective of the strict protocols and different remediation
proposed at the time, many OAuth-based services are still
vulnerable to different security flaws [10]. When considering
the different client-side parameters these protocols aren’t
detailed enough to cover all the possible attacks. CSRF attack
against the redirect URI is one of the most tangible attacks
on the implementations of the OAuth. For the mitigation of
the vulnerability, two effective defense mechanisms are: To
all the state-changing requests CSRF token is to be validated
and this includes additional headers with XMLHttpRequest
[10]. These two mechanisms are considered as they were
most repeatedly used on a large dataset. Because it is widely
used for authorization and authentication In experience,
there are numerous studies to assess safety OAuth 2.0 has
been released, and there is some practical attack detected [11].
As Open Authorization 2.0 provides very little privacy
for the users’ especially in federated login (Single Sign-on)
systems [7], the identity provider can learn a great deal about
users’ web browsing patterns. This addresses privacy issues
that concern a few users. Simple browser-based mitigations
are insufficient, modifying protocol behavior is the only
option to mitigate this problem. OAuth 2.0 helps in the
management of users’ passwords in an organization as well
as saving users the inconvenience of re-entering attributes
that are instead stored by Identity Providers (IdPs) and
provided to Relying Party (RP) websites as required. The
registration process for OAuth 2.0 and OpenID connect
gives the information of RP in the form of client_id,
client_secret, redirect_uri to the IdP [7]. It is still not
clear to mitigate this exchange of information between the
RP and IdP and it remains an issue for further research.
Allowing one Web service to act on our behalf with another
has become increasingly important as social Internet services
such as blogs, photo sharing, and social networks have become
widely popular. OAuth, a new protocol for establishing
identity management standards across services, provides
an alternative to sharing our usernames and passwords. In
the November/December issue, Jeremy Grant from the US
National Institute of Standards and Technology describes
NIST’s National Strategy for Trusted Identities in Cyberspace
(NSTIC) initiative [12]. Internet identity management is an
umbrella that covers several related problems which stem
from our use of multiple Internet services that come from
different providers [12]. OAuth began as a community effort
among numerous companies that provide Internet services.
Mobile apps frequently use the Open standard for
Authorization (OAuth) for acquiring access to user resources
on distant service providers that examine various OAuth
implementations used by the top resource providers’ SDKs
for smartphones and present potential attacks against
most OAuth implementations [15]. They [15] proposed
an application-based OAuth Manager framework, that
provides a secure, light, and fast OAuth flow for mobile
applications that are based on the concept of privilege
separation. Auth provides a secure, lightweight, and fast
OAuth flow for mobile applications that are based on
the concept of privilege separation and described the
design and security assumptions of each of the main
OAuth flows in apps, such as using an embedded web
component, a browser, and using a provider installed app.
Online service providers frequently utilize Open Standard
for Authorization (OAuth) to control the authentication
and authorization processes. Web View renders, displays,
and offers additional browsing features for HTML pages.
It was discovered to be susceptible to a wide variety of
attacks, including JavaScript injection attacks. Effective
security cue design has received some attention in mobile
web browsers and to a lesser extent in Web View [14].
Users pay less attention when using mobile devices,
according to an early study. The security status light is a
new visual indication that other researchers have proposed
(SSLight). Even though they believe they are not safe,
mobile users commonly use third-party programmers to
connect to their internet accounts. This research [14]
demonstrated that several of the security cue designs for
OAuth-Web View embedded mobile apps are very observable,
easily understood, and useful in informing users of the risks.
Many millions of users routinely use Google, Facebook,
and Microsoft to log in to websites supporting OAuth 2.0
and/or OpenID Connect. Many real-world implementations of
OAuth 2.0 and OpenID Connect are vulnerable to cross-site
request forgery (CSRF) attacks. Since OAuth 2.0 appeared
in 2012 [13], it has been widely used for single sign-on
(SSO). Websites use OAuth 2.0 to simplify user password
management and save users from reentering attributes that are
instead held by identity providers (IdPs) and introduced a new
class of mitigations that can prevent such attacks [13].
II. D ETAILED DESCRIPTION OF THE DEVELOPMENT
Open Authorization: Clients are given "safe delegated
access" to server resources via OAuth on behalf of the
resource owner. It outlines a procedure that resource owners
may use to grant unauthorized third parties access to their
server resources without giving away their credentials. With
the permission of the resource owner, OAuth simply enables
an authorization server to give access tokens to third-party
clients. In this case, the resource owner is “The Movie DB”
and the third-party client is our mobile application called
“The Movie App”. When we register ourselves with the
resource owner, it validates and then issues an access token
as shown in Figure 1. The access token is a pass that is used
by the resource owner’s server to authorize the request. The
access token provided here is an API Key. The third-party
client (i.e, Movie App), whenever it is requesting the data
from the DB, the API key is added in the header payload
along with the other required fields. The resource owner, after
receiving the request, authorizes the request with the access
token, which is an API Key. After successful authorization,
it responds with the requested data in a JSON format.
Fig. 1: Access token Validation
Retrofit: Retrofit is a type-safe REST client for Java and
Android that aims to make accessing RESTful web services
simpler. By default, Retrofit 2 relies on OkHttp as the network-
ing layer and is constructed on top of it. Retrofit uses a POJO
(Plain Old Java Object), which must be predefined for the
JSON Structure, to automatically serialize the JSON response.
We need a converter to first convert JSON into Gson before
serializing it. The following dependencies must be added to
our build.grade file as shown in Figure 2.
Fig. 2: Retrofit Dependencies
OkHttp has a strong mechanism called interceptors
that can monitor, rewrite, and retry calls. Generally
speaking, interceptors fall into one of two categories:
Application Interceptors: We must execute addInterceptor()
on OkHttpClient.Builder in order to register an
application interceptor. These can be used to timeout
a read or write request after a particular interval.
Network Interceptors: Use addNetworkInterceptor() rather
than addInterceptor to register a Network Interceptor (). The
network interceptor we used here is Stetho. This will allow
us to intercept the network calls going out from this app
and capture the response. To brief about Stetho, For Android
apps, Stetho is a well-developed debug bridge. When activated,
developers have access to the Chrome Developer Tools feature,
which is a native component of the Chrome desktop browser.
To use Stetho we have to add this dependency as shown in
Figure 3.
Fig. 3: Network Interceptor using Stetho Dependency
After adding all the application and network interceptors,
our HTTP client should be as shown in Figure 4. Now
everything is set for us to intercept the calls and capture
the response. All we need to do is, to make requests to the
resource owner. As we are requesting data, we make GET calls
from our application by using ROOM. Room is a persistence
Fig. 4: Application and Network Interceptors
library, part of the Android Architecture Components. It makes
it easier to work with SQLiteDatabase objects in your app,
decreasing the amount of boilerplate code and verifying SQL
queries at compile time[ref]. In other words, it makes our life
easier in writing SQL queries without writing boilerplate code.
We append the required fields to the base URL along
with the access token. The API key is stored in the app
through encrypted shared preferences. It is used to generate
the encryption keys that are used for encrypting keys and
values. To use Secured Shared Preferences, we need to add
the dependency as shown in Figure 5
Fig. 5: Encrypted Shared Preferences Dependency
To encrypt the keys, we use PrefKeyEncryption-
Scheme.AES256_SIV and to encrypt its corresponding
value, we use PrefValueEncryptionScheme.AES256_GCM,
Encrypted shared preferences are secured using AES 256.
The resource owner authorizes the call with the access token
and will only respond with the data if the authorization
is successful as shown in Figure 7. If not, it gives us an
unauthorized request error saying “Invalid API Key: You
must be granted a valid key” as shown in Figure 6. Here
we have demonstrated the same call from our application
and also through postman. When we make a call from our
application, it responds with the requested data. But in the
other case, the authorization failed and it did not provide us
with any data. The service provider usually provides data in
JSON format as shown in Figure 8 and we model it as per
our requirement. Since we are using Kotlin, we convert the
JSON to GSON and then map it to the User Interface (UI).
Fig. 6: Invalid API key error
Fig. 7: Successful authorization 200 OK response.
III. R ELATED W ORK I N THIS AREA
Open Authorization 2.0 roles [6] represents the Resource
owner which owns a resource stored in a remote location
that can be human (end-user) or non-human, it is mandatory
that a resource owner must be a human for OpenID Connect.
On the other hand, a Resource Server is an entity that stores
resources owned by resource owners. Access to the resources
is done by OAuth 2.0 tokens which are formally referred to
as access tokens. The client is an application that expects
permission to access resources from a resource server. This
permission is granted by the resource owner. The application
verifies this permission to a resource server by using an
access token. The authorization server is a central server that
issues valid tokens to a client application. These tokens are
Fig. 8: Data in JSON format
generated if and only if the resource owner permits them
to do so. Depending on the protocol, issued tokens may
vary. A single authorization server can serve multiple clients.
OAuth 2.0 and OpenID connect help to generate a
token response that contains the ID token [6]. The
client can validate the token and authenticate the
end-user identified through claims present in the ID
token. OpenID connect further resembles grant types
defined by OAuth 2.0, merely defining ways to obtain
authorization grants and present them to the authorization
server thus enhancing the roles of trust establishment.
With emerging cloud technologies, it is necessary to secure
shared resources. Using bearer tokens or hard-to-guess URLs
is not sufficient to provide security, so the usage of Open
Authorization with Verifiable Credentials (VC) provides
proper security [5]. When the resource server is independent
of the authorization server using an Access Control List
(ACL) is cumbersome, so encoding the access control tokens
to describe the access rights of their holds is a solution.
VCs are cryptographically secure which preserves privacy
and machine-verifiable means to provide access credentials.
However, using VCs alone could lead to standardization
issues, which will be mitigated by using Open Authorization.
A VC architecture contains a verifiable data registry that
acts as a database of VC schema, revocation list, and public
keys which are needed to issue credentials by the issuing
authority. Then those credentials and the auxiliary info will
be passed to the holder who sends them to the verifier who
has auxiliary info to verify the holders’ credentials. By
leveraging this organizations can share the resources while
protecting some through providing role-based access tokens
[5]. Each access token has a token generation endpoint
that can be invoked by clients to obtain an access token.
Proving the possession of key needs OAuth Demonstration
of proof-of-possession at the Application layer (DPoP) [5].
DPoP has been designed for HTTP communication in which
key holders can send their HTTP requests with a header
called DPoP proof. A DPoP proof is a JSON Web Signature
(JWS) signed using the key of the user. Therefore, JWS
header contains a “dpop+jwt” field which is a digital signature
algorithm and a JWK public key. The JWS payload includes
at least a unique identifier (which can be a sufficiently large
random number), the HTTP method of the request, the HTTP
URI of the request, and the time when the request was
created. Then the client requests to perform an operation on a
resource by providing a DPoP proof and the obtained access
token, then the Resource Request verification will be done.
Open Authorization token introspection allows a Resource
Server to query a token endpoint implemented by the Access
Server to know the state of the access token and its metadata
of it. The token introspection endpoint responds with a JSON
object that contains a field named active which represents
the current state of the token. The major disadvantage
of this approach is communication overhead since the
Resource Server needs to send a query for the status of each
token, thus incorporating Verifiable Credentials to verify
the revocation of the token ultimately to know the status
is beneficial. This scheme preserves privacy and efficiency [5].
Web APIs now exhibit more persuasive context with
IoT and mobile devices with the emerging web and cloud
services [8]. Conventional authorization methods are not
sufficient, for instance, take Open Authorization, which
establishes the interactions for communicating resource
requirements and credentials among different systems. Access
scopes are built as opaque data references and specified
in natural language which makes it not possible for a
machine to understand and autonomously derive or adjust
the meaning of a provided scope. OAuth does not have a
model to manage security policies, especially regarding the
structure of APIs and the exposed data it is intended to protect.
It is necessary to support companies in integrating
multilateral data sharing within their services by providing a
fully externalized, pluggable, flexible, and context-sensitive
authorization management solution that integrates well
with existing protocols and technologies which can be
achieved by leveraging the concept of a knowledge graph to
interconnect representations of web service resources, their
organizational structure, requests, and interactions occurring in
the system with entities describing security functionalities [8].
In OAuth 2.0 used for SSO systems, the resource server
and authorization server together play the IdP role; the client
plays the role of RP, and the resource owner corresponds
to the user [7]. OAuth 2.0 protocol flows have a Resource
owner password and client credentials grant that reveal the
users’ IdP account credentials to the resource owner. No
browser interaction is done during these phases; the client
directly talks to the authorization server. OpenID Connect
adds an Identity layer to the OAuth 2.0 protocol which
enables RPs to verify an end-user identity by relying on an
authentication process performed by an OpenID provider.
During these two operations, the access tokens and identity
tokens are the key [7]. Thus, IdP learns about the web access
behavior of a single user by determining the identity of RPs.
By using this information, IdP could deliver personalized
advertisements. For example, if a user uses Facebook to
log in to a movie website, then Facebook can use this
information to show personalized movie ads to the user.
Developers repurposed OAuth for authentication even
though it was initially intended for authorization. As a result,
the OAuth standard protocol never specifies how to carry out
OAuth authentication, and developers must come up with a
solution on their own. Typically, they just altered the final
step of the OAuth protocol, which uses the user’s resources to
identify the user [3]. OAuth is also used in social login. The
most popular social login OAuth is Facebook with 45% users
followed by Google with 37% users [2]. Considering the
example of Facebook OAuth, The built-in Facebook Android
SDK first asks the system if the Facebook app is already
installed; if so, the OAuth flow will go through the Facebook
app; if not, an embedded WebView will be utilized [4].
Pai et al [9] formalize the OAuth Protocol using a
method called knowledge flow analysis. In the form
of predicate logic, they formulated the OAuth protocol
into a set of formulas. But in this model Reverse
engineering would lead to revealing the passwords.
Chari et al. [9] present an analysis of the authorization
code mode of OAuth 2.0 using the universal composability
security framework. Based on the OAuth 2.0 Protocol
internet draft proposal they [9] implemented the server-side
authorization flows, also here to improvise the security
they add a compulsory need in the communication channel
between the client application and the authentication
server must be encrypted by a functionality like SSL.
The related works on OAuth and CSRF attacks can be
categorized into three groups namely, CSRF mitigation,
protection tools, and security analysis [10]. The technique
of analyzing and validating the referrer header field allows
OCSRF initiated from the domain which falls under the
attacker’s control from execution. (citation), throughout the
popular web frameworks, the authors provided an evaluation
of broad security for CSRF mitigations. They [10] figured
out 16 different existing defense mechanisms by dividing the
CSRF attacks from literature and non-literature resources. In
four categories they were distinguished namely, Origin checks,
request unguessability, SOP for cookies, and User Intention.
OAuth addresses the problem of giving services unrestricted
access to our credentials. It has the target service create
an access token that we can give out that allows only
limited access. This means we can authorize specific
actions and only those specific actions without giving
unrestricted or permanent access. The resource owner is
the entity that owns the information the client needs to
access. OAuth is an enormous improvement over giving
Gmail login credentials directly to Facebook. But OAuth
still leaves some things exposed, and attacks against the
tokens themselves are vulnerable. The more we can put the
request into plain language, the more likely it is that we’ll
be working with informed consent. The OAuth Working
Group has approved the OAuth 2.0 protocol specification,
which is moving through the IETF’s process. We’ll likely
see it published as a proposed standard in the future [13].
Security has been the contribution in the context of
general-purpose computing and communications systems.
To implement the security, they [15] have proposed to
use the privilege separation concept to ensure that the
client application has no control over the user-agent and
removed the critical OAuth components and implemented
it in a separate application (secure sandbox), known as
OAuth Manager. This helps to get rid of the attacks
that a malicious application can directly affect the device.
Generally, in mobiles, an Embedded web browser compo-
nent is used as a UI view component that can be embedded in
a mobile app to display online content within the hosting app.
This traditional method also uses the OAuth flow for client
apps, but it is prone to attacks like stealing the User Creden-
tials, modifying the interface, and tampering with the data.
The system Native browser is subject to all the same attacks
as an embedded web browser’s OAuth flow. To overcome these
problems an OAuth manager framework is introduced [15].
OAuth manager is a framework that provides a secure,
light, and fast authorization flow for mobile applications
that is based on the concept of privilege separation.
For developers, it is better to use the OAuth manager
framework to consider users’ privacy when implementing
OAuth, and to avoid using WebView-based OAuth [15].
A good security cue design must be noticeable,
understandable, and effective. seven different security
cue designs were proposed/borrowed and tested [14]. Apps
have an OAuth-WebView implementation to connect them
to Facebook. The applications have been uploaded to an
online emulator service called appetize.io. The security cue
design mainly concentrated on login pages (the authentication
and the authorization pages) on the web applications and
the mobile applications and took reviews from the public
(a group of 465 members) to know what and how they
feel about the security cues were. The security cue designs
that were used in the authentication page: Red Background
and a Message, Traffic Light, Red Border, and Toast
Password. Highlights Permissions, Traffic Light, and Red
Line designs were proposed for the authorization page [14].
OAuth is used in both the web and mobile contexts to
authenticate and authorize third-party applications. There
are crucial differences between the two application types
in terms of maintaining the integrity of the authorization
pages and assuring the confidentiality of the authentication
pages’ data. However, the difference might not be well
realized by mobile and web users. Thus, finding an effective
security cue design to be used in alerting users of OAuth-
Web View related risks. The Red Background and Traffic
Light designs were more effective than the Toast Password
design in making participants, not log in. These findings
[14] suggest the need to harden mobile applications
against attacks that aim at compromising users’ privacy.
A CSRF attack takes place during a continuous conversation
between a target website and a target UA (used by a target
user). The web browser might submit an HTTP/HTTPS
request to an RP and IdP in response to the malicious content.
A 2017 OWASP report states that 5% of web applications
have CSRF vulnerabilities [13]. Without the user’s permission,
an attacker may be able to obtain authorization to access
OAuth-protected resources by conducting CSRF attacks
against the OAuth 2.0 redirect Uri. Attacks of this nature are
both Authorization Code Grant and Implicit Grant susceptible.
A Referrer header can be used to mitigate CSRF
attacks against RPs using redirect Uri. An authorization
response is typically only generated after a user clicks on
an IdP-rendered grant button. The RP can detect this is
an attack by examining the domain in the RFC header
which points to the RP domain. In practice, major IdPs
such as Google, Facebook and Microsoft, implement an
’automatic authorization granting’ feature. As in II-C3, the
access token in the Implicit Grant Flow is not immediately
transferred when the UA is redirected to the RP [13].
CSRF attacks against redirect Uri in OAuth 2.0 and OpenID
Connect could be mitigated by a new class of mitigations for
CSRF attacks. The approach [13] is practical and straightfor-
ward to implement and requires no changes to the IdP service.
IV. C ONCLUSION
In this paper, we described the original purpose of OAuth,
which is delegating the authorization. But in later stages, the
developers also started using OAuth to delegate the authen-
tication as well. Many tech giants like Facebook, Google,
Github, and others have started providing this service. This
does not stop here, many resource owners are now providing
their services with the help of Open Authorization. We need to
validate ourselves to get an access token. Once an access token
is received, you can delegate the API services. It is very much
required that the API Token is stored on the device. So, the
security of the API token depends on the practices followed
by the developer. In this project, we used encrypted stored
preferences to store API keys. The secured stored preferences
are AES256 encrypted.
 R EFERENCES
[1] G. Henry, "Justin Richer on OAuth," in IEEE Software, vol. 37, no. 1,
pp. 98-100, Jan.-Feb. 2020, doi: 10.1109/MS.2019.2949648.
[2] L. K. Ho and N. Katuk, "Social login with OAuth for mobile applica-
tions: User’s view," 2016 IEEE Symposium on Computer Applications
& Industrial Electronics (ISCAIE), 2016, pp. 89-94, doi: 10.1109/IS-
CAIE.2016.7575043.
[3] T. A. Rahat, Y. Feng and Y. Tian, "OAUTHLINT: An Empirical
Study on OAuth Bugs in Android Applications," 2019 34th IEEE/ACM
International Conference on Automated Software Engineering (ASE),
2019, pp. 293-304, doi: 10.1109/ASE.2019.00036.
[4] M. Shehab and F. Mohsen, "Towards Enhancing the Security of OAuth
Implementations in Smart Phones," 2014 IEEE International Conference
on Mobile Services, 2014, pp. 39-46, doi: 10.1109/MobServ.2014.15.
[5] N. Fotiou, V. A. Siris and G. C. Polyzos, "Capability-based ac-
cess control for multi-tenant systems using OAuth 2.0 and Verifiable
Credentials," 2021 International Conference on Computer Commu-
nications and Networks (ICCCN), 2021, pp. 1-9, doi: 10.1109/IC-
CCN52240.2021.9522214.
[6] K. Dodanduwa and I. Kaluthanthri, "Role of Trust in OAuth 2.0 and
OpenID Connect," 2018 IEEE International Conference on Informa-
tion and Automation for Sustainability (ICIAfS), 2018, pp. 1-4, doi:
10.1109/ICIAFS.2018.8913384.
[7] W. Li and C. J. Mitchell, "User Access Privacy in OAuth 2.0 and OpenID
Connect," 2020 IEEE European Symposium on Security and Privacy
Workshops (EuroS and PW), 2020, pp. 664-6732, doi: 10.1109/Eu-
roSPW51379.2020.00095.
[8] B. Suzic and M. Latinovic, "Rethinking Authorization Management of
Web-APIs," 2020 IEEE International Conference on Pervasive Comput-
ing and Communications (PerCom), 2020, pp. 1-10, doi: 10.1109/Per-
Com45495.2020.9127384.
[9] Yang, F., Manoharan, S. (2013). A security analysis of the OAuth proto-
col. 2013 IEEE Pacific Rim Conference on Communications, Computers
and Signal Processing (PACRIM). doi:10.1109/pacrim.2013.6625487
[10] Arshad, E., Benolli, M. and Crispo, B., 2022. Practical attacks on Login
CSRF in OAuth. Computers & Security, 121, p.102859
[11] Li, X., Xu, J., Zhang, Z., Lan, X. and Wang, Y., 2020, September.
Modular Security Analysis of OAuth 2.0 in the Three-Party Setting. In
2020 IEEE European Symposium on Security and Privacy (EuroSP) (pp.
276-293). IEEE.
[12] B. Leiba, "OAuth Web Authorization Protocol," in IEEE Inter-
net Computing, vol. 16, no. 1, pp. 74-77, Jan.-Feb. 2012, doi:
10.1109/MIC.2012.11.
[13] W. Li, C. J. Mitchell and T. Chen, "Mitigating CSRF attacks on OAuth
2.0 Systems," 2018 16th Annual Conference on Privacy, Security and
Trust (PST), 2018, pp. 1-5, doi: 10.1109/PST.2018.8514180.
[14] F. Mohsen and M. Shehab, "Proposing and Testing New Security
Cue Designs for OAuth-WebView-Embedded Mobile Applications,"
2017 IEEE 3rd International Conference on Collaboration and Internet
Computing (CIC), 2017, pp. 443-448, doi: 10.1109/CIC.2017.00063.
[15] M. Shehab and F. Mohsen, "Towards Enhancing the Security of OAuth
Implementations in Smart Phones," 2014 IEEE International Conference
on Mobile Services, 2014, pp. 39-46, doi: 10.1109/MobServ.2014.15.