Abstract image of a woman sitting on books and studying on a laptop

Introduction to the Emerging JSON-Based Identity and Security Protocols

Download as PPTX, PDF
Brian Campbell, profile picture
Brian Campbell

This document provides an agenda and overview for a presentation on emerging JSON-based identity and security protocols. The presentation will begin with a quick refresher on SAML, then provide a technical overview of new protocols including JOSE, JWS, JWE, JWT, JWK and OAuth 2.0 and OpenID Connect. These new protocols use JSON and are designed to be more compact and Web-friendly compared to older XML-based standards like SAML.

Technology
1 of 48
Downloaded 198 times
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
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
9 WebFinger
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 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 with authorization_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 with Access 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 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 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 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 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 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 Authorization Response + code
41 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 Access Token Request with authorization_code grant type + code
42 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 Access Token Response with Access Token + ID Token (JWT)
43 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 Use Access Token to access User Info Endpoint
44 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 User Info Endpoint returns additional claims about (aboot) the authenticated End-User.
45 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 End-User is logged into the Client/RP
46 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 [Maybe] Use Access Token to access additional Protected Resources
47
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?

More Related Content

PPTX
I Left My JWT in San JOSE
Brian Campbell
 
PPTX
An Introduction to the Emerging JSON-Based Identity and Security Protocols (O...
Brian Campbell
 
PPTX
JOSE Can You See...
Brian Campbell
 
PDF
Javascript Object Signing & Encryption
Aaron Zauner
 
PDF
JSON Web Tokens (JWT)
Vladimir Dzhuvinov
 
PDF
CIS14: I Left My JWT in San JOSE
CloudIDSummit
 
PPT
Advanced Json
guestfd7d7c
 
PDF
Deciphering Explain Output
MongoDB
 
I Left My JWT in San JOSE
Brian Campbell
 
An Introduction to the Emerging JSON-Based Identity and Security Protocols (O...
Brian Campbell
 
JOSE Can You See...
Brian Campbell
 
Javascript Object Signing & Encryption
Aaron Zauner
 
JSON Web Tokens (JWT)
Vladimir Dzhuvinov
 
CIS14: I Left My JWT in San JOSE
CloudIDSummit
 
Advanced Json
guestfd7d7c
 
Deciphering Explain Output
MongoDB
 

What's hot (20)

PDF
Session 5 - NGSI-LD Advanced Operations | Train the Trainers Program
FIWARE
 
PDF
FIWARE Global Summit - Hands-On NGSI-LD
FIWARE
 
PDF
Data Modeling with NGSI, NGSI-LD
Fernando Lopez Aguilar
 
PDF
ActiveRecord vs Mongoid
Ivan Nemytchenko
 
PDF
Using Mongoid with Ruby on Rails
Nicholas Altobelli
 
PDF
JSMVCOMFG - To sternly look at JavaScript MVC and Templating Frameworks
Mario Heiderich
 
KEY
Practical Ruby Projects (Alex Sharp)
MongoSF
 
KEY
Practical Ruby Projects with MongoDB - MongoSF
Alex Sharp
 
PPTX
MongoDB + Java - Everything you need to know
Norberto Leite
 
PDF
MongoDB SoCal 2020: Best Practices for Working with IoT and Time-series Data
MongoDB
 
PDF
Nio
nextlib
 
PDF
What do you mean, Backwards Compatibility?
Trisha Gee
 
PDF
Building your first app with MongoDB
Norberto Leite
 
PDF
MongoDB .local Chicago 2019: Practical Data Modeling for MongoDB: Tutorial
MongoDB
 
PDF
12 core technologies you should learn, love, and hate to be a 'real' technocrat
Jonathan Linowes
 
PDF
Distributed Identities with OpenID
Bastian Hofmann
 
PPTX
Performance and Security Enhancements in MongoDB's BI Connector
MongoDB
 
PDF
Session 2 - NGSI-LD primer & Smart Data Models | Train the Trainers Program
FIWARE
 
PDF
What the Heck is OAuth and OpenID Connect? Connect.Tech 2017
Matt Raible
 
PPTX
Java Persistence Frameworks for MongoDB
Tobias Trelle
 
Session 5 - NGSI-LD Advanced Operations | Train the Trainers Program
FIWARE
 
FIWARE Global Summit - Hands-On NGSI-LD
FIWARE
 
Data Modeling with NGSI, NGSI-LD
Fernando Lopez Aguilar
 
ActiveRecord vs Mongoid
Ivan Nemytchenko
 
Using Mongoid with Ruby on Rails
Nicholas Altobelli
 
JSMVCOMFG - To sternly look at JavaScript MVC and Templating Frameworks
Mario Heiderich
 
Practical Ruby Projects (Alex Sharp)
MongoSF
 
Practical Ruby Projects with MongoDB - MongoSF
Alex Sharp
 
MongoDB + Java - Everything you need to know
Norberto Leite
 
MongoDB SoCal 2020: Best Practices for Working with IoT and Time-series Data
MongoDB
 
Nio
nextlib
 
What do you mean, Backwards Compatibility?
Trisha Gee
 
Building your first app with MongoDB
Norberto Leite
 
MongoDB .local Chicago 2019: Practical Data Modeling for MongoDB: Tutorial
MongoDB
 
12 core technologies you should learn, love, and hate to be a 'real' technocrat
Jonathan Linowes
 
Distributed Identities with OpenID
Bastian Hofmann
 
Performance and Security Enhancements in MongoDB's BI Connector
MongoDB
 
Session 2 - NGSI-LD primer & Smart Data Models | Train the Trainers Program
FIWARE
 
What the Heck is OAuth and OpenID Connect? Connect.Tech 2017
Matt Raible
 
Java Persistence Frameworks for MongoDB
Tobias Trelle
 
Ad

Viewers also liked (15)

DOCX
Introducción protocolo
gegh23
 
PDF
Protecting JavaScript source code using obfuscation - OWASP Europe Tour 2013 ...
AuditMark
 
PDF
Auth in the extended enterprise - Keynote for MIT Legal Hack A Thon 2013
Justin Richer
 
PPTX
Trade key
Zuhaib Ali
 
PDF
Introduction to OAuth2.0
Oracle Corporation
 
PPTX
Principles and patterns for test driven development
Stephen Fuqua
 
PDF
Ty vacuum turbine oil purifier
ganglilian
 
PPTX
Postman Collection Format v2.0 (pre-draft)
Postman
 
PPT
Chapter 4: Business Buying Behavior
tjamisonedu
 
PPTX
Securing RESTful APIs using OAuth 2 and OpenID Connect
Jonathan LeBlanc
 
PPTX
What's Better than Microservices? Serverless Microservices.
Apigee | Google Cloud
 
PDF
Analisis de trabajo seguro
Evelyn Stella Pacheco Arzuza
 
PDF
Levi's Marketing Plan
Dawoine Camel
 
PPTX
OAuth 2.0 and Mobile Devices: Is that a token in your phone in your pocket or...
Brian Campbell
 
PPTX
40+ tips to use Postman more efficiently
postmanclient
 
Introducción protocolo
gegh23
 
Protecting JavaScript source code using obfuscation - OWASP Europe Tour 2013 ...
AuditMark
 
Auth in the extended enterprise - Keynote for MIT Legal Hack A Thon 2013
Justin Richer
 
Trade key
Zuhaib Ali
 
Introduction to OAuth2.0
Oracle Corporation
 
Principles and patterns for test driven development
Stephen Fuqua
 
Ty vacuum turbine oil purifier
ganglilian
 
Postman Collection Format v2.0 (pre-draft)
Postman
 
Chapter 4: Business Buying Behavior
tjamisonedu
 
Securing RESTful APIs using OAuth 2 and OpenID Connect
Jonathan LeBlanc
 
What's Better than Microservices? Serverless Microservices.
Apigee | Google Cloud
 
Analisis de trabajo seguro
Evelyn Stella Pacheco Arzuza
 
Levi's Marketing Plan
Dawoine Camel
 
OAuth 2.0 and Mobile Devices: Is that a token in your phone in your pocket or...
Brian Campbell
 
40+ tips to use Postman more efficiently
postmanclient
 
Ad

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

PPTX
Microservices Security Patterns & Protocols with Spring & PCF
VMware Tanzu
 
PDF
A Primer on JSON Web Tokens
Chris Herbert
 
PPTX
Uniface Lectures Webinar - Application & Infrastructure Security - JSON Web T...
Uniface
 
PDF
Don't Loose Sleep - Secure Your Rest - php[tek] 2017
Adam Englander
 
PDF
Con Foo 2017 - Don't Loose Sleep - Secure Your REST
Adam Englander
 
PDF
PHP UK 2017 - Don't Lose Sleep - Secure Your REST
Adam Englander
 
PPTX
The JSON-based Identity Protocol Suite
Twobo Technologies
 
PPTX
JWTs and JOSE in a flash
Evan J Johnson (Not a CISSP)
 
PDF
Overview of JSON Object Signing and Encryption
Masaru Kurahayashi
 
PDF
Openstack identity protocols unconference
David Waite
 
PPTX
JsonWebTokens ppt - explains JWT, JWS , JWE Tokens
nagarajapallafl
 
PPTX
DDD Melbourne 2019 : Modern Authentication 101
Dasith Wijesiriwardena
 
PDF
JDD2015: Security in the era of modern applications and services - Bolesław D...
PROIDEA
 
PDF
Introduction to JWT and How to integrate with Spring Security
Bruno Henrique Rother
 
PDF
Secure JAX-RS
Rudy De Busscher
 
PDF
JSON Web Tokens Will Improve Your Life
John Anderson
 
PDF
[4developers2016] - Security in the era of modern applications and services (...
PROIDEA
 
PPTX
Pentesting jwt
Jaya Kumar Kondapalli
 
PPTX
IAM Overview Identiverse 2018
Brian Campbell
 
PDF
Landscape
Amit Gupta
 
Microservices Security Patterns & Protocols with Spring & PCF
VMware Tanzu
 
A Primer on JSON Web Tokens
Chris Herbert
 
Uniface Lectures Webinar - Application & Infrastructure Security - JSON Web T...
Uniface
 
Don't Loose Sleep - Secure Your Rest - php[tek] 2017
Adam Englander
 
Con Foo 2017 - Don't Loose Sleep - Secure Your REST
Adam Englander
 
PHP UK 2017 - Don't Lose Sleep - Secure Your REST
Adam Englander
 
The JSON-based Identity Protocol Suite
Twobo Technologies
 
JWTs and JOSE in a flash
Evan J Johnson (Not a CISSP)
 
Overview of JSON Object Signing and Encryption
Masaru Kurahayashi
 
Openstack identity protocols unconference
David Waite
 
JsonWebTokens ppt - explains JWT, JWS , JWE Tokens
nagarajapallafl
 
DDD Melbourne 2019 : Modern Authentication 101
Dasith Wijesiriwardena
 
JDD2015: Security in the era of modern applications and services - Bolesław D...
PROIDEA
 
Introduction to JWT and How to integrate with Spring Security
Bruno Henrique Rother
 
Secure JAX-RS
Rudy De Busscher
 
JSON Web Tokens Will Improve Your Life
John Anderson
 
[4developers2016] - Security in the era of modern applications and services (...
PROIDEA
 
Pentesting jwt
Jaya Kumar Kondapalli
 
IAM Overview Identiverse 2018
Brian Campbell
 
Landscape
Amit Gupta
 

More from Brian Campbell (12)

PPTX
The Burden of Proof
Brian Campbell
 
PPTX
Token Binding Identiverse 2018
Brian Campbell
 
PPTX
Beyond Bearer: Token Binding as the Foundation for a More Secure Web
Brian Campbell
 
PPTX
Identity and Access Management - RSA 2017 Security Foundations Seminar
Brian Campbell
 
PDF
OAuth 2.0 Token Exchange: An STS for the REST of Us
Brian Campbell
 
PPTX
Denver Startup Week '15: Mobile SSO
Brian Campbell
 
PPTX
Mobile SSO: are we there yet?
Brian Campbell
 
PPTX
Mobile Single Sign-On (Gluecon '15)
Brian Campbell
 
PPTX
OpenID Connect - a simple[sic] single sign-on & identity layer on top of OAut...
Brian Campbell
 
PPTX
Hope or Hype: A Look at the Next Generation of Identity Standards
Brian Campbell
 
PPTX
OAuth 101 & Secure APIs 2012 Cloud Identity Summit
Brian Campbell
 
PDF
OAuth 101 & Secure API's - Paul Madsen and Brian Campbell, Ping Identity
Brian Campbell
 
The Burden of Proof
Brian Campbell
 
Token Binding Identiverse 2018
Brian Campbell
 
Beyond Bearer: Token Binding as the Foundation for a More Secure Web
Brian Campbell
 
Identity and Access Management - RSA 2017 Security Foundations Seminar
Brian Campbell
 
OAuth 2.0 Token Exchange: An STS for the REST of Us
Brian Campbell
 
Denver Startup Week '15: Mobile SSO
Brian Campbell
 
Mobile SSO: are we there yet?
Brian Campbell
 
Mobile Single Sign-On (Gluecon '15)
Brian Campbell
 
OpenID Connect - a simple[sic] single sign-on & identity layer on top of OAut...
Brian Campbell
 
Hope or Hype: A Look at the Next Generation of Identity Standards
Brian Campbell
 
OAuth 101 & Secure APIs 2012 Cloud Identity Summit
Brian Campbell
 
OAuth 101 & Secure API's - Paul Madsen and Brian Campbell, Ping Identity
Brian Campbell
 

Recently uploaded (20)

PDF
The-Future-of-Automotive-Quality-is-Here-AI-Driven-Engineering.pdf
Kalilur Rahman
 
PDF
Dell Pro Micro: Speed customer interactions, patient processing, and learning...
Principled Technologies
 
PDF
A hybrid framework for wild animal classification using fine-tuned DenseNet12...
IAESIJAI
 
PDF
Transform-Your-Streaming-Platform-with-AI-Driven-Quality-Engineering.pdf
Kalilur Rahman
 
PDF
IT-ITes Industry bjjbnkmkhkhknbmhkhmjhjkhj
yatharthjutt100311
 
PDF
giants, standing on the shoulders of - by Daniel Stenberg
Daniel Stenberg
 
PDF
A symptom-driven medical diagnosis support model based on machine learning te...
IAESIJAI
 
PDF
Advancing precision in air quality forecasting through machine learning integ...
IAESIJAI
 
PPTX
MuleSoft-Compete-Deck for midddleware integrations
zupittejas
 
PPTX
Build automations faster and more reliably with UiPath ScreenPlay
AndreeaTom
 
PDF
Human Computer Interaction Miterm Lesson
JasperGarcia9
 
PPTX
Microsoft User Copilot Training Slide Deck
zohoron1
 
PDF
Accessing-Finance-in-Jordan-MENA 2024 2025.pdf
Mustafa Kuğu
 
PDF
AI.gov: A Trojan Horse in the Age of Artificial Intelligence
Michael Weaver
 
PDF
Transform-Quality-Engineering-with-AI-A-60-Day-Blueprint-for-Digital-Success.pdf
Kalilur Rahman
 
PDF
Data Virtualization in Action: Scaling APIs and Apps with FME
Safe Software
 
PDF
Co-training pseudo-labeling for text classification with support vector machi...
IAESIJAI
 
PDF
The-2025-Engineering-Revolution-AI-Quality-and-DevOps-Convergence.pdf
Kalilur Rahman
 
PPTX
SGT Report The Beast Plan and Cyberphysical Systems of Control
hopegirl587
 
PDF
zbrain.ai-Scope Key Metrics Configuration and Best Practices.pdf
ChristopherTHyatt
 
The-Future-of-Automotive-Quality-is-Here-AI-Driven-Engineering.pdf
Kalilur Rahman
 
Dell Pro Micro: Speed customer interactions, patient processing, and learning...
Principled Technologies
 
A hybrid framework for wild animal classification using fine-tuned DenseNet12...
IAESIJAI
 
Transform-Your-Streaming-Platform-with-AI-Driven-Quality-Engineering.pdf
Kalilur Rahman
 
IT-ITes Industry bjjbnkmkhkhknbmhkhmjhjkhj
yatharthjutt100311
 
giants, standing on the shoulders of - by Daniel Stenberg
Daniel Stenberg
 
A symptom-driven medical diagnosis support model based on machine learning te...
IAESIJAI
 
Advancing precision in air quality forecasting through machine learning integ...
IAESIJAI
 
MuleSoft-Compete-Deck for midddleware integrations
zupittejas
 
Build automations faster and more reliably with UiPath ScreenPlay
AndreeaTom
 
Human Computer Interaction Miterm Lesson
JasperGarcia9
 
Microsoft User Copilot Training Slide Deck
zohoron1
 
Accessing-Finance-in-Jordan-MENA 2024 2025.pdf
Mustafa Kuğu
 
AI.gov: A Trojan Horse in the Age of Artificial Intelligence
Michael Weaver
 
Transform-Quality-Engineering-with-AI-A-60-Day-Blueprint-for-Digital-Success.pdf
Kalilur Rahman
 
Data Virtualization in Action: Scaling APIs and Apps with FME
Safe Software
 
Co-training pseudo-labeling for text classification with support vector machi...
IAESIJAI
 
The-2025-Engineering-Revolution-AI-Quality-and-DevOps-Convergence.pdf
Kalilur Rahman
 
SGT Report The Beast Plan and Cyberphysical Systems of Control
hopegirl587
 
zbrain.ai-Scope Key Metrics Configuration and Best Practices.pdf
ChristopherTHyatt
 

Introduction to the Emerging JSON-Based Identity and Security Protocols

  • 1. 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
  • 2. • 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
  • 3. • 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. 4 “one of the leading visionaries and analysts in the computer industry” declared that… SAML is DEAD! Craig Burton
  • 5. 5 WTF “SAML is dead”? I‟ve got a mortgage to pay… Beer is still alive though… *Disclaimer: I work with these guys
  • 6. 6 The News Traveled Fast Beyond the Conference Walls SAML
  • 7. 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. 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
  • 10. 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
  • 11. • Javascript Object Signing and Encryption • IETF Working Group – JWS – JWE – JWK – JWA JOSE
  • 12. • 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
  • 13. • 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
  • 14. 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>
  • 15. • Simple [Relatively] • Compact • No canonicalization • Entirely Web Safe Alphabet Some Strengths of JWS
  • 16. • 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
  • 17. • 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
  • 18. • 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
  • 19. 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
  • 20. 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>
  • 21. • JSON Web Key • JSON representation of public keys with some metadata – RSA & Elliptic Curve – JWK & JWK Set JWK
  • 22. 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
  • 23. 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” }
  • 24. • 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
  • 25. • 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
  • 26. 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. 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.
  • 29. 29 Authorization Server Authorization Endpoint Token Endpoint Client Resource Owner Authorization Request with response_type=code OAuth 2.0 Resource Server Protected Resource(s)
  • 32. 32 Authorization Server 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. 33 Authorization Server 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. 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. 35 OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol.
  • 36. 36 OpenID Connect Basic Client Profile or Code Flow
  • 37. 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. 38 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 Authorization Request with response_type=code & scope=openid profile email address phone & maybe other new stuff, request[_uri], prompt, nonce, etc.
  • 39. 39 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 Authenticate and Approve
  • 40. 40 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 Authorization Response + code
  • 41. 41 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 Access Token Request with authorization_code grant type + code
  • 42. 42 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 Access Token Response with Access Token + ID Token (JWT)
  • 43. 43 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 Use Access Token to access User Info Endpoint
  • 44. 44 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 User Info Endpoint returns additional claims about (aboot) the authenticated End-User.
  • 45. 45 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 End-User is logged into the Client/RP
  • 46. 46 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 [Maybe] Use Access Token to access additional Protected Resources
  • 47. 47
  • 48. 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?