Scribd
Upload
136 views

Saml Vs Oauth2 Terminology

SAML and OAuth2 are similar authentication protocols that both involve a service provider (resource server), client, and identity provider (authorization server). SAML involves the identity provider authenticating the user and generating a SAML token that is passed to the service provider. OAuth2 similarly involves the authorization server authenticating the user, but instead of a token it issues an authorization code and access token to the client, which can then request resources from the service provider on behalf of the user. Both protocols allow a user to authenticate with an identity provider and grant a service provider access without sharing their credentials.

Uploaded by

Rajesh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
136 views

Saml Vs Oauth2 Terminology

SAML and OAuth2 are similar authentication protocols that both involve a service provider (resource server), client, and identity provider (authorization server). SAML involves the identity provider authenticating the user and generating a SAML token that is passed to the service provider. OAuth2 similarly involves the authorization server authenticating the user, but instead of a token it issues an authorization code and access token to the client, which can then request resources from the service provider on behalf of the user. Both protocols allow a user to authenticate with an identity provider and grant a service provider access without sharing their credentials.

Uploaded by

Rajesh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

SAML vs OAuth2 terminology

SAML and OAuth2 use similar terms for similar concepts. For comparison the formal SAML term is listed
with the OAuth2 equivalent in parentheses.
 Service Provider (Resource Server) – this is the web-server you are trying to access information on.
 Client – this is how the user is interacting with the Resource Server, like a web app being served through a
web browser.
 Identity Provider (Authorization Server) – this is the server that owns the user identities and credentials.
It’s who the user actually authenticates with.
The most common SAML flow is shown below:

Here’s a fictitious scenario describing the above diagram:


 A – a user opens their web-browser and goes to MyPhotos.com which stores all of their photos.
MyPhotos.com doesn’t handle authentication itself.
 B – to authenticate the user MyPhotos.com constructs a SAML Authnrequest, signs it, optionally encrypts
it, and encodes it. After which, it redirects the user’s web browser to the Identidy Provider (IdP) in order to
authenticate. The IdP receives the request, decodes it, decrypts it if necessary, and verifies the signature.
 C – With a valid Authnrequest the IdP will present the user with a login form in which they can enter their
username and password.
 D– Once the user has logged in, the IdP generates a SAML token that includes identity information about
the user (such as their username, email, etc). The Id takes the SAML token and redirects the user back to
the Service Provider (MyPhotos.com).
 E – MyPhotos.com verifies the SAML token, decrypts it if necessary, and extracts out identity information
about the user, such as who they are and what their permissions might be. MyPhotos.com now logs the
user into its system, presumably with some kind of cookie and session.

At the end of the process the user can interact with MyPhotos.com as a logged in user. The user’s
credentials never passed through MyPhotos.com, only through the Identity Provider.

OAuth 2.0

 Resource Server (Service Provider) – this is the web-server you are trying to access information on.
 Client – this is how the user is interacting with the Resource Server. This could be a browser-based web
app, a native mobile app, a desktop app, a server-side app.
 Authorization Server (Identity Provider) – this is the server that owns the user identities and credentials.
It’s who the user actually authenticates and authorizes with.
At a high level, the OAuth2 flow is not that different from the earlier SAML flow:
 A – a user opens their web-browser and goes to MyPhotos.com which stores all of their photos.
MyPhotos.com doesn’t handle authentication itself, so the user is redirected to the Authorization Server
with a request for authorization. The user is presented with a login form and is asked if they want to
approve the Resource Server (MyPhotos.com) to act on their behalf. The user logs in and they are
redirected back to MyPhotos.com.
 B – the client receives an authorization grant code as a part of the redirect and then passes this along to the
client.
 C – the Client then uses that authorization grant code to request an access token from the Authorization
Server.
 D – if the authorization grant code is valid, then the Authorization Server grants an access token. The
access token is then used by the client to request resources from the Resource Server (MyPhotos.com).
 E – MyPhotos.com receives the request for a resource and it receives the access token. In order to make
sure it’s a valid access token it sends the token directly to the Authorization Server to validate. If valid, the
Authorization Server sends back information about the user.
 F – having validated the user’s request MyPhotos.com sends the requested resource back to the user.
This is the most common OAuth2 flow: the authorization code flow. OAuth2 provides three other flows
(or what they call authorization grants) which work for slightly different scenarios, such as single page
javascript apps, native mobile apps, native desktop apps, traditional web apps, and server-side applications
where a user isn’t directly involved but they’ve granted you permission to do something on their behalf.
The big advantage with OAuth2 flows are that the communication from the Authorization Server back to
the Client and Resource Server is done over HTTP Redirects with the token information provided as query
parameters. OAuth2 also doesn’t assume the Client is a web-browser whereas the default SAML Web
Browser SSO Profile does.
Native mobile applications will just work out of the box. No workarounds necessary.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy