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 2013slides: 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 OLD SCHOOL

NEW

SCHO

OL

• 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

Last July at

the

5

WTF “SAML is dead”? I’ve got a mortgage to

pay…

Beer is still alive

though…

Meanwhile

at the

*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 OfferedBurton 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

9WebFinger

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>

Example

• 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 ExampleThe 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.eyJpc3MiOiJodHRwczpcL1wvaWRwLmV4YW1wbGUuY29tIiwiZXhwIjoxMzU3MjU1Nzg4LCJhdWQiOiJodHRwczpcL1wvc3AuZXhhbXBsZS5vcmciLCJqdGkiOiJ0bVl2WVZVMng4THZONzJCNVFfRWFjSC5fNUEiLCJhY3IiOiIyIiwic3ViIjoiQnJpYW4ifQ.2htJZOHbuk2kpQUnfwcLrfqtKuhY8vJP8KU4O9pFBiea4fvpUHQK68M_yQj74EiBHruaarDGnpwaFrOtdbN06A

Example

JWT alongside a comparable SAML AssertioneyJhbGciOiJFUzI1NiJ9.eyJpc3MiOiJodHRwczpcL1wvaWRwLmV4YW1wbGUuY29tIiwiZXhwIjoxMzU3MjU1Nzg4LCJhdWQiOiJodHRwczpcL1wvc3AuZXhhbXBsZS5vcmciLCJqdGkiOiJ0bVl2WVZVMng4THZONzJCNVFfRWFjSC5fNUEiLCJhY3IiOiIyIiwic3ViIjoiQnJpYW4ifQ.2htJZOHbuk2kpQUnfwcLrfqtKuhY8vJP8KU4O9pFBiea4fvpUHQK68M_yQj74EiBHruaarDGnpwaFrOtdbN06A

<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+TqiG3eMsRDUQU8RnNSspZzNJ8MOUwffkT6kvAR3BXeVzob5p08jsb99UJQ==</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>

JWT

SAML

Examples

• 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

Example

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/lFLMA0GCSqGSIb3DQEBBQUAMD0xCzAJBgNVBAYTAkFVMRgwFgYDVQQKEw9Ta3VsbCBhbmQgQm9uZXMxFDASBgNVBAMTC0JyaWFuJ3MgS2V5MB4XDTEzMDEwNDE0MzY1OFoXDTEzMDEwNjE0MzY1OFowPTELMAkGA1UEBhMCQVUxGDAWBgNVBAoTD1NrdWxsIGFuZCBCb25lczEUMBIGA1UEAxMLQnJpYW4ncyBLZXkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCDqklkcqENppPu6Go6lCZuPR2KOl8uMbh4dk9YbZJKoeBAH87VjLcbkwPFZXmYiUHFLnPkuIEf1q50DikPBPmARSPpOL+2ecU+zVOPWeeCuMtPcw5thBOzZ+DwlNaV7/A97MwhgqJkzOjZN7bprBAq79BS4l/EZ/H7iDWdOa5dRSfRIZ8zGPOlbxMgtLlY3Y6TgpwoamWgpEYKcl7lkw4hUKhOG8IV5rd3I96auGOiUz6j5W9q3fRXxMSN04TnP0TzZlxmWQ7fv4jWPbql3W7HKcuslLDJn35B9NPqz72KE8KlrWeWnmA8oRnrKRQYpszmm4/yScG7q7vSoNGWrZIvAgMBAAEwDQYJKoZIhvcNAQEFBQADggEBACRQUN7DlPDoMoikbDbD87BZ3FY53TYNaCs/TUze7/T/I7qpozzIKUEhDtOUiajeyPIfEE5XFlx6Nixc3y7/z36eHmsme+6yimgpy3qxhqioupS0bat5Um6EOR8oNbnu7FF9IjOC52yonEWOp6uTeTmfg2LBmh1kvLM5yVDkeLOMxOrV09dBw2FgVU4gpfJWMGzwtVhFiMF5MfTtqy0ePiHFL6M7jFs4BNinAkwJsxgco0lQWpaoJDiA7sCHPMRpHRDLMrZhm6FzGvJTjynhekIUV3ccWTf7mfnGxojAZ1nH66zgLL2HfCem9UCz4ZZ3QOwuyu0rVPuRDGgHFgGWnvo=-----END CERTIFICATE-----

{"kty":"RSA","n":"g6pJZHKhDaaT7uhqOpQmbj0dijpfLjG4eHZPWG2SSqHgQB_O1Yy3G5MDxWV5mIlBxS5z5LiBH9audA4pDwT5gEUj6Ti_tnnFPs1Tj1nngrjLT3MObYQTs2fg8JTWle_wPezMIYKiZMzo2Te26awQKu_QUuJfxGfx-4g1nTmuXUUn0SGfMxjzpW8TILS5WN2Ok4KcKGploKRGCnJe5ZMOIVCoThvCFea3dyPemrhjolM-o-Vvat30V8TEjdOE5z9E82ZcZlkO37-I1j26pd1uxynLrJSwyZ9-QfTT6s-9ihPCpa1nlp5gPKEZ6ykUGKbM5puP8knBu6u70qDRlq2SLw","e":"AQAB”}

Examples

• 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.

ClientResource

Server

Get a token

Use a token

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.

AuthorizationServer

27

The OAuth 2.0 (RFC 6749)

Code Flowa.k.a.

Authorization Code Grant Typea.k.a.

Authorization Code Flowa.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 Server

Authorization Endpoint

Token Endpoint

Client

Resource Owner

Authorization Request with response_type=code

OAuth 2.0

Resource Server

Protected Resource(s)

30

Authorization Server

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 Server

Authorization Endpoint

Token Endpoint

Client

Resource Owner

Authorization Response + code

OAuth 2.0

Resource Server

Protected Resource(s)

32

Authorization Server

Authorization Endpoint

Token Endpoint

Client

Resource Server

Protected Resource(s)

Resource Owner

Access Token Request withauthorization_code grant type

+ code

OAuth 2.0

Resource Server

Protected Resource(s)

33

Authorization Server

Authorization Endpoint

Token Endpoint

Client

Resource Server

Protected Resource(s)

Resource Owner

Access Token Response withAccess Token (and maybe

Refresh)

OAuth 2.0

Resource Server

Protected Resource(s)

34

Authorization Server

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 Profileor

Code Flow

37

Authorization Server / Identity Provider / OpenID Provider

Authorization Endpoint

Token Endpoint

Client / Relying Party

Resource Owner /

OAuth 2.0

Resource Server

Protected Resource(s)

OpenID Connect

Resource Server

User Info Endpoint

End-User

38

Authorization Server / Identity Provider / OpenID Provider

Authorization Endpoint

Token Endpoint

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

Authorization Server / Identity Provider / OpenID Provider

Authorization Endpoint

Token Endpoint

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

Authorization Server / Identity Provider / OpenID Provider

Authorization Endpoint

Token Endpoint

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

Authorization Server / Identity Provider / OpenID Provider

Authorization Endpoint

Token Endpoint

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 withauthorization_code grant type

+ code

42

Authorization Server / Identity Provider / OpenID Provider

Authorization Endpoint

Token Endpoint

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 withAccess Token

+ ID Token (JWT)

43

Authorization Server / Identity Provider / OpenID Provider

Authorization Endpoint

Token Endpoint

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

Authorization Server / Identity Provider / OpenID Provider

Authorization Endpoint

Token Endpoint

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

Authorization Server / Identity Provider / OpenID Provider

Authorization Endpoint

Token Endpoint

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

Authorization Server / Identity Provider / OpenID Provider

Authorization Endpoint

Token Endpoint

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

47

Simple, ri

ght?

You’ve just been Introduced to some Emerging JSON-Based Identity and Security Protocols

Brian Campbell

@weeUnquietMind

Gluecon 2013

http://is.gd/1qoMXG

SAMLAny Questions?