Introduction to the Emerging JSON-Based Identity and Security Protocols

An Introduction to the Emerging JSON-Based
Identity and Security Protocols
As Portfolio Architect for Ping Identity, Brian Campbell aspires to one day know
what a Portfolio Architect actually does for a living. In the meantime, he tries to
make himself useful by building software systems such as Ping‟s flagship product
PingFederate. When not making himself useful, he contributes to various identity
and security standards including a two-year stint as co-chair of the OASIS
Security Services Technical Committee (SAML) and a current focus on OAuth
2.0, JOSE and OpenID Connect. He holds a B.A., magna cum laude, in
Computer Science from Amherst College in Massachusetts. Despite spending
four years in the state, he has to look up how to spell "Massachusetts" every time
he writes it.
Brian Campbell
@weeUnquietMind
presents
Glue Conference 2013
slides: http://is.gd/1qoMXG

• Backstory
– With a Quick SAML Intro/Refresher
• Technical Overview of the new(ish) JSON-Based
Protocols
– URL Safe Base 64 Encoding
– JOSE Intro
• JWS
• JWE (just a wee bit)
• JWT
• JWK
– A slice of OAuth 2.0
– A bit of OpenID Connect
Agenda

• Security Assertion Markup Language
• XML-based framework that allows identity
and security information to be shared across
security domains
• Primarily used for cross domain Web browser
single sign-on
• Assertion is a (usually signed, sometimes
encrypted) security token
• Enterprisy Reputation
• Paying my bills for nearly a decade
Quick SAML Refresher

4
“one of the leading visionaries and analysts in the
computer industry” declared that…
SAML
is
DEAD!
Craig Burton

5
WTF “SAML is dead”?
I‟ve got a mortgage to
pay…
Beer is still
alive
though…
*Disclaimer: I work with these guys

6
The News Traveled Fast Beyond the Conference Walls
SAML

7
Death isn’t So Bad
"on your deathbed, you will receive total
consciousness."
http://blogs.kuppingercole.com/kearns/2012/07/31/the-
death-and-life-of-a-protocol/
Some Qualification / Clarification was Offered
Burton said: “SAML is the Windows XP of Identity.
No funding. No innovation. People still use it. But it
has no future.” And added, “There is no future for
SAML. No one is putting money into SAML
development. NO ONE is writing new SAML code.
SAML is dead.”
And then he reiterated for the hard of
understanding: “SAML is dead does not mean
SAML is bad. SAML is dead does not mean SAML
isn‟t useful. SAML is dead means SAML is not the
future.”
and I‟ve got 29 ½ years of mortgage
payments left and kids in private school so
maybe I should find out what *is* the future…

8
The Future
European Identity and Cloud Conference:
„“Best Innovation/New Standard in Information Security” went to OpenID Connect for
“Providing the Consumerization of SAML. Driving the adoption of federation and making
this much simpler.”‟
„OpenID Connect is a simple JSON/REST-based interoperable identity protocol built on top
of the OAuth 2.0 family of specifications. Its design philosophy is “make simple things
simple and make complicated things possible.”‟
three nerds holding a blurry piece of paper...
*Disclaimer: I also work with this guy

base64url
• It‟s like regular base64 but better!
– Both are a means of encoding binary data in an ASCII
string format
– Each 6 bits -> 1 character
– 3 bytes -> 4 characters
• Uses a URL safe alphabet rather than the almost
URL safe alphabet of regular base64
– “-” rather than “+”
– “_” rather than “/”
– Padding “=” is typically omitted
• A remaining unreserved URI character: “.”
– This will be important later

• Javascript Object Signing and Encryption
• IETF Working Group
– JWS
– JWE
– JWK
– JWA
JOSE

• JSON Web Signature
• A way of representing content secured with a
digital signature or MAC using JSON data
structures and base64url encoding
– Encoded segment are concatenated with a “.”
• Intended for space constrained environments
such as HTTP Authorization headers and URI
query parameters
• Conceptually Simple:
– Header.Payload.Signature
JWS

• JWS Header
– A bit of JSON that describes the digital signature or MAC operation applied to
create the JWS Signature value
• Reserved Header Parameter Names
– “alg”: Algorithm
• HMAC using SHA-XXX: HS256, HS384, HS512
• RSA using SHA-XXX: RS256, RS384, RS512
• ECDSA using P-XXX and SHA-XXX: ES256, ES384, ES512 (P-521)
• None
• Also extensible
– “kid”: Key ID
– “jku”: JWK Set URL
– “jwk”: JSON Web Key
– “x5u”: X.509 URL
– “x5t”: X.509 Certificate Thumbprint
– “x5c”: X.509 Certificate Chain
– “typ”: Type
– “cty”: Content Type
• Header Example
“I signed this thing with RSA-SHA256 using key ID of 9er and you can find the
corresponding public key at https://www.example.com/jwk”
{"alg":"RS256", "kid":”9er", "jwk”:"https://www.example.com/jwk"}
JWS Header

JWS Example
Payload -> USA #1!
base64url encoded payload -> VVNBICMxIQ
Header (going to sign with ECDSA P-256 SHA-256) -> {"alg":"ES256"}
base64url encoded header -> eyJhbGciOiJFUzI1NiJ9
Secured Input -> eyJhbGciOiJFUzI1NiJ9.VVNBICMxIQ
base64url encoded signature over the Secured Input
-> Y3xOwO2E99asvYvmAB-r37ikzgIzC6Kgu04_kBVrPizicWZ4lYTk3b7g5uHz0r6bi1U0Tg4eFwZWPAelrMMzk
JWS Compact Serialization ->
eyJhbGciOiJFUzI1NiJ9.VVNBICMxIQ.Y3xOwO2E99asvYvmAB-r37ikzgIzC6Kgu04_kBVrPizicWZ4lYTk3b7g5uHz0r6bi1U0Tg4eFwZWPAelrMMzkw
Which you can think of sort of like:
{"alg":"ES256"}.USA #1!.<SIGNATURE>

• Simple [Relatively]
• Compact
• No canonicalization
• Entirely Web Safe Alphabet
Some Strengths of JWS

• JSON Web Encryption
• Similar in motivation and design to JWS but for encrypting
content
– Header.EncryptedKey.InitializationVector.Ciphertext.AuthenticationTag
• More complicated
– More headers
• “alg”: Algorithm (key wrap or agreement)
• “enc”: Encryption Method (Authenticated Encryption only)
• “zip”: Compression Algorithm
• And more
– More options and variations
– More parts
JWE

• JSON Web Token
• Suggested pronunciation: "jot”
• Compact URL-safe means of representing
claims to be transferred between two parties
• A JWT is a JWS and/or JWE
– With JSON claims as the payload
JWT

• A piece of information asserted about a subject (or the
JWT itself). Here, Claims are represented name/value
pairs, consisting of a Claim Name and a Claim Value
(which can be any JSON object).
• Reserved Claim Names
– “iss”: Issuer
– “sub”: Subject
– “aud”: Audience
– “exp”: Expiration Time
– “nbf”: Not Before
– “iat”: Issued At
– “jti”: JWT ID
– “typ”: Type
JWT Claims

JWT Example
The JSON claims of a JWT saying that the subject is Brian, the JWT was
issued by https://idp.example.com, expires at such and such a time, and is
intended for consumption by https://sp.example.org (+ a few other things)
would look like this:
{
"iss":"https://idp.example.com",
"exp":1357255788,
"aud":"https://sp.example.org",
"jti":"tmYvYVU2x8LvN72B5Q_EacH._5A”,
"acr":"2",
"sub":"Brian”
}
Which becomes the JWS payload.
JWS Header saying it’s signed with ECDSA P-256 SHA-256 -> {"alg":"ES256"}
And the whole JWT->
eyJhbGciOiJFUzI1NiJ9.eyJpc3MiOiJodHRwczpcL1wvaWRwLmV4YW1wbGUuY29tIiwiZXhwIjo
xMzU3MjU1Nzg4LCJhdWQiOiJodHRwczpcL1wvc3AuZXhhbXBsZS5vcmciLCJqdGkiOiJ0bVl2WVZ
VMng4THZONzJCNVFfRWFjSC5fNUEiLCJhY3IiOiIyIiwic3ViIjoiQnJpYW4ifQ.2htJZOHbuk2k
pQUnfwcLrfqtKuhY8vJP8KU4O9pFBiea4fvpUHQK68M_yQj74EiBHruaarDGnpwaFrOtdbN06A

JWT alongside a comparable SAML Assertion
eyJhbGciOiJFUzI1NiJ9.
eyJpc3MiOiJodHRwczpcL1wvaWRwLmV4YW1wbGUuY29tIiwiZXhwIjoxMzU3MjU1Nzg4LCJhdWQiOiJodHRwczpcL1wvc3AuZXhhbXBsZS5vcmciLCJqdGkiOiJ0bVl2WVZVM
ng4THZONzJCNVFfRWFjSC5fNUEiLCJhY3IiOiIyIiwic3ViIjoiQnJpYW4ifQ.2htJZOHbuk2kpQUnfwcLrfqtKuhY8vJP8KU4O9pFBiea4fvpUHQK68M_yQj74EiBHruaarD
GnpwaFrOtdbN06A
<Assertion Version="2.0" IssueInstant="2013-01-03T23:34:38.546Z” ID="oPm.DxOqT3ZZi83IwuVr3x83xlr"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion” xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<Issuer>https://idp.example.com</Issuer>
<ds:Signature>
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/>
<ds:Reference URI="#oPm.DxOqT3ZZi83IwuVr3x83xlr">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>8JT03jjlsqBgXhStxmDhs2zlCPsgMkMTC1lIK9g7e0o=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>SAXf8eCmTjuhV742blyvLvVumZJ+TqiG3eMsRDUQU8RnNSspZzNJ8MOUwffkT6kvAR3BXeVzob5p
08jsb99UJQ==</ds:SignatureValue>
</ds:Signature>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">Brian</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData NotOnOrAfter="2013-01-03T23:39:38.552Z" Recipient="https://sp.example.org"/>
</SubjectConfirmation>
</Subject>
<Conditions NotOnOrAfter="2013-01-03T23:39:38.552Z" NotBefore="2013-01-03T23:29:38.552Z">
<AudienceRestriction>
<Audience>https://sp.example.org</Audience>
</AudienceRestriction>
</Conditions>
<AuthnStatement AuthnInstant="2013-01-03T23:34:38.483Z" SessionIndex="oPm.DxOqT3ZZi83IwuVr3x83xlr">
<AuthnContext>
<AuthnContextClassRef>2</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>

• JSON Web Key
• JSON representation of public keys with
some metadata
– RSA & Elliptic Curve
– JWK & JWK Set
JWK

JWK Parameters and Example
{"keys":
[
{"kty":"EC",
"crv":"P-256",
"x":"MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4",
"y":"4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM",
"kid":”9er"},
{"kty":"RSA",
"n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
"e":"AQAB",
"kid":”7ish"}
]
}
• Common Parameters: "kty”: Key Type, "use”: Key Use, "alg”: Algorithm, "kid”: Key
ID
• RSA: “n”: Modulus, “e”: Exponent
• EC: “crv”: Curve (P-256, P-384, P-521), “x”: X Coordinate, “y”: Y Coordinate

Side by Side JWK & X509 Certificate:
Data:
Version: 3 (0x2)
Serial Number:
01:3c:05:fe:51:4b
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=AU, O=Skull and Bones, CN=Brian's Key
Validity
Not Before: Jan 4 14:36:58 2013 GMT
Not After : Jan 6 14:36:58 2013 GMT
Subject: C=AU, O=Skull and Bones, CN=Brian's Key
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:83:aa:49:64:72:a1:0d:a6:93:ee:e8:6a:3a:94:
26:6e:3d:1d:8a:3a:5f:2e:31:b8:78:76:4f:58:6d:
92:4a:a1:e0:40:1f:ce:d5:8c:b7:1b:93:03:c5:65:
79:98:89:41:c5:2e:73:e4:b8:81:1f:d6:ae:74:0e:
29:0f:04:f9:80:45:23:e9:38:bf:b6:79:c5:3e:cd:
53:8f:59:e7:82:b8:cb:4f:73:0e:6d:84:13:b3:67:
e0:f0:94:d6:95:ef:f0:3d:ec:cc:21:82:a2:64:cc:
e8:d9:37:b6:e9:ac:10:2a:ef:d0:52:e2:5f:c4:67:
f1:fb:88:35:9d:39:ae:5d:45:27:d1:21:9f:33:18:
f3:a5:6f:13:20:b4:b9:58:dd:8e:93:82:9c:28:6a:
65:a0:a4:46:0a:72:5e:e5:93:0e:21:50:a8:4e:1b:
c2:15:e6:b7:77:23:de:9a:b8:63:a2:53:3e:a3:e5:
6f:6a:dd:f4:57:c4:c4:8d:d3:84:e7:3f:44:f3:66:
5c:66:59:0e:df:bf:88:d6:3d:ba:a5:dd:6e:c7:29:
cb:ac:94:b0:c9:9f:7e:41:f4:d3:ea:cf:bd:8a:13:
c2:a5:ad:67:96:9e:60:3c:a1:19:eb:29:14:18:a6:
cc:e6:9b:8f:f2:49:c1:bb:ab:bb:d2:a0:d1:96:ad:
92:2f
Exponent: 65537 (0x10001)
Signature Algorithm: sha1WithRSAEncryption
24:50:50:de:c3:94:f0:e8:32:88:a4:6c:36:c3:f3:b0:59:dc:
56:39:dd:36:0d:68:2b:3f:4d:4c:de:ef:f4:ff:23:ba:a9:a3:
3c:c8:29:41:21:0e:d3:94:89:a8:de:c8:f2:1f:10:4e:57:16:
5c:7a:36:2c:5c:df:2e:ff:cf:7e:9e:1e:6b:26:7b:ee:b2:8a:
68:29:cb:7a:b1:86:a8:a8:ba:94:b4:6d:ab:79:52:6e:84:39:
1f:28:35:b9:ee:ec:51:7d:22:33:82:e7:6c:a8:9c:45:8e:a7:
ab:93:79:39:9f:83:62:c1:9a:1d:64:bc:b3:39:c9:50:e4:78:
b3:8c:c4:ea:d5:d3:d7:41:c3:61:60:55:4e:20:a5:f2:56:30:
6c:f0:b5:58:45:88:c1:79:31:f4:ed:ab:2d:1e:3e:21:c5:2f:
a3:3b:8c:5b:38:04:d8:a7:02:4c:09:b3:18:1c:a3:49:50:5a:
96:a8:24:38:80:ee:c0:87:3c:c4:69:1d:10:cb:32:b6:61:9b:
a1:73:1a:f2:53:8f:29:e1:7a:42:14:57:77:1c:59:37:fb:99:
f9:c6:c6:88:c0:67:59:c7:eb:ac:e0:2c:bd:87:7c:27:a6:f5:
40:b3:e1:96:77:40:ec:2e:ca:ed:2b:54:fb:91:0c:68:07:16:
01:96:9e:fa
-----BEGIN CERTIFICATE-----
MIIC+DCCAeCgAwIBAgIGATwF/lFLMA0GCSqGSIb3DQEBBQUAMD0xCzAJBgNVBAYT
AkFVMRgwFgYDVQQKEw9Ta3VsbCBhbmQgQm9uZXMxFDASBgNVBAMTC0JyaWFuJ3Mg
S2V5MB4XDTEzMDEwNDE0MzY1OFoXDTEzMDEwNjE0MzY1OFowPTELMAkGA1UEBhMC
QVUxGDAWBgNVBAoTD1NrdWxsIGFuZCBCb25lczEUMBIGA1UEAxMLQnJpYW4ncyBL
ZXkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCDqklkcqENppPu6Go6
lCZuPR2KOl8uMbh4dk9YbZJKoeBAH87VjLcbkwPFZXmYiUHFLnPkuIEf1q50DikP
BPmARSPpOL+2ecU+zVOPWeeCuMtPcw5thBOzZ+DwlNaV7/A97MwhgqJkzOjZN7bp
rBAq79BS4l/EZ/H7iDWdOa5dRSfRIZ8zGPOlbxMgtLlY3Y6TgpwoamWgpEYKcl7l
kw4hUKhOG8IV5rd3I96auGOiUz6j5W9q3fRXxMSN04TnP0TzZlxmWQ7fv4jWPbql
3W7HKcuslLDJn35B9NPqz72KE8KlrWeWnmA8oRnrKRQYpszmm4/yScG7q7vSoNGW
rZIvAgMBAAEwDQYJKoZIhvcNAQEFBQADggEBACRQUN7DlPDoMoikbDbD87BZ3FY5
3TYNaCs/TUze7/T/I7qpozzIKUEhDtOUiajeyPIfEE5XFlx6Nixc3y7/z36eHmsm
e+6yimgpy3qxhqioupS0bat5Um6EOR8oNbnu7FF9IjOC52yonEWOp6uTeTmfg2LB
mh1kvLM5yVDkeLOMxOrV09dBw2FgVU4gpfJWMGzwtVhFiMF5MfTtqy0ePiHFL6M7
jFs4BNinAkwJsxgco0lQWpaoJDiA7sCHPMRpHRDLMrZhm6FzGvJTjynhekIUV3cc
WTf7mfnGxojAZ1nH66zgLL2HfCem9UCz4ZZ3QOwuyu0rVPuRDGgHFgGWnvo=
-----END CERTIFICATE-----
{
"kty":"RSA",
"n":"g6pJZHKhDaaT7uhqOpQmbj0dijpfLjG4eHZPWG2SSqHgQB_O1Yy3G5MDxWV5mIl
BxS5z5LiBH9audA4pDwT5gEUj6Ti_tnnFPs1Tj1nngrjLT3MObYQTs2fg8JTWle_wPez
MIYKiZMzo2Te26awQKu_QUuJfxGfx-
4g1nTmuXUUn0SGfMxjzpW8TILS5WN2Ok4KcKGploKRGCnJe5ZMOIVCoThvCFea3dyPem
rhjolM-o-Vvat30V8TEjdOE5z9E82ZcZlkO37-I1j26pd1uxynLrJSwyZ9-QfTT6s-
9ihPCpa1nlp5gPKEZ6ykUGKbM5puP8knBu6u70qDRlq2SLw",
"e":"AQAB”
}

• JWKs can be
– included in a JWS/JWE/JWT header
– saved in a file
– published at an HTTPS endpoint
– used in place of self signed certificates
JSON Web Key

• Java
– https://bitbucket.org/b_c/jose4j
• Ruby
– https://github.com/nov/json-jwt
• JavaScript
– http://kjur.github.com/jsjws/
• Perl
– https://metacpan.org/module/JSON::WebToken
Some JOSE/JWT Implementations
*Disclaimer: I‟m writing this one

OAuth Basic Abstract Flow
• client: An application
obtaining authorization and
making protected resource
requests.
– Native app on mobile device
• resource server (RS): A
server capable of accepting
and responding to protected
resource requests.
– Protected APIs
• authorization server (AS): A
server capable of issuing
tokens after successfully
authenticating the resource
owner and obtaining
authorization.
Client
Resource
Server
A few other protocol terms
• Access token (AT) – Presented by client when
accessed protected resources at the RS
• Refresh token (RT) - Allows clients to obtain a fresh
access token without re-obtaining authorization
• Scope – A permission (or set of permissions) defined
by the AS/RS
• Authorization endpoint – used by the client to obtain
authorization from the resource owner via user-agent
redirection
• Token endpoint – used for direct client to AS
communication
• Authorization Code – One time code issued by an AS
to be exchanged for an AT.
Authorization
Server

27
The OAuth 2.0 (RFC 6749)
Code Flow
a.k.a.
Authorization Code Grant Type
a.k.a.
Authorization Code Flow
a.k.a.
etc.

28
Authorization Server
Authorization
Endpoint
Token
Endpoint
Client
Resource Server
Protected
Resource(s)
Resource
Owner
OAuth 2.0
*Disclaimer: I also work with this guy

29
Authorization
Endpoint
Token
Endpoint
Client
Resource
Owner
Authorization Request with
response_type=code
OAuth 2.0
Resource Server
Protected
Resource(s)

30
Authorization
Endpoint
Token
Endpoint
Client
Resource Server
Protected
Resource(s)
Resource
Owner
Authenticate and Approve
OAuth 2.0
Resource Server
Protected
Resource(s)

31
Authorization
Endpoint
Token
Endpoint
Client
Resource
Owner
Authorization Response +
code
OAuth 2.0
Resource Server
Protected
Resource(s)

32
Authorization
Endpoint
Token
Endpoint
Client
Resource Server
Protected
Resource(s)
Resource
Owner
Access Token Request with
authorization_code grant type
+ code
OAuth 2.0
Resource Server
Protected
Resource(s)

33
Authorization
Endpoint
Token
Endpoint
Client
Resource Server
Protected
Resource(s)
Resource
Owner
Access Token Response with
Access Token (and maybe
Refresh)
OAuth 2.0
Resource Server
Protected
Resource(s)

34
Authorization
Endpoint
Token
Endpoint
Client
Resource Server
Protected
Resource(s)
Resource
Owner
Use Access Token to access
Protected Resources
OAuth 2.0
Resource Server
Protected
Resource(s)

35
OpenID Connect is a
simple identity layer on top
of the OAuth 2.0 protocol.

36
OpenID Connect
Basic Client Profile
or
Code Flow

37
Authorization Server /
Identity Provider /
OpenID Provider
Authorization
Endpoint
Token
Endpoin
t
Client /
Relying
Party
Resource
Owner /
OAuth 2.0
Resource Server
Protected
Resource(s)
OpenID Connect
Resource Server
User Info
Endpoint
End-User

38
Identity Provider /
OpenID Provider
Authorization
Endpoint
Token
Endpoin
t
Client /
Relying
Party
Resource
Owner /
OAuth 2.0
Resource Server
Protected
Resource(s)
OpenID Connect
Resource Server
User Info
Endpoint
End-User
Authorization Request with
response_type=code &
scope=openid profile email address phone
& maybe other new
stuff, request[_uri], prompt, nonce, etc.

39
Identity Provider /
OpenID Provider
Authorization
Endpoint
Token
Endpoin
t
Client /
Relying
Party
Resource
Owner /
OAuth 2.0
Resource Server
Protected
Resource(s)
OpenID Connect
Resource Server
User Info
Endpoint
End-User
Authenticate and Approve

40
Identity Provider /
OpenID Provider
Authorization
Endpoint
Token
Endpoin
t
Client /
Relying
Party
Resource
Owner /
OAuth 2.0
Resource Server
Protected
Resource(s)
OpenID Connect
Resource Server
User Info
Endpoint
End-User
Authorization Response + code

41
Identity Provider /
OpenID Provider
Authorization
Endpoint
Token
Endpoin
t
Client /
Relying
Party
Resource
Owner /
OAuth 2.0
Resource Server
Protected
Resource(s)
OpenID Connect
Resource Server
User Info
Endpoint
End-User
Access Token Request with
authorization_code grant type
+ code

42
Identity Provider /
OpenID Provider
Authorization
Endpoint
Token
Endpoin
t
Client /
Relying
Party
Resource
Owner /
OAuth 2.0
Resource Server
Protected
Resource(s)
OpenID Connect
Resource Server
User Info
Endpoint
End-User
Access Token Response with
Access Token
+ ID Token (JWT)

43
Identity Provider /
OpenID Provider
Authorization
Endpoint
Token
Endpoin
t
Client /
Relying
Party
Resource
Owner /
OAuth 2.0
Resource Server
Protected
Resource(s)
OpenID Connect
Resource Server
User Info
Endpoint
End-User
Use Access Token to access
User Info Endpoint

44
Identity Provider /
OpenID Provider
Authorization
Endpoint
Token
Endpoin
t
Client /
Relying
Party
Resource
Owner /
OAuth 2.0
Resource Server
Protected
Resource(s)
OpenID Connect
Resource Server
User Info
Endpoint
End-User
User Info Endpoint returns
additional claims about (aboot)
the authenticated End-User.

45
Identity Provider /
OpenID Provider
Authorization
Endpoint
Token
Endpoin
t
Client /
Relying
Party
Resource
Owner /
OAuth 2.0
Resource Server
Protected
Resource(s)
OpenID Connect
Resource Server
User Info
Endpoint
End-User
End-User is logged into the
Client/RP

46
Identity Provider /
OpenID Provider
Authorization
Endpoint
Token
Endpoin
t
Client /
Relying
Party
Resource
Owner /
OAuth 2.0
Resource Server
Protected
Resource(s)
OpenID Connect
Resource Server
User Info
Endpoint
End-User
[Maybe] Use Access Token to
access additional Protected
Resources

You’ve just been Introduced to some Emerging
JSON-Based Identity and Security Protocols
Brian Campbell
@weeUnquietMind
Gluecon 2013
http://is.gd/1qoMXG
SAML
Any Questions?

Introduction to the Emerging JSON-Based Identity and Security Protocols

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (15)

Similar to Introduction to the Emerging JSON-Based Identity and Security Protocols

Similar to Introduction to the Emerging JSON-Based Identity and Security Protocols (20)

More from Brian Campbell

More from Brian Campbell (13)

Recently uploaded

Recently uploaded (20)

Introduction to the Emerging JSON-Based Identity and Security Protocols