OAuth 2 und OpenID Connect @JAX2015

OAuth 2 und OpenID Connect Slides from JAX 2015

Transcript

1. OAuth 2 und OpenID Connect JAX 2015 23.04.2015, Mainz
 
 Simon Kölsch & Christoph Iserlohn
2. Agenda > OAuth 1, OAuth 2, OpenID Connect, O…? > How does it work? > Use Cases > Should I use it
3. “Web 2.0” Platforms and many more…
4. “Web 2.0” Platforms and many more… = User content on big platforms with APIs
5. “Web 2.0” Platforms and many more… = User content on big platforms with APIs 2010 - ~ 550.000 “Facebook Apps” 2015 - ~ 30 Flickr Apps tagged “geo” …
6. The access problem
7. The access problem Resource Owner
8. Resource/Auth Server The access problem Resource Owner
9. Resource/Auth Server The access problem Client Resource Owner
10. Resource/Auth Server The access problem Client Resource Owner needs Access
11. Resource/Auth Server The access problem Client Resource Owner needs Access gives Permission
12. Resource/Auth Server The access problem Client Resource Owner needs Access checks Permission
 provides Access gives Permission
13. OAuth 0
14. OAuth 0 > Client gets user password
15. OAuth 0 > Client gets user password > Client impersonates user and gets resource
16. OAuth 1 > Client registers at the service
17. OAuth 1 > Client registers at the service > Client asks resource owner for permission 
 via the service
18. OAuth 1 > Client registers at the service > Client asks resource owner for permission 
 via the service > Client gets a token
19. OAuth 1 > Client registers at the service > Client asks resource owner for permission 
 via the service > Client gets a token > Client can access the resource with the token
20. OAuth 1 > Authorization Protocol
21. OAuth 1 > Authorization Protocol > RFC 5849 (38 pages spec)
22. OAuth 1 > Authorization Protocol > RFC 5849 (38 pages spec) > One security issue (fixed 2009)
23. OAuth 1 > Authorization Protocol > RFC 5849 (38 pages spec) > One security issue (fixed 2009) > non-trivial request / response creation
24. OAuth 1 > Authorization Protocol > RFC 5849 (38 pages spec) > One security issue (fixed 2009) > non-trivial request / response creation > Scope: “web applications”
25. Why OAuth 2? > Simplify client development process
26. Why OAuth 2? > Simplify client development process > Desktop Applications / Single-Page-Apps
27. Why OAuth 2? > Simplify client development process > Desktop Applications / Single-Page-Apps > Mobile Phones
28. Why OAuth 2? > Simplify client development process > Desktop Applications / Single-Page-Apps > Mobile Phones > “Living room devices”
29. OAuth 2 Roles > Resource Owner > Client > Resource Server > Authentication Server
30. OAuth 2 Tokens > Access Token
 “An access token is a string representing 
 an authorization issued to the client.”
31. OAuth 2 Tokens > Access Token
 “An access token is a string representing 
 an authorization issued to the client.” > Token Type (e.g. “Bearer”)
32. OAuth 2 Tokens > Access Token
 “An access token is a string representing 
 an authorization issued to the client.” > Token Type (e.g. “Bearer”) > usually short-living
33. OAuth 2 Tokens > Access Token
 “An access token is a string representing 
 an authorization issued to the client.” > Token Type (e.g. “Bearer”) > usually short-living > Refresh Token
34. OAuth 2 Tokens > Access Token
 “An access token is a string representing 
 an authorization issued to the client.” > Token Type (e.g. “Bearer”) > usually short-living > Refresh Token > Scope
35. Authorization Code Grant User Agent Client Auth Server
36. Authorization Code Grant User Agent Client Auth Server redirect to grant screen add ‘state’ (and callback + client id )
37. Authorization Code Grant User Agent Client Auth Server redirect to grant screen add ‘state’ (and callback + client id ) show grant screen
38. Authorization Code Grant User Agent Client Auth Server redirect to grant screen add ‘state’ (and callback + client id ) show grant screen grant the request
39. Authorization Code Grant User Agent Client Auth Server redirect to grant screen add ‘state’ (and callback + client id ) show grant screen grant the request redirect with state and authorisation_code to client callback URI
40. Authorization Code Grant User Agent Client Auth Server redirect to grant screen add ‘state’ (and callback + client id ) show grant screen grant the request redirect with state and authorisation_code to client callback URI submit auth code, identify with client credentials
41. Authorization Code Grant User Agent Client Auth Server redirect to grant screen add ‘state’ (and callback + client id ) show grant screen grant the request redirect with state and authorisation_code to client callback URI submit auth code, identify with client credentials respond with token optional refresh token
42. OAuth 2 Grant Types > Authorization Code
43. OAuth 2 Grant Types > Authorization Code > Implicit
44. OAuth 2 Grant Types > Authorization Code > Implicit > User Credentials
45. OAuth 2 Grant Types > Authorization Code > Implicit > User Credentials > (Client Credentials)
46. OAuth 2 Spec Overview Framework
47. OAuth 2 Spec Overview Framework Security
48. OAuth 2 Spec Overview Framework Bearer Token Security
49. OAuth 2 Spec Overview Core Framework Bearer Token Security
50. OAuth 2 Spec Overview Core Framework Bearer Token Security JSON Web Token
51. OAuth 2 Spec Overview Core Framework Bearer Token Security JSON Web Token JWT Bearer Assertion
52. OAuth 2 Spec Overview Core Framework Bearer Token Security JSON Web Token Assertions JWT Bearer Assertion
53. OAuth 2 Spec Overview Core Framework Bearer Token Security JSON Web Token Assertions JWT Bearer Assertion SAML 2 Bearer Assertion
54. OAuth 2 Spec Overview Core Framework Bearer Token Security JSON Web Token Assertions JWT Bearer Assertion SAML 2 Bearer Assertion WG Drafts (PoP, Token Exchange, Introspection, …)
55. Short Comparison OAuth 1 OAuth 2
56. Short Comparison OAuth 1 OAuth 2 > Authorization protocol
57. Short Comparison OAuth 1 OAuth 2 > Authorization protocol > Delegation framework
58. Short Comparison OAuth 1 OAuth 2 > Authorization protocol > Spec finalized > Delegation framework
59. Short Comparison OAuth 1 OAuth 2 > Authorization protocol > Spec finalized > Delegation framework > Many extensions
60. Short Comparison OAuth 1 OAuth 2 > Authorization protocol > Spec finalized > Additional crypto to TLS > Delegation framework > Many extensions
61. Short Comparison OAuth 1 OAuth 2 > Authorization protocol > Spec finalized > Additional crypto to TLS > Delegation framework > Many extensions > TLS only (Core)
62. Short Comparison OAuth 1 OAuth 2 > Authorization protocol > Spec finalized > Additional crypto to TLS > Production ready libs > Delegation framework > Many extensions > TLS only (Core)
63. Short Comparison OAuth 1 OAuth 2 > Authorization protocol > Spec finalized > Additional crypto to TLS > Production ready libs > Delegation framework > Many extensions > TLS only (Core) > Incompatible implementations
64. Example: Traditional System Client Auth
65. Example: Traditional System Client Auth
66. Example: Traditional System Client Auth
67. Example: Microservices Client Auth
68. Example: Microservices Client Auth
69. Example: Microservices Client Auth
70. Example: Microservices Client Auth
71. Example: Microservices Client Auth
72. Example: Microservices Client Auth T
73. Example: Microservices Client Auth T T
74. Example: Microservices Client Auth T T T T T
75. OAuth 2 for Single-Sign-On?
76. OAuth 2 for Single-Sign-On? > Token = “Authorization to access Resource”
 Resource could be = Login to Service
77. OAuth 2 for Single-Sign-On? > Token = “Authorization to access Resource”
 Resource could be = Login to Service > Missing: When?
78. OAuth 2 for Single-Sign-On? > Token = “Authorization to access Resource”
 Resource could be = Login to Service > Missing: Who? When?
79. OAuth 2 for Single-Sign-On? > Token = “Authorization to access Resource”
 Resource could be = Login to Service > Missing: Who? Where? When?
80. OAuth 2 for Single-Sign-On? > Token = “Authorization to access Resource”
 Resource could be = Login to Service > Missing: Who? Where? When? How? … ?
81. Identities Entity
82. Identities Entity Identity 1 Identity 2 Identity 3
83. Identities Entity Identity 1 Identity 2 Identity 3 Service Service
84. OpenID Connect OpenID Connect
85. OpenID Connect OAuth 2 OpenID Connect
86. OpenID Connect OAuth 2 JOSE OpenID Connect
87. OpenID Connect OAuth 2 JOSE OpenID Connect Identity Layer
88. JWT Example { “typ”:”JWT”, “alg”:”HS256” }{ "iss": "http://server.example.com", "sub": "248289761001", "aud": "s6BhdRkqt3", "exp": 1311281970, "iat": 1311280970, "nonce": "n-0S6_WzA2Mj", "name": "Jane Doe", "given_name": "Jane", "family_name": "Doe", "gender": "female", "birthdate": "0000-10-31", "email": “janedoe@example.com”, "email_verified": {"essential": true} }
89. JWT Example { “typ”:”JWT”, “alg”:”HS256” }{ "iss": "http://server.example.com", "sub": "248289761001", "aud": "s6BhdRkqt3", "exp": 1311281970, "iat": 1311280970, "nonce": "n-0S6_WzA2Mj", "name": "Jane Doe", "given_name": "Jane", "family_name": "Doe", "gender": "female", "birthdate": "0000-10-31", "email": “janedoe@example.com”, "email_verified": {"essential": true} } JWT Header
90. JWT Example { “typ”:”JWT”, “alg”:”HS256” }{ "iss": "http://server.example.com", "sub": "248289761001", "aud": "s6BhdRkqt3", "exp": 1311281970, "iat": 1311280970, "nonce": "n-0S6_WzA2Mj", "name": "Jane Doe", "given_name": "Jane", "family_name": "Doe", "gender": "female", "birthdate": "0000-10-31", "email": “janedoe@example.com”, "email_verified": {"essential": true} } JWT Payload
91. Signature JWT Example { “typ”:”JWT”, “alg”:”HS256” }{ "iss": "http://server.example.com", "sub": "248289761001", "aud": "s6BhdRkqt3", "exp": 1311281970, "iat": 1311280970, "nonce": "n-0S6_WzA2Mj", "name": "Jane Doe", "given_name": "Jane", "family_name": "Doe", "gender": "female", "birthdate": "0000-10-31", "email": “janedoe@example.com”, "email_verified": {"essential": true} }
92. JWT Example Encoded eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9. eyJpc3MiOiJodHRwczovL2p3dC1pZHAuZXhhbXBsZS5j b20iLCJzdWIiOiJtYWlsdG86bWlrZUBleGFtcGxlLmNv bSIsIm5iZiI6MTQyOTY5MzY3MSwiZXhwIjoxNDI5Njk3 MjcxLCJpYXQiOjE0Mjk2OTM2NzEsImp0aSI6ImlkMTIz NDU2IiwidHlwIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9y ZWdpc3RlciJ9. A3DVPjcIeQPGOkMcABwAe_8lWHvPG9dFhNyskwVfsxIL t6SKtYGxYz0m7V- DjzjYLXqzSwycwlRJBuYr_vdLRA9aoGsGQpP5- SAiA5SdLMMk3MMZTIoSHgZrC8TeZx8bJBlPzkSu91dJI uzKI8PRPp3DH8Tum-XDsCmqu3_uIl2633Mb1Bg4HKEz- q2L2Y6k2Z1bqFxRn2GfV3ziQ8uqGOp3V_UlwvPccX8F3 m- qe3MrF5aPSFGoU9bZDcQcBQ2ypGTluBNYnPzuMx9EdET PJ0IxA1awgP74tFS27rt8KLUDnBvWVATNfYDFrqAcFCj zk49znd4JLvNObbDebka3_g
93. JWT Example Encoded eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9. eyJpc3MiOiJodHRwczovL2p3dC1pZHAuZXhhbXBsZS5j b20iLCJzdWIiOiJtYWlsdG86bWlrZUBleGFtcGxlLmNv bSIsIm5iZiI6MTQyOTY5MzY3MSwiZXhwIjoxNDI5Njk3 MjcxLCJpYXQiOjE0Mjk2OTM2NzEsImp0aSI6ImlkMTIz NDU2IiwidHlwIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9y ZWdpc3RlciJ9. A3DVPjcIeQPGOkMcABwAe_8lWHvPG9dFhNyskwVfsxIL t6SKtYGxYz0m7V- DjzjYLXqzSwycwlRJBuYr_vdLRA9aoGsGQpP5- SAiA5SdLMMk3MMZTIoSHgZrC8TeZx8bJBlPzkSu91dJI uzKI8PRPp3DH8Tum-XDsCmqu3_uIl2633Mb1Bg4HKEz- q2L2Y6k2Z1bqFxRn2GfV3ziQ8uqGOp3V_UlwvPccX8F3 m- qe3MrF5aPSFGoU9bZDcQcBQ2ypGTluBNYnPzuMx9EdET PJ0IxA1awgP74tFS27rt8KLUDnBvWVATNfYDFrqAcFCj zk49znd4JLvNObbDebka3_g Header
94. JWT Example Encoded eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9. eyJpc3MiOiJodHRwczovL2p3dC1pZHAuZXhhbXBsZS5j b20iLCJzdWIiOiJtYWlsdG86bWlrZUBleGFtcGxlLmNv bSIsIm5iZiI6MTQyOTY5MzY3MSwiZXhwIjoxNDI5Njk3 MjcxLCJpYXQiOjE0Mjk2OTM2NzEsImp0aSI6ImlkMTIz NDU2IiwidHlwIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9y ZWdpc3RlciJ9. A3DVPjcIeQPGOkMcABwAe_8lWHvPG9dFhNyskwVfsxIL t6SKtYGxYz0m7V- DjzjYLXqzSwycwlRJBuYr_vdLRA9aoGsGQpP5- SAiA5SdLMMk3MMZTIoSHgZrC8TeZx8bJBlPzkSu91dJI uzKI8PRPp3DH8Tum-XDsCmqu3_uIl2633Mb1Bg4HKEz- q2L2Y6k2Z1bqFxRn2GfV3ziQ8uqGOp3V_UlwvPccX8F3 m- qe3MrF5aPSFGoU9bZDcQcBQ2ypGTluBNYnPzuMx9EdET PJ0IxA1awgP74tFS27rt8KLUDnBvWVATNfYDFrqAcFCj zk49znd4JLvNObbDebka3_g Payload
95. JWT Example Encoded eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9. eyJpc3MiOiJodHRwczovL2p3dC1pZHAuZXhhbXBsZS5j b20iLCJzdWIiOiJtYWlsdG86bWlrZUBleGFtcGxlLmNv bSIsIm5iZiI6MTQyOTY5MzY3MSwiZXhwIjoxNDI5Njk3 MjcxLCJpYXQiOjE0Mjk2OTM2NzEsImp0aSI6ImlkMTIz NDU2IiwidHlwIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9y ZWdpc3RlciJ9. A3DVPjcIeQPGOkMcABwAe_8lWHvPG9dFhNyskwVfsxIL t6SKtYGxYz0m7V- DjzjYLXqzSwycwlRJBuYr_vdLRA9aoGsGQpP5- SAiA5SdLMMk3MMZTIoSHgZrC8TeZx8bJBlPzkSu91dJI uzKI8PRPp3DH8Tum-XDsCmqu3_uIl2633Mb1Bg4HKEz- q2L2Y6k2Z1bqFxRn2GfV3ziQ8uqGOp3V_UlwvPccX8F3 m- qe3MrF5aPSFGoU9bZDcQcBQ2ypGTluBNYnPzuMx9EdET PJ0IxA1awgP74tFS27rt8KLUDnBvWVATNfYDFrqAcFCj zk49znd4JLvNObbDebka3_g Signature
96. JWT Example Encoded eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9. eyJpc3MiOiJodHRwczovL2p3dC1pZHAuZXhhbXBsZS5j b20iLCJzdWIiOiJtYWlsdG86bWlrZUBleGFtcGxlLmNv bSIsIm5iZiI6MTQyOTY5MzY3MSwiZXhwIjoxNDI5Njk3 MjcxLCJpYXQiOjE0Mjk2OTM2NzEsImp0aSI6ImlkMTIz NDU2IiwidHlwIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9y ZWdpc3RlciJ9. A3DVPjcIeQPGOkMcABwAe_8lWHvPG9dFhNyskwVfsxIL t6SKtYGxYz0m7V- DjzjYLXqzSwycwlRJBuYr_vdLRA9aoGsGQpP5- SAiA5SdLMMk3MMZTIoSHgZrC8TeZx8bJBlPzkSu91dJI uzKI8PRPp3DH8Tum-XDsCmqu3_uIl2633Mb1Bg4HKEz- q2L2Y6k2Z1bqFxRn2GfV3ziQ8uqGOp3V_UlwvPccX8F3 m- qe3MrF5aPSFGoU9bZDcQcBQ2ypGTluBNYnPzuMx9EdET PJ0IxA1awgP74tFS27rt8KLUDnBvWVATNfYDFrqAcFCj zk49znd4JLvNObbDebka3_g
97. ID Token Example { “typ”:”JWT”, “alg”:”HS256” }{ "iss": "http://server.example.com", "sub": "248289761001", "aud": "s6BhdRkqt3", "exp": 1311281970, "iat": 1311280970, "nonce": "n-0S6_WzA2Mj", "name": "Jane Doe", "given_name": "Jane", "family_name": "Doe", "gender": "female", "birthdate": "0000-10-31", "email": “janedoe@example.com”, "email_verified": {"essential": true} }
98. ID Token Example { “typ”:”JWT”, “alg”:”HS256” }{ "iss": "http://server.example.com", "sub": "248289761001", "aud": "s6BhdRkqt3", "exp": 1311281970, "iat": 1311280970, "nonce": "n-0S6_WzA2Mj", "name": "Jane Doe", "given_name": "Jane", "family_name": "Doe", "gender": "female", "birthdate": "0000-10-31", "email": “janedoe@example.com”, "email_verified": {"essential": true} } Claim
99. ID Token Example { “typ”:”JWT”, “alg”:”HS256” }{ "iss": "http://server.example.com", "sub": "248289761001", "aud": "s6BhdRkqt3", "exp": 1311281970, "iat": 1311280970, "nonce": "n-0S6_WzA2Mj", "name": "Jane Doe", "given_name": "Jane", "family_name": "Doe", "gender": "female", "birthdate": "0000-10-31", "email": “janedoe@example.com”, "email_verified": {"essential": true} } mandatory
 Claims
100. ID Token Example { “typ”:”JWT”, “alg”:”HS256” }{ "iss": "http://server.example.com", "sub": "248289761001", "aud": "s6BhdRkqt3", "exp": 1311281970, "iat": 1311280970, "nonce": "n-0S6_WzA2Mj", "name": "Jane Doe", "given_name": "Jane", "family_name": "Doe", "gender": "female", "birthdate": "0000-10-31", "email": “janedoe@example.com”, "email_verified": {"essential": true} } scope E-Mail
101. ID Token Example { “typ”:”JWT”, “alg”:”HS256” }{ "iss": "http://server.example.com", "sub": "248289761001", "aud": "s6BhdRkqt3", "exp": 1311281970, "iat": 1311280970, "nonce": "n-0S6_WzA2Mj", "name": "Jane Doe", "given_name": "Jane", "family_name": "Doe", "gender": "female", "birthdate": "0000-10-31", "email": “janedoe@example.com”, "email_verified": {"essential": true} }
102. OpenID Connect Modules Core
103. OpenID Connect Modules Core Discovery Dynamic Client Registration
104. OpenID Connect Modules Core Discovery Dynamic Client Registration Session Management Form Post Response Mode
105. Enterprise Use Cases
106. Enterprise Use Cases > Securing internal APIs
107. Enterprise Use Cases > Securing internal APIs > Single-Sign-On
108. Enterprise Use Cases > Securing internal APIs > Single-Sign-On > Active Directory
109. Enterprise Use Cases > Securing internal APIs > Single-Sign-On > Active Directory > Mobile Clients
110. Enterprise Use Cases > Securing internal APIs > Single-Sign-On > Active Directory > Mobile Clients > White Label Software
111. Should I use it? > OpenID Connect Extensions 
 still partly Working Drafts
112. Should I use it? > OpenID Connect Extensions 
 still partly Working Drafts > JOSE still Working Draft
113. Should I use it? > OpenID Connect Extensions 
 still partly Working Drafts > JOSE still Working Draft > OAuth Extensions: PoP, etc.
114. Should I use it? > OpenID Connect Extensions 
 still partly Working Drafts > JOSE still Working Draft > OAuth Extensions: PoP, etc. > Implementation Complexity
115. Simon Kölsch | @simkoelsch simon.koelsch@innoq.com innoQ Deutschland GmbH Krischerstr. 100 40789 Monheim am Rhein Germany Phone: +49 2173 3366-0 innoQ Schweiz GmbH Gewerbestr. 11 CH-6330 Cham Switzerland Phone: +41 41 743 0116 www.innoq.com Ohlauer Straße 43 10999 Berlin Germany Phone: +49 2173 3366-0 Robert-Bosch-Straße 7 64293 Darmstadt Germany Phone: +49 2173 3366-0 Radlkoferstraße 2 D-81373 München Germany Telefon +49 (0) 89 741185-270 Thank you! Questions?
     Comments? Christoph Iserlohn christoph.iserlohn@innoq.com