This document provides an introduction and overview of SAML and OIDC for single sign-on and federated authentication. It describes the key components of each standard, including identity providers, service providers, assertions, flows, and tokens. SAML enables users to authenticate once and access multiple sites using circles of trust, while OIDC builds on OAuth2 and provides additional functionality for authentication with RESTful endpoints and easier token and claims handling.

1. © 2016 ForgeRock. All rights reserved.
Introduction to SAML & OIDC
@WayneBlacklock
wayne.blacklock@forgerock.com

2. © 2016 ForgeRock. All rights reserved.
What is the problem?
I want my users to access systems hosted by third parties, however:
● I do not want the third party to store credentials for my users.
● I also do not want my users to have to remember and enter yet
another set of credentials.
We can achieve this using federation.
SAML and OIDC are both types of federation ( though not the only types ).

3. © 2016 ForgeRock. All rights reserved.
Introducing SAML (Version 2)
SAML ( Security Assertion Markup Language ) is a standard which
enables a user to authenticate once and access multiple web sites across
different networks.
The SAML standard defines two different types of provider:
● Identity Provider (IdP): Authenticates users and stores user
credentials.
● Service Provider (SP): Where authenticated users go to consume
services.
We are going to look at the Authentication Request Protocol, there are
other protocols but this is the most important one.
https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

4. © 2016 ForgeRock. All rights reserved.
Circles of Trust
A circle of trust is a set of IdPs and SPs that
have been configured to trust SAML assertions
generated by each other.
Circle of Trust
SP
IdP
SP
SP
SP
As a user I login once to the IdP, then
I can access all of the SPs without
re-entering my credentials.

5. © 2016 ForgeRock. All rights reserved.
Assertions
SAML makes use of assertions, which is an XML payload of security
information about the user. There are two common assertions:
● Authentication Assertion: Confirms the user has proven their
identity.
● Attribute Assertion: Contain specific information about the user (e.g.
email address, name, etc).
Assertions are signed with an XML signature to prove they have not been
tampered with. They can also be encrypted if required.

6. © 2016 ForgeRock. All rights reserved.
Bindings
SAML assertions are commonly exchanged via the browser through
bindings:
● HTTP Redirect: SAML message carried directly in the URL of a GET request
as a parameter.
● HTTP Post: SAML message is contained in an XHTML form, which is then
automatically submitted ( via Javascript ) by the browser.
● HTTP Artifact: Passes references via redirect resolved using back channels
directly ( not via the browser ).

7. © 2016 ForgeRock. All rights reserved.
IDP Initiated SAML ( Post )
Browser IdP SP
Click on SP link
Redirect with authn response
Post to SP with authn response
Optionally
retrieve
attributes
Allow access to protected resource

8. © 2016 ForgeRock. All rights reserved.
SP Initiated SAML ( Post )
Browser IdP SP
Redirect with authn response
Post to SP with authn response
Optionally
retrieve
attributes
Allow access to protected resource
Browse to SP
Redirect with SAML authn request
* Authenticate if required
Post to IdP with authn request *

9. © 2016 ForgeRock. All rights reserved.
SAML
Users can now access resources securely cross domain, without yet
another set of credentials, however:
SAML:
● Requires pre-agreed metadata ( trust ) to be set up beforehand for
both IdP and SP
● Difficult to implement in native mobile apps
● Uses an XML based messaging structure ( as opposed to JSON )

10. © 2016 ForgeRock. All rights reserved.
Introducing OIDC
OpenID Connect ( OIDC ) is built on OAuth2 and adds authentication
functionality ( whereas OAuth2 is only for delegated access)
Like SAML it solves the problem of accessing different sites without
introducing yet another set of credentials.
You may have seen one of these
buttons, they use OIDC.
Sites can be OpenID certified

11. © 2016 ForgeRock. All rights reserved.
OIDC Parties
There are a number of different parties involved in OIDC flows:
● Relying Party: The application that is relying on a third party for user
authentication.
● OpenID Provider (Authz Server): The third party that will authenticate the
user.
● Endpoints:
○ TokenInfo: RESTful service for returning information about tokens.
○ UserInfo: RESTful service for retrieving claims about a user.

12. © 2016 ForgeRock. All rights reserved.
OIDC Scopes & Claims
Scopes & claims are the terms used in OIDC for requesting information
about a user.
● Scopes:
○ openid: Tells the OpenID provider the client is making an OIDC request
○ profile: Requests access to the users profile
○ email: Requests access to the users email
○ address: Requests access to the users address
○ phone: Requests access to the users phone
● Claims: Scopes map to sets of claims e.g.
○ A request for the profile scope returns something like…
○ A single scope may return multiple claims
"userinfo":
{
"claims":
{
"user_id": null,
"name": {"optional": true},
"nickname": {"optional": true}
…
}
}

13. © 2016 ForgeRock. All rights reserved.
OIDC Tokens
There are a number of different tokens involved in OIDC:
● ID Token: Confirms the user has been authenticated and contains claims
about the authenticated user.
● Access Token/Refresh Tokens: Grant or deny access to resources for a
period of time, and extend that access. Inherited from OAuth2.

14. © 2016 ForgeRock. All rights reserved.
OIDC Flows
There are three OIDC flows for authentication, these are a subset of
OAuth2 flows:
● Authorization Code Flow
● Implicit Flow
● Hybrid Flow
We are going to look at the Authorization Code Flow

15. © 2016 ForgeRock. All rights reserved.
OIDC Authorization Code Flow
Relying Party User
OpenID
Provider
Token
Endpoint
UserInfo
Endpoint
Authorization code request
Authenticate end user
User consent *
Redirect with....
...authorization code
Exchange code for tokens
Access Token & ID
Token
(Optional) Access token
(Optional) Userinfo response
Access protected resource
* Unless already granted

16. © 2016 ForgeRock. All rights reserved.
Why OIDC?
OIDC offers additional functionality over and above SAML:
● Dynamic registration & discovery: Discovery enables client
applications to automatically register themselves with the OIDC server.
● RESTful services: JSON based services that can be utilised by
mobile apps.
● Easy to consume tokens: OIDC utilises JWT’s ( JSON Web Tokens )
● Endpoints: That can flexibly return claims about the end user

17. © 2016 ForgeRock. All rights reserved.
?