Comparison of Single Sign-On: Saml vs Oauth

vs Openid

Comparison of Single Sign-On: Saml vs Oauth vs Openid

For every way there is to keep data safe, there’s a way to attack it. You can use single-sign on,
firewalls, multi-factor authentication, and many other options. For IT professionals and developers,
the first thing to do is to choose the standard that needs to be deployed to keep federation identities
safe.

Unfortunately, the decision isn’t always clear cut. Many professionals have a hard time
distinguishing between security assertion markup language (SAML), Oauth, and OpenID. Each
standard brings structure to the federation process.

Let’s take a closer look at the differences between the standards, learn what each means, and why
organizations should use them.

https://www.purchasecontrol.com/blog/saml-vs-oauth-vs-openid/

1/6
What is Federated Identity?
In simple terms, federated identity refers to linking and using an electronic identity that the user has
across several systems. This means an application doesn’t necessarily need to obtain in-store
credentials in order to authenticate users. Rather the application can use an identity management
system that is already storing a user’s electronic identity to authenticate the user as long as the
application trusts that identity management system.

It all started with single sign-on (SSO) because companies required a way to unify all the
authentication systems in their organization, or easier management and better security.

The Difference Between Standards

The primary difference between SAML vs. Oauth vs. OpenID is that Oauth is a framework that
controls authorization to protected resources like applications or groups of files. OpenID Connect
and SAML, on the other hand, are industry standards for federated authentication. Because of this,
Oauth 2.0 is used in different situations, but it can be used at the same time as SAML or OpenID
Connect. OAuth 2.0 is a standard for resource authorization, not authentication.

You can use SAML or OpenID Connect independently to authenticate users and support single sign-
on. Even though they both deal with login, they have their own strengths and weaknesses.

OpenID Connect is built on the OAuth 2.0 protocol. It uses an ID token, an JSON web token to
standardize the areas OAuth 2.0 leaves to choice, including endpoint discovery and scopes. It
focuses solely on user authentication, and is mostly used to enable users to login to consumer
websites and mobile applications.

SAML runs independently of Oauth 2.0, and instead of JSON web token, it uses message exchange to
authenticate in XML. As such, it is more common to help organization users to use a single login for
multiple applications. It is an umbrella standard that addresses federation, single sign-on, and
identity management.

“It’s not about which structure a company should use, but is about when the company
should deploy each one. The strongest identity solution uses these structures to achieve
different things, depending on what the organization needs to protect.”

SAML
This is what allows users to login to identity providers (IdPs) or corporate intranet and then access
other services without needing to re-enter your credentials. It uses XML to exchange authentication

https://www.purchasecontrol.com/blog/saml-vs-oauth-vs-openid/

2/6
and authorization messages between IdPs and service providers to verify user identity and
permission, then either grants or denies access accordingly.

Terms to Know in SAML

Client: The web browser or other application the end user uses to access a resource or web
application.

Identity Provider: The server that owns the user identities and credentials.

Service Provider (SP): The protected application.

SAML Workflow

1. The end user clicks the login button for a file sharing service. The file sharing service is the
service provider and the end user is the client.
2. The file sharing service builds an SAML authentication request, signs, and optionally encrypts
it. Then, it sends it to the identity provider.
3. The file sharing service redirects the client’s browser to the identity provider for
authentication.
4. The identity provider verifies the received SAML authentication request. If valid, it presents a
login form for the user to enter their username and password.
5. After the client is successfully logged in, the identity provider generates a SAML assertion,
also known as a token. It includes the user identity and sends it directly to the service
provider.
6. The identity provider redirects the client back to the service provider.
7. The service provider verifies the SAML token, extracts the user identity from it, assigns the
correct permissions for the client and then logs them into the service.

OAuth
This standard provides secure delegated access, meaning an application can access sources or take
action on a server on a user’s behalf, without requiring users to log in or share sign-in information.
When you’ve set up a new smartphone and given permission to add your Facebook contacts to your
phone’s contacts, then it’s more than likely you’ve used OAuth 2.0.

Terms to Know in OAuth

Client: The web browser or other application the end user uses to access a resource or application.

Authorization Server: The server that owns the user identities and credentials.

https://www.purchasecontrol.com/blog/saml-vs-oauth-vs-openid/

3/6
Resource Server: The protected application.

OAuth Workflow

OAuth does not assume the client is a web browser. The workflow is as follows:

1. The end user clicks the login button for a file sharing service. The file sharing service is the
resource server and the end user is the client.
2. The resource server presents the client with an authorization grant and directs the client to
the authorization server.
3. The client requests an access token from the authorization server with the authorization code.
4. The client logs into the authorization server and checks to see if the code is valid. If so, the
client gets an access token that can be used to request a Protected resource from the resource
server.
5. After receiving a request for a protected resource with an access token, the resource server
will verify the token’s validity with the authorization server.
6. if the token is valid, the authorization server sends the information about the client to the
resource server.

OpenID
OpenID is an open standard companies can use to authenticate users. IdPs use this so users can sign
into the IdP then access other apps or websites without needing to share their sign-in information or
login again.

It’s an open source solution that handles the authentication process. Major companies like Google,
Microsoft, Ping Identity, Facebook, Yahoo, and PayPal sponsor the standard. It allows users to
choose the third-party OpenID provider they want to use to login to any website that accepts the
OpenID standard. If you’ve ever used your Google or Facebook accounts to sign into another service
or shopping cart, then you’ve seen OpenID in action.

OpenID is useful for app and website developers who want to authenticate users, but do not want
the responsibility of storing and managing their own user records due to the sheer volume of data
breach possibilities.

OpenID Connect is the third version of this standard. Before it came OpenID and OpenID 2.0.

Use Cases and the Standard to Use

Access to Applications from a Portal: Use SAML
Centralized Identity Source: Use SAML
Enterprise Single Sign-On: Use SAML

https://www.purchasecontrol.com/blog/saml-vs-oauth-vs-openid/

4/6
 Mobile use cases: Oauth or OpenID
Access to resources (either permanent or temporary): Oauth or OpenID

These of course, aren’t the only protocols for federated identity – just the most popular. Others
include: Higgins, Liberty Alliance, MicroID, and Windows CardSpace.

As technology continues to grow and we see even more interconnectivity between systems,
federated identity helps because it’s more convenient for users. It ensures they don’t have to
remember as many usernames and passwords – but it does present some security issues. The key to
its success lies in proper implementation – whether it is SAML, OAuth, or OpenID.

PurchaseControl works with single sign-on in your organization

Find Out How

https://www.purchasecontrol.com/blog/saml-vs-oauth-vs-openid/

5/6
 AboutPur
chaseCont
rol
Pur
chaseCont
roli
scl
oudbasedpr
ocur
ementsof
twar
eforbusi
ness
spendmanagement
.Weempowerbusi
nessesbypr
ovi
dinggr
eat
er
t
ranspar
encyandover
sighti
ntot
hepur
chasi
ngpr
ocess.Wi
th
Pur
chaseCont
rol
,youhavet
hef
lexi
bil
it
ytomanagehow spendact
ual
ly
happensi
nst
eadofhow youwi
shi
twoul
dhappen.

Theent
ir
ePur
chaseCont
rolt
eam hasexper
iencewi
thi
nar
ange
ofbusi
nesses,andassuch,webr
ingapr
act
ical
,hol
ist
icappr
oach
t
opur
chasi
ng.Weunder
standwhati
ttakest
orunabusi
nessandappl
y
t
hatknowl
edget
omakePur
chaseCont
rolasef
fect
iveaspossi
blef
oral
l
user
s.

Lear eatwww.
nmor pur
chasecont
rol
.com

Cont
act
s
EU Of
fi
ceI
nfor
mat
ion
UK:+448455912724
I
rel
and:+35315134623
enqui
ry@pur
chasecont
rol
.com

USOf
fi
ceI
nfor
mat
ion
US:8007375605
i
nqui
ry@pur
chasecont
rol
.com

ConnectWi
thUs
Facebook:ht
tps:
//www.
facebook.
com/
Pur
chaseCont
rol
/
Twi
tt
er:ht
tps:
//t
wit
ter
.com/
pur
chasecont
rol
/
Li
nkedI
n:ht
tps:
//www.
li
nkedi
n.com/
company/
pur
chasecont
ol/

https://www.purchasecontrol.com/blog/saml-vs-oauth-vs-openid/

6/6