A security analysis of the OAuth protocolFeng Yang and Sathiamoorthy Manoharan

Department of Computer ScienceUniversity of Auckland

New Zealand

AbstractThe OAuth 2.0 authorization protocol standardisesdelegated authorization on the Web. Popular social networkssuch as Facebook, Google and Twitter implement their APIsbased on the OAuth protocol to enhance user experience of socialsign-on and social sharing. The intermediary authorization codecan be potentially leaked during the transmission, which thenmay lead to its abuse. This paper uses an attacker model tostudy the security vulnerabilities of the OAuth 2.0 protocol. Theexperimental results show that common attacks such as replayattacks, impersonation attacks and forced-login CSRF attacks arecapable of compromising the resources protected by the OAuth2.0 protocol. The paper presents a systematic analysis of thepotential root causes of the disclosed vulnerabilities.

Keywords-Single sign-on, OAuth, security vulnerabilities.

I. INTRODUCTIONOAuth (open standard for authorization) protocol provides

a generic framework to let a resource owner authorize third-party to access the owners resource held at a server withoutrevelaing to the third-party the owners credentials (such asusername and password) [1], [2].

The protocol works roughly as follows. When required by a(trusted) third-party, the resource owner requests the server toprovide a valet key to the third-party. The server authenticatesthe resource owner (e.g. using username and password) andonce authenticated, passes a valet key. The third-party thenuses the valet key to access the owners resources held at theserver. See Figure 1.

&OLHQW$SS7KLUG3DUW\

(QGXVHU5HVRXUFH2ZQHU

5HVRXUFHDFFHVVUHTXHVW

9DOHWNH\WRNHQUHTXHVWVHQW ZLWK DXWKHQWLFDWLRQ

9DOHWNH\IRUUHVRXUFHDFFHVV

6HUYHUKROGLQJRZQHUVUHVRXUFHV

VHQWZLWKDXWKHQWLFDWLRQ

9DOHWNH\WRNHQJUDQWHGZLWKVXFFHVVIXODXWKHQWLFDWLRQ

Fig. 1. A rough overview of the OAuth protocol

A leaked valet key can potentially be used by other parties

to obtain illegal access to owners resources. This paperinvestigates some of the mechanisms that may lead to suchcompromises. An implementation of OAuth protocol is usedas the basis for understanding the protocol. Assuming thatit is possible to eavesdrop on the network trafc carryingOAuth data, the paper examines through experiments the easeor otherwise of impersonation and replays. Some of the attacksare seen to be possible and the paper discusses how theseattacks could be mitigated.

The rest of this paper is organized as follows. Section IIintroduces the OAuth protocol. Section III reviews relatedwork. Section IV presents an experimental analysis of theOAuth protocol through attacker models. The nal sectionconcludes with a summary and a discussion on the mitigationof attacks.

II. INTRODUCTION TO OAUTH

Quite a number of websites provide APIs to access userinformation stored on the site. For example, Google providesAPIs to add entries to a users calendar. It will not beappropriate for client applications using such an API to requestthe users Google credentials in order to add calendar entries.The OAuth protocol alleviates this issue by allowing the userto obtain from Google an access code that she can pass onto the client application; this access code is then honouredby Google when the application attempts to add to the userscalendar entry. This is known as delegated authorization. Theuser in this case grants access to the client application to addentries to her calendar on her behalf.

OAuth 2.0 specication denes how to handle delegated au-thorization in a variety of situations such as client-server webapplications, mobile application, and desktop applications. Itdenes four client proles: Web Server prole, User-Agentprole, Native Application prole, and Autonomous. The webserver prole is widely implemented and deployed by severalmajor service providers such as Google, Twitter, Facebook,and Yahoo!.

OAuth 2.0 denes several authorization ows to cope withthe specic need of each of the client proles. They areauthorization code ows, implicit grant ows, resource ownerpassword credentials ows and client credentials ow. Server-side web applications typically use authorization code grantows while client-side web applications typically use implicitgrant ows.

271 978-1-4799-1501-9/13/$31.00 2013 IEEE

A. Authorization Code Flow and Implicit Grant FlowIn the authorization code ow, the resource owner is redi-

rected back to the client application with an authorizationcode. To exchange the authorization code for an access token,the client application must provide the client credentials inthe access token request. In the implicit grant ow, on theother hand, when the resource owner grants access to the ap-plication, instead of returning an authorization code, an accesstoken is immediately redirected back to the client applicationby the authorization server. Since the client application ishosted in the resource owner machine, likely running in theweb browser, returning an authorization code is redundant.

B. Authorization RequestOAuth 2.0 recommends that the authorization endpoint

should be protected by the use of TLS while there is norequirement and no recommendation for the protection of theauthorization endpoint in WRAP. The vulnerability of notauthenticating clients with TLS when using implicit grantis well documented in the OAuth 2.0 specication. Shouldan implementation choose not to use TLS, the authorizationendpoint will be vulnerable to phishing attacks.

C. Authorization Response and Callback EndpointIn the authorization ow, if the resource owner grants the

access request, the authorization server generates an autho-rization code and adds it in the redirection URI as a queryparameter. The redirection passes via the resource owners user-agent to the client. If TLS is not uses, the authorization codecan be eavesdropped [3].D. Access Token Request

In OAuth 2.0, authorization server must implement a TLSmechanism to protect requests to the token endpoints. Fig-ure 2 shows a clients HTTP access token request to Googleauthorization server. This includes client credential and anauthorization code in the POST data.

grant type: authorization coderedirect uri: http://127.0.0.1:3000/oauth2callback/client id: 678942420820.apps.googleusercontent.comclient secret: hWh0fWA79J42z m19PB7iINUtype: web servercode: 4/Y5PZXm . . . GMuFzsEfQI

Fig. 2. Post Data from Access Token Request

E. Access TokensAccording to OAuth 2.0 specication, the access token

represents the grants scope, expiration and other attributesissued by the authorization server. It is important for thelegitimate client to keep the access token safe from unintendedparties.

OAuth working group published two specications OAuth2.0 Message Authentication Code (MAC) Token [4] andOAuth 2.0: Bearer Token Usage [5] to describe the usage of

the access token. These two drafts dene two kinds of accesstokens: Bearer Token and MAC Access Token respectively.Bearer tokens are considered less secure compared to MACaccess tokens because anyone simply possessing of the tokencan have access to the protected resources. No signature ofthe API request is needed in the API endpoint. Although ithas this weakness, most major service providers implementingOAuth 2.0 protocol use bearer tokens as a form of accesstokens due to its simplicity. There is always a tradeoff betweensecurity and usability. To protect against token disclosure,especially bearer tokens, the specication requires that the TLSmechanism must be used in the transmission of access tokenrequests and protected resource requests [5].

To minimize the risk as a consequence of stolen token, theprotocol introduces a short-lived access token and a long-liverefresh token. If the duration authorized to an access tokenis expired, the client application can use the refresh token toissue another access token request. What happens if the refreshtoken is stolen? The answer is any party possessing of therefresh token will have a long duration of authorized access tothe protected resources. Therefore, the optional refresh tokenis only granted to the client applications with high securitystandard.

III. RELATED WORKFrancisco and Karen classied OpenID and OAuth as a

double-redirection protocol [6], [7]. First redirection is theapplication redirects the browser to a third party authenticationor authorization endpoint. Second redirection is the thirdparty endpoint redirects the browser to a callback endpointof the application. They analyze the security of the double-redirection protocol and nd that the user is vulnerable tophishing attacks if the third partys authentication or authoriza-tion endpoint is not protected by TLS. Moreover, they pointout that implementing TLS in the callback endpoint of theapplication can provide security protection against man-in-the-middle and passive attacks.

Uruena et al. present a paper studying the privacy risks forthe users of the OpenID Single Sign-On mechanism [8]. Theynd out that OpenID Authentication Protocol relying URL-parameter encoding as a means of information transmissionbetween the Relying Party and the OpenID Provider canpotentially compromise privacy of the application users. Eventhough the parameters of the authentication grant response aresigned to protect the integrity, anyone that has access to thefull URLs of the authentication request or response can see allthese non-encrypted parameters such as OpenID Identier. Itis extremely easy to access these URLs due to the nature of theHypertext Transfer Protocol (HTTP). Nowadays, it is unlikelyfor a website to only host their resource . So resources suchimages and links from third parties are often embedded in thepage the user is currently visiting. All these external resourceswill trigger individual HTTP request to a third party with aReferer header set to the full URL of the web page wherethose resources are accessed from. Presenting the Referereld in HTTP request header can prevent CSRF attacks and

272

facilitate trafc analysis. Unfortunately, attackers can takeadvantage of the Referer eld to reveal user condentialinformation passing in the delegated-based authorization andauthentication protocol. Uruena and Busquiel proposed threepossible solution to this vulnerability: Redesigning the OpenIDAuthentication Protocol, Disabling the HTTP Referer eld andprohibiting external resources embedded in the web pagesprocessing OpenID Authentication URLs.

Pai et al. formalize the OAuth protocol using a methodcalled knowledge ow analysis [9] . They formalize the OAuthprotocol as a set of formulas in the form of predicate logic.These formulas are then used to build a model in Alloy [10].They show that the OAuth protocol has a security vulnerabilityin the client credentials ow of the OAuth protocol. Clientapplications using client credentials ow store client passwordin the software package. However, reverse engineering canreveal the stored password. Then this compromised secretclient credentials could be used in malicious application toharvest sensitive information.

Miculan and Urban present a formal analysis of FacebookConnect protocol using the specication language HLPSLand AVISPA [11]. To translate the Facebook protocol intoHLPSL, a detailed specication of the protocol is essential.Unfortunately, Facebook never releases an ofcial specica-tion about its propriety protocol. In order to formalize theFacebook protocol, they analysed all HTTP trafc betweenthe browser, the Facebook authentication server and a clientapplication during the process of the authentication. As asecurity protocols verication tool, AVISPA revealed twosecurity vulnerabilities which are replay attack and imperson-ation attack. They provided a countermeasure to defend theseattacks.

Bansal et al. modelled several proles of the OAuth2.0 protocol in applied pi-calculus and veried them usingProVerif [12], [13]. They introduced a library called WebSpifor modelling web applications and web-based attackers. Typ-ically a complete web application involves three parties: User,User-agent, Server. To simulate these three components in thereal world, WebSpi contains three processes: (1) a server-site(PHP-like) process providing services as a website, running ontop of HttpServer, (2) a client-side (JavaScript-like) processacting as a user agent with all the basic functionalities ofHttpClient, and (3) a user process interacting with the useragent and the latter communicate with the web application.They also introduced a customizable attacker model to launchdifferent kinds of attacks. The Attacker issues a commandby signalling the public channel admin. A specic attackercapability can be enabled from three categories by this API .The three categories are Managing principals, Network attack-ers and Website attackers. Based on the WebSpi model, theyidentify four circumstances where OAuth 2.0 deployments arevulnerable to Social CSRF attacks such as Automatic LoginCSRF, Social Sharing CSRF, Social Login CSRF on statelessclients and Social Login CSRF through AS Login CSRF.Furthermore, they revealed that OAuth 2.0 are vulnerable totoken redirection attacks and resource theft as a consequence

of access token redirection.Chari et al. present an analysis on the authorization code

mode of OAuth 2.0 using the Universal Composability Se-curity Framework [14], [15]. They implement the server-sideauthorization ows based on the OAuth 2.0 protocol Internetdraft proposal [1]. On top of the implementation, they enhancethe security feature by adding a mandatory requirement thatthe communication channel between the client applicationand the authentication server must be encrypted by SSL-like functionality. This does not require the usage of sessionidentier in advance, which can eliminate the possibility ofsession xation and session swapping attacks. The renementis proven to be the complementary of the countermeasures onthe security threats introduced by exposing authorization codein the communication channel.

The OAuth threat model provides implementers with acomprehensive threat model analysis and respective countermeasures in a systematic way [3].

IV. EXPERIMENTAL ANALYSISTo evaluate the security of the implementation of the OAuth

2.0 protocol from different parties, including client applica-tions and their associated authorization servers, we implementtwo client applications. One redirects the login request to aauthorization server implemented locally. The other commu-nicates with Googles authorization server. Figure 3 illustratesthe architecture for evaluating the OAuth protocol.

InternetGoogle Client

Local Client Local Authorization Server

Local Network

Google Authorization Server

Fig. 3. The Architecture for evaluating OAuth

A user needs to perform three clicks and provide two textinputs in the authorization ow in order to login into the clientapplication.

First click: they need to click on the external link whichredirects them to the authorization endpoint.

Type username in the authentication page. Type password in the authentication page. Second click: Click on the submit button to send the

authentication request. Third click: They need to make a decision if they would

like to grant access permissions to the client application.

A. Local Authorization ServerTo simplify the design, the authorization server imple-

mented locally serves protected resource requests as wellas authorization requests. So the authorization endpoint and

273

token endpoint are dened in the authorization server. Whenthe user visits the client site and initiates the protocol, theclient redirects the user to the authorization endpoint to grantaccess. The authorization server will ensure the user is inan authenticated state. If not, the user must perform thelogin action. After the user authenticates, a security validationshould be checked by the authorization server to ensure therequest is redirected by a legitimate client. This is done bychecking the received client id and redirection URI matchesthe registered URI in the authorization servers persistent datastore. If the validation is successful, an authorization codeis generated and stored in a temperate storage. Then theauthorization code is redirected to the requesting client via theusers web browser. In the meantime, there is a process runningin the authorization server to handle access token requests.Like authorization code grant, a validation check needs toperform to ensure it is a legitimate access token request. Asdiscussed previously, an access token request must containthe client credential, redirection URI and a valid authorizationcode. In addition to making sure the received client credentialsand redirection URI match the registered ones, the process stillneed to validate the submitted authorization code is originallyassigned to the requesting client. Failing to do so may resultin phishing attack vulnerability.

B. Client ApplicationsIn this implementation, Client applications basically have

three functionalities: user redirection, access token requests,and protected resource requests. As discussed previously, whenthe client application redirects the user to the authorizationserver, the request must contain the client id and redirectionURI. And the scope parameter is optional and is used to limitthe access of authorization grant. If the scope parameter is notprovided, minimum or default permission is given to the accessgrant. When the client application exchanges an authorizationcode with an access token, it must provide its client credentialsand redirection URI.

C. The Attacker ModelTo evaluate the security of the OAuth 2.0 implementation,

we build an attacker model, which automatically simulatecommon network attacks on the OAuth 2.0 protocol. Theattacker model consists of intercepting modules. Each modulerepresents a single attack. Four attack modules are imple-mented in this work. They are monitoring attack module,replay attack module, phishing attack module, and imperson-ation attack module. The monitoring attack module is foranalysis purposes only and it simply monitors the HTTPtrafc.

The attacker model is built on the following attack assump-tions:

It is assumed that the attacker has full access to thenetwork among the three involving parties: the resourceowners user-agent, the client application and the autho-rization server. Three communication channels (between

the resource owners user-agent and the client applica-tion, between the client application and the authorizationserver, and between the resource owners user-agent andthe authorization server) are eavesdropped by the attackermodel.

It is assumed that the attacker model is equipped withunlimited resources to launch an attack

1) Replay Attack Module: In authorization code ows ofthe OAuth 2.0 protocol, an authorization code is a representa-tion of the resource owners access grant to the client. Onceit is consumed by the client application, it should be void.The authorization code should be single use. If not, it mayresult in replay attack vulnerability. The malicious attackermay capture an authorization code redirection request in thecommunication between the resource owners user-agent andthe client application. Then the attacker resends the requestto the client application in order to login in with the accountassociated with the authorization code.

Resource Owner User-agent

Client Application

Authorization Server

1. Initiate the protocol2. Redirect to the Service Provider(ClientId, Redirect_URL)

3. User authenticates

4. Redirect user back to the client with a authorization code

6. Access token request

7. Grant access token

Plain Text

TLS with no signature

5. The authorization code

Capture request

Replay attack bysending the

captured request

Fig. 4. The Attack Model: Replay Attack

2) Phishing Attack Module: Phishing is a common way inwhich the attacker masquerades as a trustworthy entity such asa website to gain condential information such as usernames,passwords, access code, and other security information. Aswe know, it is extremely easy to obtain a client id froma service provider. For example, as long as you have anaccount with Google, you can register a client application toconsume Google web services in any time. So this meansnot all the client applications allowed to use web servicesfrom a well-known service provider respect user privacy.Some of them may just masquerade as a legitimate websitein order to gain authorization codes. In order to launch aphishing attack, the attack can poison DNS cache records onthe users machine. As a result, whenever the victim triesto visit some legitimate sites, he or she is redirected to amalicious client site that he or she is not intended to visit.In this attack module, the resource owner is redirected to amalicious client application rather than the legitimate client

274

site he or she intended to. When the victim initiates the ow,he is redirected to the authorization server with the requestcontaining the malicious clients client id and redirect URI.Once the malicious application receives the authorization code,it constructs a request with the authorization code and sendsit to the callback endpoint of the legitimate client.

Resource Owner User-agent Malicious Client

Authorization Server

1. Initiate the protocol

2. Redirect to the Service Provider(ClientId, Redirect_URL)

3. User authenticates

4. Redirect user back to the client with a authorization code

7. Access token request

8. Grant access token

Plain Text

TLS with no signature

5. The authorization code

Legitimate Client

6. Login as the victims accountBy the stolen authorization code

Fig. 5. The Attack Model: Phishing Attack

3) Impersonation Attack Module: This attack module takesadvantage of the security vulnerability that the callback end-point of the client application is not required to use TLSmechanism to protect the condentiality of the communica-tion. Firstly, the authorization code is eavesdropped by theattacker. Second, the attacker block the original request tokeep the stolen authorization code in a fresh state as we knowthe authorization code could become invalid after it has beenused. Finally, the attacker establish a session with the clientapplication by initiating the authorization ow and send aforged request with the stolen authorization code.

Resource Owner User-agent

Client Application

Authorization Server

1. Initiate the protocol2. Redirect to the Service Provider(ClientId, Redirect_URL)

3. User authenticates

4. Redirect user back to the client with a authorization code

6. Access token request

7. Grant access token

Plain Text

TLS with no signature

5. The authorization code

1. Intercept the authorization code

2. Initiate the protocol

3. Request with the victimsAuthorization code

Fig. 6. The Attack Model: Impersonation Attack

D. Observations

We nd that the local authorization server is vulnerable toreplay attacks. We observed that authorization code redirectionis sent by the web browser to the client application, followedby a forged request with the same authorization code. We cansee that both requests gain access to the restricted area of thesite. This means the local authorization server does not haveany authorization code restriction limiting the duration of theauthorization code. In contrast, Google authorization serverpassed the replay attack vulnerability test, which indicatesthat it enforce one-time use of the authorization code. Wealso manually tested this vulnerability on Facebook and foundout that it allows multiple-time uses. While multiple-timeuses of an authorization code gives developers exibility inimplementation, it may result in replay attacks vulnerability.We recommend that the authorization server should enforceone-time use of authorization codes unless proper securitymeasure is put in place to prevent malicious reuse of theauthorization code, as specied in the OAuth 2.0 specication.

The Google client application hosted inwww.livejournal.com and found that two tests were failed onthis website. We observed that the livejournal site failed theimpersonation attack vulnerability test. After anaylzing theHTTP trafc from the generated HAR les, we found outthat the livejournal site set a cookie in the users web browserwhen the user visits a page from the site. When the user isredirected back from the authorization server, the callbackendpoint considers the redirection invalid if the cookie is notcontained in the request. From the packet captures, it seemedthat the site tries to prevent the impersonation attacks bystoring a cookie in the users web browser.

In this case, only having the authorization code is notsufcient enough to impersonate the victims account. It mustcooperate with a valid cookie from livejournal.com. Since thecallback endpoint of the livejournal website is not protectedby TLS, the HTTP trafc data is not encrypted. So it isextremely easy for the attacker to obtain the cookie as well asthe authorization code. Furthermore, the failed test testImper-sonationAttackByAuthCodeAndForgedCookie shows that theoriginal cookie is not necessary for the callback endpointrequest from the redirection. It can be simply replaced by anyother cookie that is obtained by any other connection to thepage. This means the livejournal site users account is likelyto be compromised as long as the authorization code is leakedto the attacker. The approach where the livejournal site sets acookie in advance when the user rst visits the page does notthwart the attacks.

How does the Google authorization server perform in thetest? The passing GoogleOAuthVulnerabilityTest indicates thatappropriate countermeasures are carried out by Goolge toensure access token requests are legitimate. For example, one-time use of authorization code and the clients authenticityare enforced by Google. To enhance user experience, Googleintroduces automatic authorization grant features in the au-thorization ow of OAuth 2.0. This means, if the user has

275

previously granted permissions to a client application not longago but currently not in a authenticated session state with theclient application, Google will not ask for the user to grantspermissions to the client if it receives the authorization requestfrom the client again. Instead, it will redirect the user backto the client application with a new generated authorizationcode. As both redirections happen instantly, the user doesnot realize the existence of the redirection. This reduces thenumber of mouse clicks users need to perform in order tologin into the client application. However, it may result inforced login Cross-Site Request Forgery (CSRF) if the clientapplication is vulnerable to CSRF attacks. For example, it doesnot check the Referer header eld or generate random tokensfor its pages. An attacker could take advantage of this featureto force the victim login into the client application without theknowledge of the victim. Then further attacks can be launchedto compromise the user data.

However, the impart of the attack could be minimized ifthe authorization server whitelists the redirection URI insteadof matching the domain . As we know, after the authorizationrequest is completed, the authorization server will redirect theuser to the registered redirection URI. If only some specicsecure URIs are permitted, it would be more difcult for anattacker to launch sequential attacks.

Furthermore, the forced login CSRF attacks is not likely tohappen in the situation where the signature of the authorizationrequest is required and the validation of the signature is en-forced by the authorization server. This signature requirementwas initially there in the protocol but was removed for thereason of simplicity. As a result, it is very difcult for theauthorization server to check the validity of the authorizationrequest due to lack of authenticity of the client application inthe request.

The pursues of simplicity often sacries the security of thesystem. There is a trade-off between simplicity and security.We recommend that automatic authorization granting featureshould only be turned on in a situation where the data securityis not so important. Alternately, it should be only enabled forthe client applications that meet the security requirement.

V. SUMMARY AND CONCLUSIONThe initial goal of OAuth 1.0 protocol is to enables users

to grant third-party applications access to their protectedresources without revealing their login credentials to thethird party. OAuth 2.0 removed several security features forsimplicity, which makes the implementation simple and easy.Unfortunately, simplicity often comes with less security. Theremoval of signature requirements, for example, is a serioussecurity concern. These relaxations in security makes thedeployment of network attacks easier.

We presented a systematic root cause analysis of securitythreats in different phases of the OAuth protocol. The attackermodel found out that there are several common networkattacks that could be possibly carried out by attackers toimpersonate users and access their protected resources, suchas replay attacks, network eavesdropping, forced-login CSRF

attacks, and impersonation attacks. We further investigatedthe root causes of these vulnerabilities and found out theyare possible because (1) No requirement or no recommenda-tion of TLS protection on callback endpoints; (2) Allowingmultiple uses of authorization codes; (3) The removal of thesignature requirement of authorization requests disables theauthorization server to validate the authenticity of the clientapplication; (4) No vetting process is enforced to ensure thesecurity of the client application before enabling the automaticauthorization granting feature; (5) Flexible redirection URIsvalidation mechanism is not adopted; and (6) No authenticityof the authorization code.

In this work, our analysis on the security threats of OAuthprotocol was focused on the communication (1) between theuser-agent and the authorization server, and (2) between theuser-agent and the client application. Future work remains toanalyse the security of the access token transmision betweenthe client application and the authorization server.

REFERENCES[1] D. Hardt, The OAuth 2.0 authorization framework, The Internet Eng.

Task Force RFC 6749, October 2012.[2] E. Hammer-Lahav, The OAuth 1.0 protocol, The Internet Eng. Task

Force RFC 5849, April 2010.[3] T. Lodderstedt, M. McGloin, and P. Hunt, OAuth 2.0 threat model and

security considerations, The Internet Eng. Task Force RFC 6819, April2013.

[4] J. Richer, W. Mills, and H. Tschofenig, OAuth 2.0 messageauthentication code (MAC) tokens, November 2012. [Online].Available: http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-00

[5] M. Jones and D. Hardt, OAuth 2.0: Bearer token usage, August2012. [Online]. Available: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-23

[6] K. P. L. Francisco Corella, Security analysis of double redirectionprotocols, Pomcor, Tech. Rep., February 2011.

[7] OpenID.net, OpenID authentication 2.0, OpenID Foundation, Decem-ber 2007.

[8] M. Uruena, A. Munoz, and D. Larrabeiti, Analysis of privacy vul-nerabilities in single sign-on mechanisms for multimedia websites,Multimedia Tools and Applications, pp. 118, 2012.

[9] S. Pai, Y. Sharma, S. Kumar, R. Pai, and S. Singh, Formal vericationof oauth 2.0 using alloy framework, in Intl. Conf. om CommunicationSystems and Network Technologies, 2011, pp. 655659.

[10] D. Jackson, Software Abstractions. MIT Press, November 2011.[11] C. U. Marino Miculan, Formal analysis of facebook connect single

sign-on authentication protocol, In SofSem 2011, Proceedings of Stu-dent Research Forum, 2011.

[12] C. Bansal, K. Bhargavan, and S. Maffeis, Discovering concrete attackson website authorization by formal analysis, in Proceedings of the IEEE25th Computer Security Foundations Symposium, 2012, pp. 247262.

[13] B. S. Bruno Blanchet, ProVerif: Automatic cryptographic protocolverier, user manual and tutorial, http://www.proverif.ens.fr/manual.pdf.

[14] R. Canetti, Universally composable security: A new paradigm forcryptographic protocols, Foundations of Computer Science, pp. 13614, 2001.

[15] S. Chari, C. S. Jutla, A. Roy, and A. Roy, Universally composablesecurity analysis of OAuth v2.0. IACR Cryptology ePrint Archive, p.526, 2011.

276