This document reviews the security and performance of the OpenID Connect 1.0 protocol, which serves as an identity layer on top of OAuth 2.0, enabling client applications to verify user identities and obtain profile information. Key security aspects include vulnerabilities to attacks such as CSRF, replay, and MITM, emphasizing the necessity of secure communications. Performance analysis shows that both the authorization code and implicit flows exhibit high bandwidth efficiency, especially in authenticated traffic patterns.

1. Introducing OpenID Connect 1.0 protocol:
Security and Performance
M. Amin Saghizadeh
JUL 2015

2. 1) Introduction
In this document we review the security and performance of the OpenID Connect 1.0 protocol. OpenID
Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol [1]. It enables Clients to verify the
identity of the End-User based on the authentication performed by an Authorization Server, as well as to
obtain basic profile information about the End-User in an interoperable and REST-like manner [2].
After a brief introduction about the protocol and its flow in section 2, we review some security aspects
of the protocol in section 3 and see how secure is it against common attacks on authentication
protocols. Reviewing performance of the protocol and some considerations about high availability is in
section 4. We then conclude this document in section 5.
2) Introducing OpenID Connect 1.0 protocol
The OpenID Connect Core 1.0 specification [2] defines the core OpenID Connect functionality which is
authentication built on top of OAuth 2.0 and the use of Claims to communicate information about the
End-User. In this section, we introduce the protocol and discuss about its flows.
As background, the OAuth 2.0 Authorization Framework [1] and OAuth 2.0 Bearer Token Usage [3]
specifications provide a general framework for third-party applications to obtain and use limited access
to HTTP resources. They define mechanisms to obtain and use Access Tokens to access resources but do
not define standard methods to provide identity information. Notably, without profiling OAuth 2.0, it is
incapable of providing information about the authentication of an End-User.
The primary extension that OpenID Connect makes to OAuth 2.0 to enable end-users to be
authenticated, is the ID Token data structure. The ID Token is a security token that contains Claims about
the authentication of an end-user by an Authorization Server when using a Client, and potentially other
requested Claims. The ID Token is represented as a JSON Web Token (JWT) [4].
2-1) Basic Definitions
In this document we uses the key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD"
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be
interpreted as described in RFC 2119 [5].
The terms Access Token, Authorization Code, Authorization Endpoint, Authorization Grant, Authorization
Server, Client, Client Authentication, Client Identifier, Client Secret, Grant Type, Protected Resource,
Redirection URI, Refresh Token, Resource Owner, Resource Server, Response Type, and Token Endpoint
defined by OAuth 2.0 [1].
The terms Claim Name, Claim Value, JSON Web Token (JWT), JWT Claims Set, and Nested JWT defined by
JSON Web Token (JWT) [4].
The terms Header Parameter and JOSE Header defined by JSON Web Signature (JWS) [6]. The term User
Agent defined by RFC2616 [7], and the term Response Mode defined by OAuth 2.0 Multiple Response
Type Encoding Practices [8].
A complete list of the terminology is available in [2].
2-2) The Protocol Flow
Figure (1) illustrates how the whole protocol flows. The OpenID Connect protocol, in abstract, follows
the following steps.

3. 1. The RP (Client) sends a request to the OpenID Provider (OP).
2. The OP authenticates the End-User and obtains authorization.
3. The OP responds with an ID Token and usually an Access Token.
4. The RP can send a request with the Access Token to the UserInfo Endpoint.
5. The UserInfo Endpoint returns Claims about the End-User.
Figure 1 – OpenID Connect abstract protocol flow
OpenID Connect performs authentication to log in the end-user or to determine that the end-user is
already logged in. here, Clients are supposed to be websites, apps or devices which want to access to
the end-user informations. OpenID Connect returns the result of the authentication performed by the
server to the client in a secure manner so that the client can rely on it. For this reason, the client is called
Relying Party (RP) in this case.
The Authentication result is returned in an ID Token, as defined in [2]. It has Claims expressing such
information as the Issuer, the Subject Identifier, when the authentication expires, etc. Claims are groups
of attributes that are released to the Client (RP).
Authentication can follow one of three paths: the Authorization Code Flow, the Implicit Flow, or the
Hybrid Flow (using Response Type values defined in OAuth 2.0 Multiple Response Type Encoding
Practices [7]). The flows determine how the ID Token and Access Token are returned to the Client. In this
document we only discuss about Authorization Code Flow and Implicit Flow.

4. 2-2-1) Authentication using the Authorization Code Flow
When using the Authorization Code Flow, all tokens are returned from the Token Endpoint. The token
endpoint is the endpoint on the authorization server where the client application exchanges the
authorization code, client ID and client secret, for an access token [1]. Communication with the Token
Endpoint MUST utilize TLS.
The Authorization Code Flow returns an Authorization Code to the client, which can then exchange it for
an ID Token and an Access Token directly. This provides the benefit of not exposing any tokens to the
User Agent and possibly other malicious applications with access to the User Agent. The Authorization
Server can also authenticate the client before exchanging the Authorization Code for an Access Token.
The Authorization Code flow is suitable for clients that can securely maintain a client secret between
themselves and the authorization server.
The Authorization Endpoint performs authentication of the end-user. This is done by sending the User
Agent to the Authorization Server's Authorization Endpoint for authentication and authorization, using
request parameters defined by OAuth 2.0 and additional parameters and parameter values defined by
OpenID Connect. Communication with the Authorization Endpoint MUST also utilize TLS. Figure (2)
illustrates the Authorization Code flow.
Figure 2 – Authorization Code Flow
The Authorization Code flow goes through the following steps.

5. 1. Client prepares an authentication request containing the desired request parameters.
2. Client sends the request to the authorization server.
3. Authorization server authenticates the end-user.
4. Authorization server obtains end-user Consent/Authorization.
5. Authorization Server sends an Authorization Code to the end-user.
6. The end-user delivers the Authorization Code to the client through a redirect.
7. Client requests a response using the Authorization Code at the Token Endpoint.
8. Client receives a response that contains an ID Token and Access Token in the response body.
9. Client validates the ID Token and retrieves the End-User's Subject Identifier.
Finally, the client can submit its request to access user information by sending the Access Token and
retrieve the result.
2-2-2) Authentication using the Implicit Flow
When using the Implicit Flow, all tokens are returned from the Authorization Endpoint and the Token
Endpoint is not used. The Implicit Flow is mainly used by clients implemented in a browser using a
scripting language. The Access Token and ID Token are returned directly to the client, which may expose
them to the end-user and applications that have access to the end-user's User Agent. The authorization
server does not perform client authentication. Figure (3) shows the implicit flow.
Figure 3 – Implicit Flow

6. The Implicit Flow follows the following steps:
1. Client prepares an Authentication Request containing the desired request parameters.
2. Client sends the request to the Authorization Server.
3. Authorization Server Authenticates the End-User.
4. Authorization Server obtains End-User Consent/Authorization.
5. Authorization Server sends an ID Token and Access Token to the end-user.
6. The end-user delivers the ID Token and Access Token to the client through a redirect.
6. Client validates the ID token and retrieves the End-User's Subject Identifier.
From now on, the client can access user information by submitting the Access Token.
3) Security Analysis
In this section we review security of the mentioned flows. As the OpenID Connect protocol is built on
top of the OAuth 2.0 protocol without any modification on its flows, OpenID connect brings no security
by itself and highly relies on secure communications (TLS) like the OAuth 2.0 protocol. Here, we discuss
about possible attacks in absence of secure communication. A comprehensive official security and
privacy consideration is available in the protocol specifications document [2].
3-1) Compromising with CSRF Attack
Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a
web application in which they're currently authenticated [0]. CSRF attacks specifically target state-
changing requests, not theft of data, since the attacker has no way to see the response to the forged
request. In other words, CSRF attack is useful when the authenticated user can perform actions which
change the state of the system (i.e. Insert, Update and Delete), so this attack alone is not suitable when
the user just retrieves some protected data. A real example of CSRF attacks is available in [10].
As all Access Tokens are submitted by HTTP headers, attacker can simply perform a CSRF attack trying
to change the system state in account of the authenticated user. From the other side, the UserInfo
Endpoint has no idea which the forged request is legal or malicious and simply accepts it. Enabling TLS
alone also is not enough to protect against CSRF attack since the protocol has not a solution to recognize
the real origin of the request.
3-2) Compromising with Replay Attack
A replay attack occurs when an attacker copies a stream of messages between two parties and replays
the stream to one or more of the parties [11]. Unless mitigated, the computers subject to the attack
process the stream as legitimate messages, resulting in a range of unwanted consequences, such as
authenticating or recognizing the attacker as an authenticated user.
By eavesdropping Access Tokens, the attacker can perform replay attacks to impersonate the
authenticated user and perform whatever the client is authorized to do. The protocol itself does not
have a solution (usually a hashed or encrypted time stamp) to mitigate replay attacks.

7. 3-3) Compromising with MITM Attack
The man-in-the middle (MITM) attack intercepts a communication between two systems [12]. For
example, in an http transaction the target is the TCP connection between client and server. Using
different techniques, the attacker splits the original TCP connection into 2 new connections, one
between the client and the attacker and the other between the attacker and the server. Once the TCP
connection is intercepted, the attacker acts as a proxy, being able to read, insert and modify the data in
the intercepted communication.
By performing a MITM attack, the attacker can intercept the protected data and deliver incorrect data
or nothing to the client. It can impersonate the UserInfo Endpoint and collect Access Tokens of all clients
to perform replay attacks in the future. The attacker also is able to spread malicious data instead of the
user information requested by the client.
4) Performance Analysis
In this section we analyze performance of the above mentioned flows. We concentrate on the
performance of the communication and skip the computational and storage performance analysis of the
protocol. We also define each pair of Request – Response sent and received from/to an entity (client or
every provider) as an Interaction.
4-1) Performance of Authorization Code Flow
In this flow, there are four interaction when the client does not have an Access Token yet. Three of them
are between the client and the Authorization Server, and the other one is between the end-user and the
authorization server. So, half of the network load is on the authorization server, 37.5% on the client and
the other 12.5% is on the end-user. As the end-user usually authenticates himself to the authorization
server not more than once, so we can say that the network load is 50-50 between the client and the
authorization server. However, since the authorization server is a central third party, it becomes the
bottleneck of the system in heavy loads.
Therefore, if the communication pattern of the system is accessing a protected resource just once, then
in large scales of this pattern the bandwidth efficiency will be at least about 1/4 or 25%. This is because
that there are totally four interactions in a flow which one them is used to do the useful work (retrieving
protected resource). This situation can occur when there are many clients that want to access some
resources just once, or logout quickly.
However, if the traffic pattern of the system is accessing same resources, then most of clients submit
their access token with requests and don’t impose any other interaction to channel but the one to
retrieve the user information (protected resource). So, it can dramatically increase the bandwidth
efficiency. In this situation, the bandwidth efficiency is highly dependent on the amount of data
supposed to be retrieved and the length of the access token. Therefore, if the requested data is very
larger than the length of the access token, the bandwidth efficiency goes very high and OpenID Connect
is really a high performance protocol in this situation.
4-2) Performance of Implicit Flow
In this flow, there are three interaction when the client does not have an access token yet. Two of them
are between the client and the authorization server, and the other one is between the end-user and the
authorization server. So, half of the network load is on the authorization server, about 16.67% on the
end-user and about 33.33% is on the client. Like the previous flow, as the end-user usually authenticates
himself to the authorization server not more than once, so we can say that the network load is 50-50

8. between the client and the authorization server. However, since the authorization server is a central
third party, it becomes the bottleneck of the system in heavy loads. It is also worth noting that in implicit
flow, the authorization server has three interactions to deliver the protected resources which is one
interaction less than the authorization code flow.
Therefore, if the communication pattern of the system is accessing a protected resource just once, then
in large scales of this pattern the bandwidth efficiency will be at least about 1/3 or 33%. This is because
that there are totally three interactions in a flow which one them is used to do the useful work
(retrieving protected resource).
However, if the traffic pattern of the system is accessing same resources, then most of clients submit
their access token with requests and don’t impose any other interaction to channel but the one to
retrieve the user information (protected resource). So, it also will increase the bandwidth efficiency
dramatically. Like the other flow, here the bandwidth efficiency is highly dependent on the amount of
data supposed to be retrieved and the length of the access token. Therefore, if the requested data is
very larger than the length of the access token, the bandwidth efficiency goes very high and OpenID
Connect is really a high performance protocol in this situation, too.
5) Conclusion
In this document we first introduced the OpenID Connect 1.0 protocol. OpenID Connect 1.0 is a simple
identity layer on top of the OAuth 2.0 protocol. It enables clients to verify the identity of the end-user
based on the authentication performed by an Authorization Server, as well as to obtain basic profile
information about the end-user in an interoperable and REST-like manner.
Then we discussed about the security matters. Security of the OpenID Connect 1.0 protocol highly relies
on secure communications (TLS). If the communication goes through HTTP, the attacker can eavesdrop
the ID Token and Access Token to perform impersonation attacks. It also can perform information
disclosure and even MITM attacks and deliver wrong resources to the client.
We also analyzed the performance of the protocol in its two flows, each of which in two traffic patterns.
We saw that both of the flows are very high performance in authenticated traffic pattern, while the
implicit flow has a bit more performance in unauthenticated traffic pattern.
6) References
[1] Hardt, D., Ed., The OAuth 2.0 Authorization Framework, RFC 6749, DOI 10.17487/RFC6749,
October 2012, [ONLINE] Available at: http://www.rfc-editor.org/info/rfc6749. [Accessed 03 July
2015].
[2] OpenID Connect Core 1.0 incorporating errata set 1. 2014. OpenID Connect Core 1.0
incorporating errata set 1. [ONLINE] Available at: http://openid.net/specs/openid-connect-core-
1_0.html. [Accessed 09 July 2015].
[3] Jones, M., Hardt, D., The OAuth 2.0 Authorization Framework: Bearer Token Usage, RFC 6750,
DOI 10.17487/RFC6750, October 2012, [ONLINE] Available at: http://www.rfc-
editor.org/info/rfc6750. [Accessed 09 July 2015].

9. [4] Jones, M., Bradley, J., and N. Sakimura, JSON Web Token (JWT), draft-ietf-oauth-json-web-token
(work in progress), July 2014, [ONLINE] Available at: https://tools.ietf.org/html/draft-ietf-oauth-
json-web-token-32. [Accessed 09 July 2015].
[5] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997 [ONLINE] Available at: http://www.rfc-editor.org/info/rfc2119.
[Accessed 03 July 2015].
[6] Jones, M., Bradley, J., and N. Sakimura, JSON Web Signature (JWS), draft-ietf-oauth-json-web-
signature (work in progress), July 2014, [ONLINE] Available at: https://tools.ietf.org/html/draft-
ietf-oauth-json-web-signature-32. [Accessed 09 July 2015].
[7] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2068, DOI 10.17487/RFC2068, January 1997, [ONLINE] Available at:
http://www.rfc-editor.org/info/rfc2616. [Accessed 03 July 2015].
[8] OAuth 2.0 Multiple Response Type Encoding Practices. 2014. OAuth 2.0 Multiple Response Type
Encoding Practices. [ONLINE] Available at: http://openid.net/specs/oauth-v2-multiple-response-
types-1_0.html. [Accessed 09 July 2015].
[9] Cross-Site Request Forgery (CSRF) - OWASP. 2015. Cross-Site Request Forgery (CSRF) - OWASP.
[ONLINE] Available at:https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF).
[Accessed 07 July 2015].
[10]Introducing CSRF Attacks. 2015. Introducing CSRF Attacks. [ONLINE] Available at:
http://www.aparat.com/v/TOwmh/. [Accessed 07 July 2015].
[11]Replay Attacks - Microsoft. 2015. Replay Attacks - Microsoft. [ONLINE] Available at:
https://msdn.microsoft.com/en-us/library/aa738652(v=vs.110).aspx. [Accessed 07 July 2015].
[12]Man-in-the-middle attack - OWASP. 2015. Man-in-the-middle attack - OWASP. [ONLINE]
Available at: https://www.owasp.org/index.php/Man-in-the-middle_attack. [Accessed 07 July
2015].