A Survey on SSO Authentication protocols: Security and Performance

A Survey on SSO Authentication Protocols:
Security and Performance
M. Amin Saghizadeh
JUL 2015

1) Introduction
In this document we survey some of Single-Sign-On web authentication protocols and compare their
security and performance. In this survey we concentrate on OAuth 2.0 Authorization Framework [1],
OpenID Connect 1.0 [2], Central Authentication Service (CAS) 3.0 [3] and Security Assertion Markup
Language (SAML) 2.0 [4] protocols.
After a brief introduction about the protocols in section 2, we review some security aspects of protocols
and see how secure are them against common attacks on authentication protocols compare them in
section 3 and compare them based on their vulnerabilities. Reviewing performance of protocols and
some considerations about high availability is in section 4. We then conclude this document in section 5.
2) Protocols at Glance
In this section we briefly introduce each protocol chosen for this survey. Each protocol has several flows
and some performance and security considerations. For each protocol, we first present some basic
definitions and then introduce its flow(s) briefly.
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].
2-1) OAuth 2.0 Authorization Framework
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an
HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the
resource owner and the HTTP service, or by allowing the third-party application to obtain access on its
own behalf [1].
In the traditional client-server authentication model, the client requests an access-restricted resource
(protected resource) on the server by authenticating with the server using the resource owner's
credentials. In order to provide third-party applications access to restricted resources, the resource
owner shares its credentials with the third party. This creates several problems and limitations:
Third-party applications are required to store the resource owner's credentials for future use,
typically a password in clear-text.
Servers are required to support password authentication, despite the security weaknesses
inherent in passwords.
Third-party applications gain overly broad access to the resource owner's protected resources,
leaving resource owners without any ability to restrict duration or access to a limited subset of
resources.
Resource owners cannot revoke access to an individual third party without revoking access to all
third parties, and must do so by changing the third party's password.
Compromise of any third-party application results in compromise of the end-user's password
and all of the data protected by that password.
OAuth addresses these issues by introducing an authorization layer and separating the role of the client
from that of the resource owner. In OAuth, the client requests access to resources controlled by the

resource owner and hosted by the resource server, and is issued a different set of credentials than those
of the resource owner.
Instead of using the resource owner's credentials to access protected resources, the client obtains an
access token -- a string denoting a specific scope, lifetime, and other access attributes. Access tokens
are issued to third-party clients by an authorization server with the approval of the resource owner. The
client uses the access token to access the protected resources hosted by the resource server.
2-1-1) Basic Definitions
OAuth defines four roles in the protocol flow which can be assumed as an active entity. Along roles,
there are some special message passed between entities which have important meanings in the
protocol.
Resource Owner. An entity capable of granting access to a protected resource. When the resource
owner is a person, it is referred to as an end-user.
Resource Server. The server hosting the protected resources, capable of accepting and responding to
protected resource requests using access tokens.
Client. An application making protected resource requests on behalf of the resource owner and with its
authorization. The term "client" does not imply any particular implementation characteristics (e.g.,
whether the application executes on a server, a desktop, or other devices).
Authorization Server. The server issuing access tokens to the client after successfully authenticating the
resource owner and obtaining authorization.
Authorization Grant. An authorization grant is a credential representing the resource owner's
authorization (to access its protected resources) used by the client to obtain an access token. OAuth
standard defines four grant types: Authorization Code, Implicit, Resource Owner Password Credentials,
and Client Credentials. There is also an extensibility mechanism for defining additional types.
Access Token. Access tokens are credentials used to access protected resources. An access token is a
string representing an authorization issued to the client and is usually opaque to the client.
Refresh Token. Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to
the client by the authorization server and are used to obtain a new access token when the current
access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower
scope.
2-1-2) Protocol Flows
The abstract OAuth 2.0 flow illustrated in Figure (1) describes the interaction between the four roles and
includes the following steps:
Figure (1) - OAuth 2.0 abstract protocol flow

(A) The client requests authorization from the resource owner. The authorization request can
be made directly to the resource owner (as shown), or preferably indirectly via the authorization
server as an intermediary.
(B) The client receives an authorization grant, which is a credential representing the resource
owner's authorization, expressed using one of four grant types defined in this specification or
using an extension grant type. The authorization grant type depends on the method used by the
client to request authorization and the types supported by the authorization server.
(C) The client requests an access token by authenticating with the authorization server and
presenting the authorization grant.
(D) The authorization server authenticates the client and validates the authorization grant, and
if valid, issues an access token.
(E) The client requests the protected resource from the resource server and authenticates by
presenting the access token.
(F) The resource server validates the access token, and if valid, serves the request.
The preferred method for the client to obtain an authorization grant from the resource owner (depicted
in steps (A) and (B)) is to use the authorization server as an intermediary.
Authorization Code Flow
The authorization code grant type is used to obtain both access tokens and refresh tokens and is
optimized for confidential clients. Since this is a redirection-based flow, the client must be capable of

interacting with the resource owner's user-agent (typically a web browser) and capable of receiving
incoming requests (via redirection) from the authorization server.
Figure (2) illustrates the authorization code flow. Note that the lines illustrating steps (A), (B), and (C) are
broken into two parts as they pass through the user-agent.
Figure 2 – OAuth 2.0 Authorization Code Flow
The flow steps are as the following:
(A) The client initiates the flow by directing the resource owner's user-agent to the
authorization endpoint. The client includes its client identifier, requested scope, local state, and
a redirection URI to which the authorization server will send the user-agent back once access is
granted (or denied).
(B) The authorization server authenticates the resource owner (via the user-agent) and
establishes whether the resource owner grants or denies the client's access request.
(C) Assuming the resource owner grants access, the authorization server redirects the user-
agent back to the client using the redirection URI provided earlier (in the request or during client
registration). The redirection URI includes an authorization code and any local state provided by
the client earlier.

(D) The client requests an access token from the authorization server's token endpoint by
including the authorization code received in the previous step. When making the request, the
client authenticates with the authorization server. The client includes the redirection URI used
to obtain the authorization code for verification.
(E) The authorization server authenticates the client, validates the authorization code, and
ensures that the redirection URI received matches the URI used to redirect the client in step (C).
If valid, the authorization server responds back with an access token and, optionally, a refresh
token.
Implicit Flow
The implicit grant type is used to obtain access tokens (it does not support the issuance of refresh
tokens) and is optimized for public clients known to operate a particular redirection URI. These clients
are typically implemented in a browser using a scripting language such as JavaScript.
Since this is a redirection-based flow, the client must be capable of interacting with the resource
owner's user-agent (typically a web browser) and capable of receiving incoming requests (via
redirection) from the authorization server.
Unlike the authorization code grant type, in which the client makes separate requests for authorization
and for an access token, the client receives the access token as the result of the authorization request.
The implicit grant type does not include client authentication, and relies on the presence of the resource
owner and the registration of the redirection URI. Because the access token is encoded into the
redirection URI, it may be exposed to the resource owner and other applications residing on the same
device.
Figure (3) shows this flow. Please note that the lines illustrating steps (A) and (B) are broken into two
parts as they pass through the user-agent.
Figure 3 – Implicit Grant Flow

The flow includes the following steps:
(A) The client initiates the flow by directing the resource owner's user-agent to the
authorization endpoint. The client includes its client identifier, requested scope, local state, and
a redirection URI to which the authorization server will send the user-agent back once access is
granted (or denied).
(B) The authorization server authenticates the resource owner (via the user-agent) and
establishes whether the resource owner grants or denies the client's access request.
(C) Assuming the resource owner grants access, the authorization server redirects the user-
agent back to the client using the redirection URI provided earlier. The redirection URI includes
the access token in the URI fragment.
(D) The user-agent follows the redirection instructions by making a request to the web-hosted
client resource (which does not include the fragment per [RFC2616]). The user-agent retains the
fragment information locally.

(E) The web-hosted client resource returns a web page (typically an HTML document with an
embedded script) capable of accessing the full redirection URI including the fragment retained
by the user-agent, and extracting the access token (and other parameters) contained in the
fragment.
(F) The user-agent executes the script provided by the web-hosted client resource locally, which
extracts the access token.
(G) The user-agent passes the access token to the client.
2-2) OpenID Connect 1.0
OpenID Connect 1.0 protocol 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 [2].
As background, the OAuth 2.0 Authorization Framework [1] and OAuth 2.0 Bearer Token Usage [bearer]
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) [7].
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) [7].
The terms Header Parameter and JOSE Header defined by JSON Web Signature (JWS) [8]. The term User
Agent defined by RFC2616 [9], and the term Response Mode defined by OAuth 2.0 Multiple Response
Type Encoding Practices [10].
A complete list of the terminology is available in [2].
Figure (4) illustrates how the whole protocol flows. The OpenID Connect protocol, in abstract, follows
the following steps.
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 4 – 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 [10]). 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.
Authentication using 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 (5)
illustrates the Authorization Code flow.
Figure 5 – Authorization Code Flow
The Authorization Code flow goes through 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 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.
Authentication using 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 (6) shows the implicit flow.
Figure 6 – Implicit Flow
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.
2-3) Central Authentication Service 3.0
Central Authentication Service (CAS) protocol is a single-sign-on / single-sign-off (SSO) protocol for the
web originally created by Yale University to provide a trusted way for an application to authenticate a
user [3]. It permits a user to access multiple applications while providing their credentials (such as
USERID and PASSWORD) only once to a central CAS Server application.
The CAS protocol is a simple and powerful ticket-based protocol developed exclusively for CAS [11]. It
involves one or many clients and one server. Clients are embedded in classified applications called CAS
Services, whereas the CAS server is a standalone component. The CAS server is responsible for
authenticating users and granting accesses to applications and the CAS clients protect the CAS
applications and retrieve the identity of the granted users from the CAS server.
Before we proceed any further, we should take a look at some definitions and conventions used in the
rest of this subsection.
Client. Client refers to the end user and/or the web browser.
CAS Client. CAS Client refers to the software component that is integrated with a web application and
interacts with the CAS server via CAS protocol.
Server. Server refers to the Central Authentication Service server.
Service. Service refers to the application the client is trying to access.
Back-end Service. Back-end service refers to the application a service is trying to access on behalf of a
client. This can also be referred to as the Target Service.
SSO. SSO refers to Single Sign On.
SLO. SLO refers to Single Logout.
CAS is an HTTP-based [4] protocol that requires each of its components to be accessible through specific
URIs. There are two flows defined in CAS specification each of which somehow utilize these URIs.
Detailed information about URLs and their implementation parameters are out of scope of this
document and is available in [3].
Web Flow
As the client goes through the life cycle of the authentication process, it should operate differently in
some situations. When the client wants to access a protected application for the first time, it must login
to the CAS server with its credentials to obtain a session and a Ticket Granting Ticket (TGT) and a session
key. However, in further access attempts to that protected application, the client will only submit its
session key to the protected application. In addition, when the client wants to access another protected

application, it will submit its TGT to the application and after the validation, it receives another session
key and session cookie to access that application.
Figure (7) illustrates the process of the first access of the client to a protected application.
Figure 7 – First access to a protected application
At first, the client requests access to the protected application. As it is not authenticated yet, the
application redirects the client to the server. Server sees that the client doesn’t have a SSO session and
presents the login form to the client.
Client submits its credentials to the server. Server authenticates the client, generates a Ticket-Granting
Ticket (TGT) and sends it as a cookie to the client. This TGT is the session key of the session between the

client and the server. The server also generates a Service Ticket (TS) and sends it to the client by the
same cookie.
The client submits TS to the service (i.e. application). Then the application sends received TS to the
server in order that the server validates it. The server validates TS and returns a XML document
containing a success indicator, authenticated subject and other attributes.
Finally, the application generates a session key and sends it to the client. Now, the client can request
access to the application by submitting the session key. The application validates the session key and
serves the request of the client.
The steps of further accesses to the same protected application is shown in Figure (8).
Figure (8) – Further accesses to the same application
Like the last step of the previous process, the client requests access to the application by submitting the
session key. The application validates the session key and serves the request of the client.
Figure (9) shows the process of accessing new protected applications when the client has a TGT prom its
previous accesses to the other protected applications.
Figure 9 – First access to the other applications

Here, the client has authenticated itself to the server before. The client requests access to a new
protected application. As it has not a session key, the application redirects it to the server.
By this redirection, the client sends its TGT as the session key of its session with the server. The server
validates TGT (i.e. session key), generates a TS and sends it to the client.
The client sends TS to the application. The application validates the TS by sending it to the server and
receiving the success indicator from it. Then the application generates a session key for the client and
sends the session key to it.
From now on, the client can submit the session key and access to the application resources. The
application validates the session key and serves the request of the client.
Web Proxy Flow
One of the features of the CAS protocol is the ability for a CAS service to act as a proxy for another CAS
service, transmitting the user identity [11]. In this approach, the client first authenticate with the server
and setup a session with the proxy application to obtain a session key. Here, the client does not interact
with the protected application at all – it just send the request to the proxy and after protocol steps and
validations, the client receives requested resources of the application through the proxy. This approach
is consisted of two flows: load application proxy, and accessing application resources through the proxy.
Figure (10) shows the flow to setting up a session with the proxy application. This flow includes
authenticating with the server and obtaining a session key for accessing the proxy.
Figure 10 – Load application proxy

The client requests access to the proxy (not the application). As the client is not authenticated, the proxy
redirects it to the server. The server sees that the client doesn’t have a session key (TGT) and presents
the login form to it.
The client submits its credentials to the server. The server authenticates the client, generate a TGT and
sends it to the client as a cookie. The server also generates TS for the client and sends it by the same
cookie.
The client sends the ST to the proxy. The proxy validates the ST by sending it to the server. Along the ST,
the proxy sends a callback URL itself to the server. The final goal of this URL is to mitigate impersonation
attacks in the further steps.
The server validates the ST and generates a PGT. Instead of sending the PGT to the proxy, the server
sends the TGT as a PGT identifier, along with an IOU (PGTIOU) to the proxy. The proxy stores the PGT
(i.e. the identifier) and PGTIOU mapping for further use. Till now, the proxy is registered a callback URL
on the server, and received a receipt (PGT and PGTIOU) from it. From now on, by receiving the PGTIOU

from the server, the proxy can authenticate the server by finding a mapping between the PGTIOU and a
valid PGT (which in fact is a TGT of the client) and believes that the client is already authenticated to the
CAS server.
Then the proxy generates a session key for the client and sends the key to it. From now on, the client
can access the proxy by submitting that session key and finally receives a specific resource of the
application via the proxy. However, the client cannot access all other resources of the application or
resources of other applications by this session key.
This is true because the session key will be mapped to a specific PGT-PGTIOU pair, and that pair will be
mapped to a specific TGT on the CAS server, cause creation of a specific ST which is valid for accessing
specific resources of the application.
After setting up a session with the proxy, the client send its request to the proxy and receives requested
resources from the proxy application. Figure (11) illustrates this flow.
Figure 11 – Access to application resources via proxy
The client send a request to the proxy and submits session key. The proxy validates the session key and
retrieves the appropriate PGT and sends it to the server. Along the PGT, the proxy submits the target
service (i.e. application) URL to the server. The server generates a ST based on the target service URL
and sends it to the proxy.

The proxy sends ST to the application. Then, the application validates ST by sending it to the server. The
server retrieves the appropriate callback URL of the proxy and sends it to the application. Know, the
application can check whether this callback URL and the referrer URL of the previous request from the
proxy matches or not. If so, it believes that the proxy is itself and nobody is trying to impersonate it.
Then, the application generates a session key for the proxy and delivers it to the proxy. From now on,
the proxy can submits the session key to the application and it will receive the content requested by the
client from the application. The proxy then delivers the resource to the client.
2-4) Security Assertion Markup Language 2.0
Security Assertion Markup Language (SAML) 2.0 is an OASIS [5] standard and defines a framework for
exchanging security information between online business partners [4]. It defines a common XML
framework for exchanging security assertions between entities to define, enhance, and maintain a
standard XML-based framework for creating and exchanging authentication and authorization
information.
SAML is different from other security systems due to its approach of expressing assertions about a
subject that other applications within a network can trust. There are several drivers behind the creation
of the SAML standard [4]:
Limitations of Browser cookies. Most existing Single-Sign On products use browser cookies to
maintain state so that re-authentication is not required. Browser cookies are not transferred
between DNS domains. So, if you obtain a cookie from www.abc.com, then that cookie will not
be sent in any HTTP messages to www.xyz.com. This could even apply within an organization
that has separate DNS domains. Therefore, to solve the Cross-Domain SSO (CDSSO) problem
requires the application of different technology.
SSO Interoperability. How products implement SSO and CDSSO are completely proprietary. If
you are an organization and you want to perform SSO across different DNS domains within the
same organization or you want to perform CDSSO to trading partners, then you will have to use
the same SSO product in all the domains.
Web Services. Security within Web Services is still being defined. Most of the focus has been on
how to provide confidentiality and authentication/integrity services on an end-to-end basis. The
SAML standard provides the means by which authentication and authorization assertions can
exchanged between communicating parties.
Federation. The need to simplify identity management across organizational boundaries,
allowing users to consolidate many local identities into a single (or at least a reduced set)
Federated Identity.
There are two high-level use cases of the SAML standard. We now take a brief look at each of them.
Single-Sign-On Use case. This use case illustrates the support for Cross Domain Single Sign-On. A user
has a logon session (that is a security context) on a website (AirlineInc.com) and is accessing resources
on that site. At some either explicitly or transparently he is directed over to another web site (in a
different DNS domain). The Identity Provider site (AirlineInc.com) asserts to the Service Provider site
(CarRentalInc.com) that the user is known to it and provides the user's name and session attributes (e.g.
gold member). As CarRentalInc.com trusts AirlineInc.com it knows that the user is valid and creates a
session for the user based on the user's name and/or the user attributes. This use case illustrates the

fact that the user is not required to re-authenticate when directed over to the CarRentalInc.com site.
Figure (12) shows the SSO high-level use case.
Figure 12 – SSO high-level use case
Federation Use Case. This use case illustrates the “account linking” facet of federation [12]. Figure (13)
illustrates one possible scenario. Two Service Providers exist, one for car rentals the other for hotel
bookings. The same user is registered on both sites, however using different names. On
CarRentalInc.com he is registered as JDOE and on HotelBookings.com as JOHND. Account Linking
enables a pseudonym to be established that links the two accounts.
Figure 13 – Federation high-level use case

Before we proceed any further, we should take a look at some definitions and conventions used in the
rest of this subsection.
Identity Provider (IdP). The system or administrative domain that asserts information about a subject.
For instance, the identity provider asserts that this user has been authenticated and has given
associated attributes. In SAML, Identity Providers are also known as SAML Authorities and Asserting
Parties.
Service Provider (SP). The system or administrative domain that relies on information supplied to it by
the identity provider. It is up to the service provider as to whether it trusts the assertions provided to it.
Service providers are also known as Relying Parties.
Assertion. Assertions carry statements about a principal as asserted by an Asserting Party and are
defined by an XML Schema.
SAML protocol. SAML Protocols define how and which assertions are requested and they also have their
own XML schema.

Binding. Bindings define the lower-level communication or messaging protocols (such as HTTP or SOAP)
that the SAML Protocols can be transported over them.
Profile. SAML Protocols, Bindings and Assertions can be combined together to create a Profile. In
general, profiles are a set of rules and concepts satisfying a particular use case.
SSO. SSO refers to Single Sign On.
SLO. SLO refers to Single Logout.
The official SAML 2.0 Glossary is available in [13] which defines all concepts used in all other SAML
documents.
2-4-2) SAML Components
SAML consists of a number of building-block components that, when put together, allow a number of
use cases to be supported. Primarily the components permit transfer of identity, authentication, and
authorization information to be exchanged between autonomous organizations. This section describes
The SAML components and their individual parts. Detailed information about the individual parts can be
found in [4] and [14].
Assertion. SAML allows for one party to assert characteristics and attributes of an entity. For instance, a
SAML assertion could state that the user is “John Doe”, the user has “Gold” status, the user’s email
address is john.doe@example.com, and the user is a member of the “engineering” group. SAML
assertions are encoded in a XML schema. SAML defines three kinds of statements that can be carried
within an assertion: Authentication Statement, Attribute Statement and Authorization Decision
Statements. Technical details about assertions can be found in [14].
SAML protocol. SAML defines a number of request/response protocols. The protocols defined are
Assertion Query and Request Protocol, Authentication Request Protocol, Artifact Protocol, Name
Identifier Management Protocol, Single Logout Protocol and Name Identifier Mapping Protocol.
Technical details about protocols can also be found in [14].
Binding. It details exactly how the SAML protocol maps onto the transport protocols. For instance, the
SAML specification provides a binding of how SAML request/responses are carried with SOAP exchange
messages. The bindings defined are SAML SOAP, Reverse SOAP (PAOS), HTTP Redirect, HTTP Post, HTTP
Artifact and SAML URI Binding. More information and details about bindings are available in [15]
Profile. Profiles define how the SAML assertions, protocols and bindings are combined. The profiles
defined are Web Browser SSO, Enhanced Client and Proxy (ECP), Identity Provider Discovery, Single
Logout, Name Identifier Management, Artifact Resolution, Assertion Query/Request and Name Identifier
Mapping Profile. A comprehensive definition of each profile can be found in [16]
Figure (14) illustrates the relationship between the SAML components.
Figure 14 – Relationship between SAML components

Some real examples of implementation of the components and their structures can be find in [4].
This section is about how the protocol actually works. SAML supports a number of use cases and
profiles. Each use case with combination of a binding within a profile can be thought as a protocol flow.
In this section we describe two use cases of Web Browser SSO profile and analyze them in the rest of this
document. More information about all SAML profiles and their use cases can be found in [16].
Web Browser SSO profile supports some different types of model, based on how the message flows are
initiated (IdP or SP initiated), and which SAML bindings will be used when sending messages back and
forth between the IdP and SP. We discuss about two of them in this document. Figure (15) illustrates IdP
and SP Initiated approaches.

IdP Initiated. In this approach the user is accessing resources on the Identity Provider, and wishes to
access resources on another web site (the Service Provider). The user already has a current security
context with the Identity Provider. A SAML Assertion is provided to the Service Provider.
SP Initiated. Here, the user is accessing resources on the Service Provider and attempts to access a
protected resource requiring knowledge of their authentication and authorization attributes. The Service
Provider directs the request to their Identity Provider so that it may provide back SAML Assertion(s) in
order to validate whether they have access rights to the resource.
Figure 15 – IdP and SP Initiated approaches
Now we present the above mentioned protocol flows (use cases).
SP Initiated: Redirect/POST Binding
In this use case the user attempts to access a resource on the SP, sp.example.com. However it do not
have a current logon session on this site and its federated identity is managed by the IdP,
idp.example.org. The user is sent to the IdP to log on and the IdP provides a SAML web SSO Assertion for
the user's federated identity back to the SP. Figure (16) illustrates this flow.
Figure 16 – SP initiated Redirect/POST binding

The flow is as the following:
1. The user attempts to access a resource on sp.example.com. The user does not have a valid
logon session (i.e. security context) on this site. The SP saves the requested resource URL in local
state information that can be saved across the web SSO exchange.
2. The SP sends an HTTP redirect response to the browser (HTTP status 302 or 303). The
Location HTTP header contains the destination URI of the Sign-On Service at the identity
provider together with an <AuthnRequest> message encoded as a URL query variable named
SAMLRequest.
3. The Single Sign-On Service determines whether the user has an existing logon security context
at the identity provider that meets the default or requested (in the <AuthnRequest>)
authentication policy requirements. If not, the IdP interacts with the browser to challenge the
user to provide valid credentials.
4. The user provides valid credentials and a local logon security context is created for the user at
the IdP.

5. The IdP Single Sign-On Service builds a SAML assertion representing the user's logon security
context. Since a POST binding is going to be used, the assertion is digitally signed and then
placed within a SAML <Response> message. The <Response> message is then placed within an
HTML FORM as a hidden form control named SAMLResponse. If the IdP received a RelayState
value from the SP, it must return it unmodified to the SP in a hidden form control named
RelayState. The Single Sign-On Service sends the HTML form back to the browser in the HTTP
response. For ease of use purposes, the HTML FORM typically will be accompanied by script
code that will automatically post the form to the destination site.
6. The browser, due either to a user action or execution of an “auto-submit” script, issues an
HTTP POST request to send the form to the SP's Assertion Consumer Service.
7. An access check is made to establish whether the user has the correct authorization to access the
resource. If the access check passes, the resource is then returned to the browser.
IdP Initiated: POST Binding
In this use case the identity provider is configured with specialized links that refer to the desired service
providers. These links actually refer to the local IdP's Single Sign-On Service and pass parameters to the
service identifying the remote SP. So instead of visiting the SP directly, the user accesses the IdP site and
clicks on one of the links to gain access to the remote SP. This triggers the creation of a SAML assertion
that will be transported to the service provider using the HTTP POST binding. Figure (17) shows this flow.
Figure 17 – IdP initiated: POST binding

The flow is as the following:
1. If the user does not have a valid local security context at the IdP, at some point the user will
be challenged to supply their credentials to the IdP site, idp.example.org.
2. The user provides valid credentials and a local logon security context is created for the user at
the IdP.
3. The user selects a menu option or link on the IdP to request access to an SP web site,
sp.example.com. This causes the IdP's Single Sign-On Service to be called.
4. The Single Sign-On Service builds a SAML assertion representing the user's logon security
context. Since a POST binding is going to be used, the assertion is digitally signed before it is
placed within a SAML <Response> message. The <Response> message is then placed within an
HTML FORM as a hidden form control named SAMLResponse. (If the convention for identifying a
specific application resource at the SP is supported at the IdP and SP, the resource URL at the SP
is also encoded into the form using a hidden form control named RelayState.) The Single Sign-On
Service sends the HTML form back to the browser in the HTTP response. For ease-of-use

purposes, the HTML FORM typically will contain script code that will automatically post the form
to the destination site.
5. The browser, due either to a user action or execution of an “auto-submit” script, issues an
HTTP POST request to send the form to the SP's Assertion Consumer Service. The service
provider's Assertion Consumer Service obtains the <Response> message from the HTML FORM
for processing. The digital signature on the SAML assertion must first be validated and then the
assertion contents are processed in order to create a local logon security context for the user at
the SP. Once this completes, the SP retrieves the RelayState data (if any) to determine the
desired application resource URL and sends an HTTP redirect response to the browser directing
it to access the requested resource (not shown).
6. An access check is made to establish whether the user has the correct authorization to access the
resource. If the access check passes, the resource is then returned to the browser.
3) Security Analysis
In this section we review the security aspects and vulnerabilities of the mentioned protocol flows. First
we discuss about the importance of secure communication and reliance of the protocols security on it.
Then we review protocols vulnerabilities against some attacks on authentication protocols (CSRF, Replay
and MITM attacks).
3-1) Secure Communication
Secure communication is when two entities are communicating and do not want a third party to listen
in. For that they need to communicate in a way not susceptible to eavesdropping or interception and
usually is achieved by utilizing SSL or TLS protocol. Figure (18) shows that security of which protocols are
relying on secure communication.
Figure 18 – Protocols relying on secure communication
Protocols OAuth 2.0 OpenID Connect 1.0 CAS 3.0 SAML 2.0
Relied on? yes yes yes yes
All of mentioned protocols rely highly on secure communication. That’s because all sensitive
informations (session keys, access tokens, etc.) are transmitted in clear text and without any encryption.
In OAuth 2.0, the confidentiality of access tokens, and therefore the security of the protocol completely
relies on TLS and the protocol itself does nothing to keep access tokens confidential.
This issue also is not covered in OpenID Connect 1.0. As OpenID Connect 1.0 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.
CAS 3.0 also suffers from this issue. Almost all security concerns of CAS is from the fact that all
communication with the CAS server MUST occur over a secure channel (i.e. SSL or TLS). There are two

primary justifications for this requirement: The authentication process requires transmission of security
credentials, and the CAS ticket-granting ticket (TGT) is a bearer token. Since the disclosure of either data
would allow impersonation attacks, it’s vitally important to secure the communication channel between
CAS clients and the CAS server. Practically, it means that all CAS URLs must use HTTPS, but it also means
that all connections from the CAS server to the application must be done using HTTPS - when the
generated service ticket is sent back to the application on the service URL, and when a proxy callback
URL is called.
SAML 2.0 also brings no security by itself and highly relies on secure communications (SSL or TLS) or
some pre-existed trust relationship which also typically relies on PKI or asymmetric cryptography. So, it
has a minor advantage against other protocols and that is the support for enabling pre-existed trust.
3-2) 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 [17]. 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 [18]. Figure
(19) illustrates the vulnerability of protocols against CSRF attack.
Figure 19 – Protocols vulnerable to CSRF attack
Is Vulnerable? yes yes yes yes
In OAuth 2.0, authorization code and implicit flow are vulnerable to this attack. As the resource server
does not have a mechanism to distinguish the real origin of requests, it cannot detect malicious requests
that the client is unaware of them. So, all works that attacker should do is to somehow force the client
or user to perform the action which attacker wants (click on an element, etc.). Then the attacker forges
a request and sends it to the resource server and the browser will automatically attach the access token
to the request. The result is that the attacker performs an action on resource server in account of the
client.
OpenID Connect 1.0 is also vulnerable to CSRF attack. 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.
Nothing changes about this situation in CAS 3.0 protocol. As the session key is all the client needs to
access to protected resources, attacker can easily perform a CSRF attack just like the other protocols
mentioned above and the logging mechanisms will record the client as the sender of the forged request.

SAML 2.0 protocol is vulnerable to this attack too. As all SML Assertions are delivered by HTTP headers,
cookies or query strings in URLs, attacker can simply perform a CSRF attack trying to change the system
state in account of the authenticated user. From the other side, without the pre-existing trust, the
Service Provider has no idea which the forged request is legal or malicious and simply accepts it.
Enabling pre-existed trust 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-3) 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 [19]. 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. Figure (20) shows the vulnerability
of protocols against Replay attack.
Figure 20 – Protocols vulnerable to Replay attack
As the access token delivers in clear text to the client in OAuth 2.0 and the resource server only validates
the structure and expiration time of the access token, so the attacker can eavesdrop the communication
and record access tokens of all clients authenticated to the resource server. As a result, the attacker can
forge a cookie by writing the desired access token to it and easily impersonate the client, as long as the
access token is not expired.
In OpenID Connect 1.0, the attacker can perform replay attacks to impersonate the authenticated user
and perform whatever the client is authorized to do by eavesdropping Access Tokens. The protocol itself
does not have a solution (usually a hashed or encrypted time stamp) to mitigate replay attacks.
CAS 3.0 also lacks a mitigation mechanism against replay attack. The attacker can perform replay attack
by sending the appropriate session key in each step and it also performs an impersonation attack,
because all parties will be remembered by their session keys and those keys are sent through cookies or
HTTP headers and in clear text.
SAML 2.0 also is vulnerable to replay attacks. By eavesdropping SAML Assertions, the attacker can
perform replay attacks to impersonate the authenticated user and perform whatever the user can do.
The protocol itself does not have a solution (usually a hashed or encrypted time stamp) to mitigate
replay attacks.
3-4) Compromising with MITM Attack
The man-in-the middle (MITM) attack intercepts a communication between two systems [20]. 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. Figure (21) shows which protocols are vulnerable to MITM attacks.
Figure 21 – Protocols vulnerable to Replay attack
OAuth 2.0 is vulnerable to MITM attacks. Attacker can intercept the connection between the
authorization server and the client and issue wrong access token to perform some kind of denial-of-
Service attack. The attacker can also intercept the connection between the resource server and the
client and deliver wrong resources or malicious code to the client instead of the actual protected
resource.
In OpenID Connect 1.0, 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.
The attacker can perform MITM attacks in CAS 3.0 protocol too, and it can use this attack to bring
incorrect or harmful data instead of the protected resource. Like other protocols, there is no mechanism
to recognize the origin of requests and mitigate MITM attacks in CAS 3.0 protocol.
Like other protocols, in SAML 2.0 the attacker can intercept the protected data and deliver incorrect
data or nothing to the client by performing a MITM attack. It can impersonate the Identity Provider and
collect Assertions of all user to perform replay attacks in the future. The attacker also is able to
impersonate the Service Provider and spread malicious data instead of the protected data requested by
users.
3-5) Miscellaneous Considerations
There are several official documents available about security considerations and threat modeling for the
protocols we analyzed here. OAuth 2.0 Threat Model and Security Considerations (RFC 6819) is available
in [21]. A comprehensive official security and privacy consideration about OpenID Connect 1.0 is
available in the protocol specifications document [2]. There is a fair CAS 3.0 threat modeling and a
proposal to mitigate security risks available in [22] and [23] respectively from the Apereo Foundation
[24]. Some security features of CAS protocol and its implementation is mentioned in [25], too. A
comprehensive official security and privacy consideration document of SAML 2.0 protocol is also
available in [26].
4) Performance Analysis
In this section we analyze performance of the above mentioned protocols and its flows. We concentrate
on the communication performance and skip the computational and storage performance analysis of
the protocol.

4-1) Basic Definitions and Analysis Cases
We define each pair of Request – Response sent and received from/to an entity (user or every provider)
as an Interaction. We also define two analysis cases to discuss about and compare protocols based on
them. In fact, these analysis cases are two network traffic patterns based on the authenticity of the
client.
We define Unauthenticated Traffic Pattern (UnAuth Pattern from now on) to refer to a situation in
which the communication pattern of the system is accessing a protected resource just once. This
situation can occur when there are many clients that want to access some resources just once, or logout
quickly.
We also define Authenticated Traffic Pattern (Auth Pattern from now on) to refer to a situation in which
the traffic pattern of the system is accessing same resources repetitive. This situation is usually in the
web, where the client logins once, and perform authorized actions or access to its resources several
times during a session.
4-2) Performance of Protocols in UnAuth Pattern
Figure (22) shows a comparison of performance of protocols in the UnAuth pattern based on the
number of their interactions in this pattern.
Figure 22 – Bandwidth Efficiency of Protocols in UnAuth Pattern
Protocols and Flows Bandwidth Efficiency
OAuth 2.0
Authorization Code flow
16.67%
OAuth 2.0
Implicit flow
16.67%
OpenID Connect 1.0
25%
OpenID Connect 1.0
Implicit flow
33%
CAS 3.0
Web flow
16.67%
CAS 3.0
Web Proxy flow
16.67%
SAML 2.0
SP Initiated flow
25%
SAML 2.0
IdP Initiated flow
33%
In the following subsections we discuss about the bandwidth efficiency of protocol flows.

4-2-1) Performance of OAuth 2.0 Authorization Code Flow in UnAuth Pattern
In this flow, there are six interaction when the client does not have an Access Token yet. Five of them
are between the client and the Authorization Server, and the other one is between the resource owner
and the authorization server. So, half of the network load is on the authorization server, and the other
50% is on the client (As in web, the client is usually resource owner too). 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, in large scales of this pattern the bandwidth efficiency will be at least about 1/6 or 16.67%.
This is because that there are totally six interactions in a flow which one them is used to do the useful
work (retrieving protected resource).
4-2-2) Performance of OAuth 2.0 Implicit Flow in UnAuth Pattern
In this flow, there are also six 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 are between the client and the
resource server. So, half of the network load is on the client, about 25% on authorization server and the
other 25% is on the resource server. 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
between the client and the servers.
However, unlike the authorization code flow, since half of the load is balanced between authorization
server and resource server, then the authorization server is not the bottleneck of the system in heavy
loads anymore.
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 about 1/6 or 16.67%. This is because that
there are totally six interactions in a flow which one them is used to do the useful work (retrieving
protected resource).
4-2-3) Performance of OpenID Connect 1.0 Authorization Code Flow in UnAuth Pattern
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.
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).
4-2-4) Performance of OpenID Connect 1.0 Implicit Flow in UnAuth Pattern
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

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.
that there are totally three interactions in a flow which one them is used to do the useful work
(retrieving protected resource).
4-2-5) Performance of CAS 3.0 Web Flow in UnAuth Pattern
Web flow is consisted of three separate phases: First Access, Second Access, and First Access to Another.
We discuss about performance of each phase in this section and then take an overall look at the
performance of the web flow.
There are six interactions in the First Access as illustrated in Figure (7). Two of them are between the
client and the server, and another one of the six is between the server and the application. That is, the
server is engaged in 50% of the communication.
If the communication pattern of the system is accessing a protected application just once, then in large
scales of this pattern, the server will handle about 50% the network traffic and it becomes the
bottleneck of the whole system. Therefore, the bandwidth efficiency will be about 1/6 or 16.67%. This
situation can occur when a server is responsible for protecting many applications and there are many
clients that want to access some application just once, or logout quickly.
4-2-6) Performance of CAS 3.0 Web Proxy Flow in UnAuth Pattern
Proxy flow is consisted of two separate phases: Load Proxy and Access via Proxy. We discuss about
performance of Load Proxy phase in this section and then take an overall look at the performance of the
proxy flow in this traffic pattern.
Like the web flow, there are six interaction in the Load Proxy as shown in figure (10). Two of them are
between the proxy and the client, and two of them also are between the proxy and the server. That is,
the proxy is engaged in 66.67% of the communication.
If the communication pattern of the system is accessing a protected application just once, then in large
scales of this pattern, the proxy will handle about 66.67% the network traffic and it becomes the
bottleneck of the whole system. In this situation, the bandwidth efficiency at the best case will be about
1/6 or 16.67%. The reason for this low efficiency is that the purpose of this phase to generate a session
key for the client and the proxy which costs one effective interaction. However, six interactions is
performed to achieve that goal. As it said, 16.67% is the best efficiency here and can be achieved when
the content length of the session key is equal with all content lengths of all other interactions. So, it will
be lower than 16.67% in the real world scenarios.
4-2-7) Performance of SAML 2.0 SP Initiated flow in UnAuth Pattern
In this flow, there are four interaction when the user is not authenticated (does not have an Assertion
yet). Two of them are between the client and the Service Provider, and the other two are between the
client and the Identity Provider. So, half of the network load is on the client, 25% on the SP and the other
25% is on the IdP. As a result, from the provider point of view, this flow is a high performance and fair
protocol and none of the providers becomes bottleneck of the system.

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.
4-2-8) Performance of SAML 2.0 IdP Initiated flow in UnAuth Pattern
In this flow, there are three interaction when the user is not authenticated (does not have a security
context with the IdP). Two of them are between the client and the Identity Provider, and the other one is
between the client and the Service Provider. So, half of the network load is on the client, about 16.67%
on the SP and about 33.33% is on the IdP. As a result, from the SP point of view, this flow is a high
performance and in IdP opinion, it’s not a so heavy load. So, none of the providers becomes bottleneck
of the system.
that there are totally three interactions in a flow which one them is used to do the useful work
(retrieving protected resource).
4-3) Performance of Protocols in Auth Pattern
Figure (23) shows a comparison of bandwidth efficiency of protocols in the Auth pattern based on the
number of their interactions in this pattern.
Figure 23 – Bandwidth Efficiency of Protocols in Auth Pattern
Protocols and Flows Bandwidth Efficiency
OAuth 2.0
( + )
OAuth 2.0
Implicit flow
( + )
OpenID Connect 1.0
( + )
OpenID Connect 1.0
Implicit flow
( + )
CAS 3.0
Web flow
( + )
CAS 3.0
Web Proxy flow
20%
SAML 2.0
SP Initiated flow
( + )
SAML 2.0
IdP Initiated flow
( + )

Here, n is the length of the resource supposed to be retrieved and t (Token) refers to the length of
access token, session key or assertion. In the following subsections we discuss about the bandwidth
efficiency of protocol flows.
4-3-1) Performance of OAuth 2.0 Authorization Code Flow in Auth Pattern
In this flow with the Auth pattern applied, 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-3-2) Performance of OAuth 2.0 Implicit Flow in Auth Pattern
When Auth pattern applied to this flow, 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
protocol in this situation, too.
4-3-3) Performance of OpenID Connect 1.0 Authorization Code Flow in Auth Pattern
In this flow, 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-3-4) Performance of OpenID Connect 1.0 Implicit Flow in Auth Pattern
When Auth pattern applied to this flow, 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
4-3-5) Performance of CAS 3.0 Web Flow in Auth Pattern
As a reminder, Web flow of CAS 3.0 is consisted of three separate phases: First Access, Second Access,
and First Access to Another. Here we discuss about Second Access and First Access to Another phases.
There is only one interaction is in the Second Access, as shown in figure (8) and it is between client and
application. So, server is completely idle in this phase and it can be a good point because the server can
dedicate its resources to handle First Access phases of the client.

From the other side, there is five interaction in the First Access to Another as you see in figure (9). Server
is a pair of two of them, one with client and the other with application. Therefore, the work of server is
reduced from 50% to 40% in comparison to the First Access phase.
So in the Auth pattern, most of requests don’t impose any interaction to channel as there is only one
interaction in the second Access and it is used to retrieve requested resources too. So, it can
dramatically increase the bandwidth efficiency. In this situation, the bandwidth is highly dependent of
the amount of protected resources and data supposed to be retrieved and length of the session key.
Therefore, if the requested data is very larger than the length of the session key, the bandwidth
efficiency goes very high and CAS is really a high performance protocol in this situation.
4-3-6) Performance of CAS 3.0 Web Proxy Flow in Auth Pattern
As a background, Proxy flow is consisted of two separate phases: Load Proxy and Access via Proxy. We
are going to analyze the bandwidth efficiency of the Access via Proxy phase here.
There are five interactions in the Access via Proxy phase as illustrated in figure (5) and the proxy is
engaged in four of them. That is, the proxy is engaged in 80% of the communication here. However, the
client and server are idle most of the time and the application also is engaged in 40% of the
communication.
So in Auth pattern, most of requests goes through the Access via Proxy phase and it make thing worse
for the proxy – the proxy will be engaged in 80% of the traffic and becomes a more critical bottleneck in
the system. From the other hand, the bandwidth efficiency is about 20% at the worst condition. The
reason is that the length of the requested data can be large in comparison to the content length of other
interactions.
4-3-7) Performance of SAML 2.0 SP Initiated flow in Auth Pattern
In this flow, if the traffic pattern of the system is accessing same resources, then most of users submit
their assertions with requests and don’t impose any other interaction to channel as there but the one to
retrieve requested resources. So, it can dramatically increase the bandwidth efficiency. In this situation,
the bandwidth is highly dependent on the amount of data supposed to be retrieved and the length of
the assertion. Therefore, if the requested data is very larger than the length of the assertion, the
bandwidth efficiency goes very high and SAML is really a high performance protocol in this situation.
4-3-8) Performance of SAML 2.0 IdP Initiated flow in Auth Pattern
There are two interactions in this flow when the user has a security context with the IdP. One of them
are between the client and the IdP, and the other one is between the client and the SP. So, half of the
network load is on the client, 25% on the IdP and the other 25% is on the SP. As a result, from the
provider point of view, in this situation the protocol act as a high performance and fair protocol and
none of the providers becomes bottleneck of the system.
Therefore, in Auth pattern, most of users have a security context with the IdP and perform two
interactions to retrieve the protected resources. The bandwidth also is dependent on the amount of
data supposed to be retrieved. Therefore, if the requested data is very larger than the length of the
other interaction, the bandwidth efficiency can go very high and SAML can be a high performance
4-4) Miscellaneous Analysis Results
In this subsection, we present some results of our analysis about bandwidth efficiency and behavior of
protocols in different network traffic patterns:

It can be said that all protocols have low performance in unauthenticated network traffic
pattern. However, there is some notable differences in some protocols. As an example,
performance of OpenID Connect 1.0 and SAML 2.0 is twice of OAuth 2.0 in UnAuth traffic
pattern.
There is not any significant difference between performance of protocols and their flows in
authenticated network traffic pattern, except CAS 3.0 web proxy flow.
In OpenID Connect 1.0, 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.
Two main results can be deducted from the discussion about performance of CAS 3.0: protocol
flows (web and proxy) show opposite performance results in the above mentioned traffic
patterns, and the low performance of the proxy flow is mainly the cost of mitigating
impersonation attacks (the attacker couldn’t impersonate the proxy) and reducing the traffic
load of the server.
About SAML 2.0, it is seen that protocol flows show opposite behavior about bandwidth
efficiency. The SP initiated flow has more performance in authenticated traffic pattern and the
IdP initiated flow has more performance in unauthenticated traffic pattern.
5) Conclusion
In this document we surveyed on some of SSO web authentication protocols and compare their security
and performance. We concentrated on OAuth 2.0 Authorization Framework, OpenID Connect 1.0,
Central Authentication Service (CAS) 3.0 and Security Assertion Markup Language (SAML) 2.0 in this
survey.
First we presented each protocol and its most used flows briefly and discussed about steps of each
protocol flow. The OAuth 2.0 authorization framework enables a third-party application to obtain
limited access to an HTTP service, either on behalf of a resource, or by allowing the third-party
application to obtain access on its own behalf. OpenID Connect 1.0 protocol 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. Central Authentication Service (CAS)
protocol is a single-sign-on / single-sign-off (SSO) protocol for the web originally created by Yale
University to provide a trusted way for an application to authenticate a user. Security Assertion Markup
Language (SAML) 2.0 is an OASIS standard and defines a framework for exchanging security information
between online business partners. It defines a common XML framework for exchanging security
assertions between entities to define, enhance, and maintain a standard XML-based framework for
creating and exchanging authentication and authorization information.
Then we compared them based on their vulnerabilities against some major attacks on authentication
protocols. We focused on CSRF, Replay and MITM attacks. In absence of secure communications (SSL,
TLS) all protocols are vulnerable to all mentioned attacks. Except CAS 3.0 web proxy flow that mitigates
some kinds of MITM attacks (impersonation attacks) by itself.
Finally, we analyzed bandwidth efficiency of each protocol and its flows, each of which in two network
traffic pattern and discussed about their performance and whether a party could become the bottleneck
of the system or not. We also present some results of our analysis and did a comparison of them on

their behavior in different traffic patterns. Except CAS 3.0 web proxy flow, all of protocol flows are high
performance protocols in authenticated network 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] CAS - CAS Protocol Specification. 2015. CAS - CAS Protocol Specification. [ONLINE] Available at:
http://jasig.github.io/cas/development/protocol/CAS-Protocol-Specification.html. [Accessed 26
June 2015].
[4] SAML Technical Overview | SAML XML.org. 2005. SAML Technical Overview | SAML XML.org.
[ONLINE] Available at: http://saml.xml.org/saml-technical-overview. [Accessed 03 July 2015].
[5] OASIS | Advancing open standards for the information society. 2015. OASIS | Advancing open
standards for the information society. [ONLINE] Available at: https://www.oasis-open.org/.
[Accessed 03 July 2015].
[6] 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.
[7] 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].
[8] 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].
[9] 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].
[10]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].
[11]CAS - CAS Protocol. 2015. CAS - CAS Protocol. [ONLINE] Available at:
http://jasig.github.io/cas/4.0.x/protocol/CAS-Protocol.html. [Accessed 25 June 2015].
[12]Federated identity - Wikipedia, the free encyclopedia. 2015. Federated identity - Wikipedia, the
free encyclopedia. [ONLINE] Available at: https://en.wikipedia.org/wiki/Federated_identity.

[13]Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0| SAML XML.org.
2005. Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0 | SAML XML.org.
[ONLINE] Available at: https://www.oasis-open.org/committees/download.php/21111/saml-
glossary-2.0-os.html. [Accessed 03 July 2015].
[14]Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 | SAML
XML.org. 2005. Assertions and Protocols for the OASIS Security Assertion Markup Language
(SAML) V2.0 | SAML XML.org. [ONLINE] Available at: http://docs.oasis-
open.org/security/saml/v2.0/saml-core-2.0-os.pdf. [Accessed 03 July 2015].
[15]Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0 | SAML XML.org.
2005. Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0 | SAML XML.org.
[ONLINE] Available at: http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf.
[16]Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0 | SAML XML.org.
2005. Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0 | SAML XML.org.
[ONLINE] Available at: http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf.
[17]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).
[18]Introducing CSRF Attacks. 2015. Introducing CSRF Attacks. [ONLINE] Available at:
http://www.aparat.com/v/TOwmh/. [Accessed 07 July 2015].
[19]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].
[20]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].
[21]Lodderstedt, T., OAuth 2.0 Threat Model and Security Considerations, RFC 2119, DOI
10.17487/RFC6819, JUN 2013 [ONLINE] Available at: http://www.rfc-editor.org/info/rfc6819.
[22]CAS Threat Modeling - Central Authentication Service - Apereo Wiki. 2015. CAS Threat Modeling
- Central Authentication Service - Apereo Wiki. [ONLINE] Available at:
https://wiki.jasig.org/display/CAS/CAS+Threat+Modeling. [Accessed 26 June 2015].
[23]Proposals to mitigate security risks - Central Authentication Service - Apereo Wiki.
2015. Proposals to mitigate security risks - Central Authentication Service - Apereo Wiki.
[ONLINE] Available at: https://wiki.jasig.org/display/CAS/Proposals+to+mitigate+security+risks.
[Accessed 26 June 2015].
[24]Apereo Foundation | Apereo. 2015. Apereo Foundation | Apereo. [ONLINE] Available
at: https://www.apereo.org/. [Accessed 26 June 2015].
[25]CAS - Security Guide. 2015. CAS - Security Guide. [ONLINE] Available at:
http://jasig.github.io/cas/4.0.x/planning/Security-Guide.html#secure-transport-https. [Accessed
26 June 2015].

[26]Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML)
V2.0 | SAML XML.org. 2005. Security and Privacy Considerations for the OASIS Security Assertion
Markup Language (SAML) V2.0 | SAML XML.org. [ONLINE] Available at: http://docs.oasis-
open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf. [Accessed 03 July 2015].

A Survey on SSO Authentication protocols: Security and Performance

Recommended

More Related Content

What's hot (20)

Viewers also liked (19)

Similar to A Survey on SSO Authentication protocols: Security and Performance (20)

Recently uploaded (19)

A Survey on SSO Authentication protocols: Security and Performance