Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

2019 | OAuth 2.0 Masterclass - Intro to OAuth 2.0 Part 1 | Identiverse | Day 1, June 25

134 views

Published on

(Part 1) An in-depth overview of the OAuth 2 protocol from one of the world's foremost experts. Learn about how the protocol works, why it was built the way that it is, and what it can do. Just as important, learn what its limitations are and what it can't do, along with the ecosystem of technologies that have grown up around it.

Published in: Technology
  • Be the first to comment

2019 | OAuth 2.0 Masterclass - Intro to OAuth 2.0 Part 1 | Identiverse | Day 1, June 25

  1. 1. @justin__richerhttps://bspk.io/ Introduction to OAuth 2.0 Justin Richer Bespoke Engineering 1
  2. 2. @justin__richerhttps://bspk.io/ COURSE VERSION 1.11 Feedback is welcome! 2
  3. 3. @justin__richerhttps://bspk.io/ Try the home edition • OAuth 2 In Action • Code is open source • Published March 2017 • Now available in Korean and Japanese 3
  4. 4. @justin__richerhttps://bspk.io/ WHAT IS OAUTH 2.0? 4
  5. 5. @justin__richerhttps://bspk.io/ From the spec (RFC6749) The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. 5
  6. 6. @justin__richerhttps://bspk.io/ The good bits The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. 6
  7. 7. @justin__richerhttps://bspk.io/ In other words OAuth 2.0 is a delegation protocol that lets people allow applications to access things on their behalf. 7
  8. 8. @justin__richerhttps://bspk.io/ Who is involved? 8
  9. 9. @justin__richerhttps://bspk.io/ The resource owner • Has access to some resource or API • Can delegate access to that resource or API • Usually has access to a web browser • Usually is a person 9
  10. 10. @justin__richerhttps://bspk.io/ The protected resource • Web service (API) with security controls • Protects things for the resource owner • Shares things on the resource owner’s request 10
  11. 11. @justin__richerhttps://bspk.io/ The client application • Wants to access the protected resource • Does things on the resource owner’s behalf • Could be a web server – But it’s still a “client” in OAuth parlance – Could also be a native app or JS app 11
  12. 12. @justin__richerhttps://bspk.io/ What are we trying to solve? 12
  13. 13. @justin__richerhttps://bspk.io/ THIS ISN’T A NEW PROBLEM People have been solving this for a long time 13
  14. 14. @justin__richerhttps://bspk.io/ Steal the keys 14
  15. 15. @justin__richerhttps://bspk.io/ Ask for the keys 15
  16. 16. @justin__richerhttps://bspk.io/ Use a universal key 16
  17. 17. @justin__richerhttps://bspk.io/ Service-specific credentials 17
  18. 18. @justin__richerhttps://bspk.io/ WE’RE GETTING CLOSER… 18
  19. 19. @justin__richerhttps://bspk.io/ Introducing the Authorization Server (AS) 19
  20. 20. @justin__richerhttps://bspk.io/ The Authorization Server • Generates tokens for the client • Authenticates resource owners (users) • Authenticates clients • Manages authorizations 20
  21. 21. @justin__richerhttps://bspk.io/ OAuth Tokens • Represent granted delegated authorities – From the resource owner to the client for the protected resource • Issued by authorization server • Used by client – Format is opaque to clients • Consumed by protected resource 21
  22. 22. @justin__richerhttps://bspk.io/ Example OAuth Tokens • 92d42038006dba95d0c501951ac5b5eb • 2df029c6-b38d-4083-b8d9-db67c774d13f • eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiO iIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiw iYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RM HrHDcEfxjoYZgeFONFh7HgQ • waterbuffalo-elephant-helicopter-argument 22
  23. 23. @justin__richerhttps://bspk.io/ HAVE YOU USED OAUTH 2? 23
  24. 24. @justin__richerhttps://bspk.io/ You’ve used OAuth 24
  25. 25. @justin__richerhttps://bspk.io/ A BRIEF HISTORY OF OAUTH 2.0 25
  26. 26. @justin__richerhttps://bspk.io/ Circa 2006 • HTTP password authentication common for API access – “Give me your password” • Internet companies have proprietary solutions for delegated access – BBAuth, AuthSub, a few others 26
  27. 27. @justin__richerhttps://bspk.io/ The problem • Two smaller sites want to connect their APIs for their users • Both use OpenID for login – No username/password to pass! • Neither wants to use a proprietary solution 27
  28. 28. @justin__richerhttps://bspk.io/ A new standard is born • OAuth 1.0 is published independently – No formal standards body, people just use it • A session fixation attack is found and fixed – New version is called OAuth 1.0a • This community document is standardized as RFC5849 in the IETF 28
  29. 29. @justin__richerhttps://bspk.io/ People start using it • OAuth 1.0a solves major pain points for many people in a standard and understandable way • Google, Yahoo, and others replace their solutions with the new standard 29
  30. 30. @justin__richerhttps://bspk.io/ People start abusing it • People also decide to start using OAuth for off-label use cases – Native applications – No user in the loop – Distributed authorization systems 30
  31. 31. @justin__richerhttps://bspk.io/ Version 2.0: The framework • Modularized concepts • Separated previously conflated components • Added explicit extensibility points • Removed pain points of implementers • Standardized in RFC6749 and RFC6750 31
  32. 32. @justin__richerhttps://bspk.io/ What does this mean? • Instead of a single protocol, OAuth 2.0 defines common concepts and components and different ways to mix them together • It’s not a single standard, it’s a set of standards for different use cases 32
  33. 33. @justin__richerhttps://bspk.io/ OAuth 2 Today: The Ecosystem • Extensions – PKCE, DynReg, Discovery • Siblings – JOSE, JWT, COSE • Applications – OIDC, UMA • Profiles – HEART, FAPI, iGov 33
  34. 34. @justin__richerhttps://bspk.io/ WHAT OAUTH ISN’T 34
  35. 35. @justin__richerhttps://bspk.io/ Not defined outside of HTTP • Core protocol defined only for HTTP • Relies on TLS for securing messages • There are efforts to use OAuth over non-HTTP protocols – GSSAPI – CoAP 35
  36. 36. @justin__richerhttps://bspk.io/ No user-to-user delegation • Allows a user to delegate to a piece of software but not to another user • However, multi-party delegation can be built using OAuth as a core component (UMA) 36
  37. 37. @justin__richerhttps://bspk.io/ No authorization processing • Tokens can represent scopes and other authorization information • Processing of this information is up to the resource server • However, several methods (UMA, JWT, introspection) to communicate this information 37
  38. 38. @justin__richerhttps://bspk.io/ No token format • Token is opaque to the client • Token needs to be issued by the authorization server and understood by the resource server, but they’re free to use whatever format they want • However, JSON Web Tokens (JWT) provide a useful common format 38
  39. 39. @justin__richerhttps://bspk.io/ No cryptographic methods • Core OAuth relies on TLS for protecting information in transit • However, other mechanisms like JSON Object Signing and Encryption (JOSE) define things that can be used with OAuth 39
  40. 40. @justin__richerhttps://bspk.io/ Not a single protocol • OAuth 2.0 is a framework – Several core flows plus extensions • Two things can “implement OAuth” but be incompatible with each other • However, code re-use and patterns between common components makes life simpler 40
  41. 41. @justin__richerhttps://bspk.io/ Not an authentication protocol • Relies on authentication in several places – Client authentication to token endpoint – Resource owner authentication at authorization endpoint • Doesn’t communicate anything about the user • However: authentication protocols can be built using OAuth (OpenID Connect) 41
  42. 42. @justin__richerhttps://bspk.io/ THIS IS NOT IDENTITY! 42
  43. 43. @justin__richerhttps://bspk.io/ THE AUTHORIZATION CODE FLOW A deep dive into the canonical OAuth 2.0 transaction 43
  44. 44. @justin__richerhttps://bspk.io/ The pieces of OAuth 44
  45. 45. @justin__richerhttps://bspk.io/ The authorization code flow 45
  46. 46. @justin__richerhttps://bspk.io/ TWO FORMS OF COMMUNICATION 46
  47. 47. @justin__richerhttps://bspk.io/ The back channel 47
  48. 48. @justin__richerhttps://bspk.io/ The front channel 48
  49. 49. @justin__richerhttps://bspk.io/ A front channel request/response 49
  50. 50. @justin__richerhttps://bspk.io/ Why both? • Separation of information • Front channel when the user’s involved • Back channel when they’re not 50
  51. 51. @justin__richerhttps://bspk.io/ THE AUTHORIZATION CODE FLOW Step by step 51
  52. 52. @justin__richerhttps://bspk.io/ Authorization Code: Step 1 52
  53. 53. @justin__richerhttps://bspk.io/ Authorization Code: Step 2 53
  54. 54. @justin__richerhttps://bspk.io/ Authorization Code: Step 3 54
  55. 55. @justin__richerhttps://bspk.io/ Authorization Code: Step 4 55
  56. 56. @justin__richerhttps://bspk.io/ Authorization Code: Step 5 56
  57. 57. @justin__richerhttps://bspk.io/ Authorization Code: Step 6 57
  58. 58. @justin__richerhttps://bspk.io/ Authorization Code: Step 7 58
  59. 59. @justin__richerhttps://bspk.io/ REFRESH TOKENS 59
  60. 60. @justin__richerhttps://bspk.io/ When the user isn’t there • Access tokens work after the user leaves – One of the original design goals of OAuth • What does a client do when the access token stops working? – Expiration – Revocation 60
  61. 61. @justin__richerhttps://bspk.io/ Getting a new token • Repeat the process of getting a token – Interactive grants: send the resource owner to the authorization endpoint • But what if the user’s not there anymore? 61
  62. 62. @justin__richerhttps://bspk.io/ Refresh tokens • Issued alongside the access token • Used for getting new access tokens – Presented along with client credentials – Not good for calling protected resources directly 62
  63. 63. @justin__richerhttps://bspk.io/ SCOPES 63
  64. 64. @justin__richerhttps://bspk.io/ API Design • Naïve APIs allow simple yes/no access – If your token is good, your request is good • Smarter APIs divide access 64
  65. 65. @justin__richerhttps://bspk.io/ Limited access • Type of action – Read, write, delete • Type of resource – Photos, metadata, profile • Time of access – User is offline, limited number of accesses 65
  66. 66. @justin__richerhttps://bspk.io/ OAuth Scopes • Strings that represent what the token can do • Client can ask for scopes • Resource owner approves scopes • Access token is bound to scopes 66
  67. 67. @justin__richerhttps://bspk.io/ OTHER WAYS TO DO OAUTH 2.0 67
  68. 68. @justin__richerhttps://bspk.io/ Protocol flexibility • Canonical use case: web server based application accessed through a browser • Authorization code flow is built around this use case • What about different kinds of clients? • What about different kinds of delegation? 68
  69. 69. @justin__richerhttps://bspk.io/ The implicit flow 69
  70. 70. @justin__richerhttps://bspk.io/ The client credentials flow 70
  71. 71. @justin__richerhttps://bspk.io/ The resource owner password flow 71
  72. 72. @justin__richerhttps://bspk.io/ HOLD ON! Didn’t we say it was bad to steal the credentials? 72
  73. 73. @justin__richerhttps://bspk.io/ The assertions flows 73
  74. 74. @justin__richerhttps://bspk.io/ The device flow 74
  75. 75. @justin__richerhttps://bspk.io/ NATIVE CLIENTS 75
  76. 76. @justin__richerhttps://bspk.io/ What’s a native client? • Runs on the end user’s system – Not hosted on a remote web server – Not executed inside of a web browser • Can be desktop or mobile – Local self-contained web server apps qualify 76
  77. 77. @justin__richerhttps://bspk.io/ What makes a native client different? • Functionality lives outside the browser • Can’t keep secrets from the user – Especially configure-time secrets • Requires adaptations to redirect URI to use the front channel 77
  78. 78. @justin__richerhttps://bspk.io/ Dealing with secrets • Application is copied and run many times – Shouldn’t give each copy the same secret • Dynamic client registration – Give each instance its own ID and secret • Public clients – Share an ID and don’t use secrets 78
  79. 79. @justin__richerhttps://bspk.io/ Redirect URIs • Custom URI scheme – myapp:/oauth_callback?code=ABC123 • Locally hosted web server – http://localhost:39103/myapp?code=ABC123 • Remote host with push notification – https://push.example.com/app-942/code=ABC123 79
  80. 80. @justin__richerhttps://bspk.io/ Redirect URIs with custom schemes • Apps need to register for namespace • Any app can take any namespace • Malicious apps can try to grab items coming in on redirect URIs – Authorization codes (for code flow) – Tokens (for implicit flow) 80
  81. 81. @justin__richerhttps://bspk.io/ PKCE: Sending the challenge 81
  82. 82. @justin__richerhttps://bspk.io/ PKCE: Sending the verifier 82
  83. 83. @justin__richerhttps://bspk.io/ PKCE: Verifying the challenge 83
  84. 84. @justin__richerhttps://bspk.io/ MANAGING THE GRANT TYPES 84
  85. 85. @justin__richerhttps://bspk.io/ Different use cases • Authorization code flow: web applications, some native applications • Implicit flow: in-browser applications • Client credentials flow: non-interactive • Password flow: trusted legacy clients • Assertion flows: trust frameworks 85
  86. 86. @justin__richerhttps://bspk.io/ HOW TO CHOOSE A GRANT TYPE 86
  87. 87. @justin__richerhttps://bspk.io/ 87
  88. 88. @justin__richerhttps://bspk.io/ REGISTRATION AND DISCOVERY 88
  89. 89. @justin__richerhttps://bspk.io/ Dynamic Client Registration 89
  90. 90. @justin__richerhttps://bspk.io/ Software statements • Third party generates an assertion that contains fixed attributes of the client – Client can’t change or override what’s in the statement • Client presents the statement alongside any variable attributes • Server generates unique ID and secret for client 90
  91. 91. @justin__richerhttps://bspk.io/ Why use a software statement? • Many instances of a client software – Each instance needs its own ID/secret – All instances should be “recognizable” • Allow pre-registration across domains – Software statement from trusted server – Individual AS registrations for clients 91
  92. 92. @justin__richerhttps://bspk.io/ Server discovery • Find the issuer URL • We still need to know all the server information – Endpoint locations – Key location – Authentication methods – Etc… 92
  93. 93. @justin__richerhttps://bspk.io/ Discovery example https://idp.domain.com 93
  94. 94. @justin__richerhttps://bspk.io/ Discovery example https://idp.domain.com /.well-known/openid-configuration 94
  95. 95. @justin__richerhttps://bspk.io/ Discovery response { "issuer”: "https://idp.domain.com", "authorization_endpoint”: "https://idp.domain.com/connect/authorize", "token_endpoint”: "https://idp.domain.com/connect/token", "token_endpoint_auth_methods_supported”: ["client_secret_basic", "private_key_jwt"], "token_endpoint_auth_signing_alg_values_supported”: ["RS256", "ES256"], "userinfo_endpoint”: "https://idp.domain.com/connect/userinfo", "jwks_uri”: "https://idp.domain.com/jwks.json", "registration_endpoint”: "https://idp.domain.com/connect/register", "scopes_supported”: ["openid", "profile", "email", "address”, "phone", "offline_access"], "response_types_supported”: ["code", "code id_token", "id_token", "token id_token"], "subject_types_supported”: ["public", "pairwise"], "userinfo_signing_alg_values_supported”: ["RS256", "ES256", "HS256"], "id_token_signing_alg_values_supported”: ["RS256", "ES256", "HS256"], "id_token_encryption_alg_values_supported”: ["RSA1_5", "A128KW"], "id_token_encryption_enc_values_supported”: ["A128CBC-HS256", "A128GCM"], "request_object_signing_alg_values_supported”: ["none", "RS256", "ES256"], "service_documentation”: "http://idp.domain.com/connect/service_documentation.html” } 95
  96. 96. @justin__richerhttps://bspk.io/ TOKEN INTROSPECTION 96
  97. 97. @justin__richerhttps://bspk.io/ OAuth tokens are opaque • But they’re only opaque to the client • Protected resource needs to know the token – What’s it good for? – Who issued it? – Is it valid? 97
  98. 98. @justin__richerhttps://bspk.io/ How does the resource know? • Database lookup – AS and RS are in the same box • Pack information into the token itself – Remember JWT? • Query the AS – Runtime lookup over the network 98
  99. 99. @justin__richerhttps://bspk.io/ “What’s this token good for?” • Protected resource queries the AS about a token it received • AS responds with a JSON structure describing the token’s status 99
  100. 100. @justin__richerhttps://bspk.io/ Introspection trade-offs • Requires extra credentials (at the RS) • More network traffic • Subject to cache consistency problems – Introspect every time? Only on timeout? 100
  101. 101. @justin__richerhttps://bspk.io/ TOKEN REVOCATION 101
  102. 102. @justin__richerhttps://bspk.io/ Completing the token lifecycle • OAuth defines how to get a new token and refresh a dead token • Revocation allows clients to proactively throw away tokens they no longer use 102
  103. 103. @justin__richerhttps://bspk.io/ Why revoke tokens? • Native application being uninstalled • User selects “log out” or “de-authorize” from the client (not the AS) 103
  104. 104. @justin__richerhttps://bspk.io/ A simple protocol • Client POSTs to the revocation endpoint – Token included in body • Server deletes the token if it finds it • Server tells the client everything is OK – Even if no token was deleted, we pretend we did – Otherwise clients could use this to fish for token values • Client throws out its copy of the token 104
  105. 105. @justin__richerhttps://bspk.io/ POP, MTLS, AND TOKEN BINDING 105
  106. 106. @justin__richerhttps://bspk.io/ Beyond bearer tokens • Bearer tokens are sent as-is over the wire • Anyone who has access to the token can use it • Proof of Possession (PoP) tokens require cryptographic proof of a key – Token is transmitted as-is – Key is used to sign something, not transmitted itself 106
  107. 107. @justin__richerhttps://bspk.io/ Two parts Token: Opaque to client Associated with scopes and RO Sent as-is to PR Key: Known to client Associated with token Used to sign request 107
  108. 108. @justin__richerhttps://bspk.io/ Mutual TLS • Client presents certificate to token endpoint • AS hashes certificate and ties it to token • Client presents same certificate to RS • RS hashes certificate and sees if it’s the same as the one bound to the token • Client does not have to authenticate with TLS 108
  109. 109. @justin__richerhttps://bspk.io/ Token binding 109
  110. 110. @justin__richerhttps://bspk.io/ A problem with token binding 110
  111. 111. @justin__richerhttps://bspk.io/ JSON WEB TOKENS Also some JOSE while we’re here 111 ©2016 Bespoke Engineering LLC
  112. 112. @justin__richerhttps://bspk.io/ OAuth tokens • No specified token format – “Opaque to the client” • However: tokens must be understood by the AS and PR 112 ©2016 Bespoke Engineering LLC
  113. 113. @justin__richerhttps://bspk.io/ JOSE: Protect a JSON Payload • JavaScript Object Signing and Encryption • No normalization or canonical form – Cryptographic operations based on exactly what’s sent across the wire 113 ©2016 Bespoke Engineering LLC
  114. 114. @justin__richerhttps://bspk.io/ JWT: a common format • Standardized set of claims useful to many applications – “iss”: who issued the token – “aud”: who the token is targeted at – “exp”: when the token expires • Contained in an extensible JSON object • Protected by JOSE 114 ©2016 Bespoke Engineering LLC
  115. 115. @justin__richerhttps://bspk.io/ Signatures: JWS • Three part data structure • Can contain arbitrary payloads and be embedded into other structures • Symmetric or asymmetric signatures 115 ©2016 Bespoke Engineering LLC
  116. 116. @justin__richerhttps://bspk.io/ Signed JWT 116 ©2016 Bespoke Engineering LLC eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2Ui LA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGx lLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVP- mB92K27uhbUJU1p1r_wW1gFWFOEjXk {"typ":"JWT", "alg":"HS256"} {"iss":"joe", "exp":1300819380, "http://example.com/is_root":true} + + =(signature)
  117. 117. @justin__richerhttps://bspk.io/ Parsing a signed JWT • Split on “.” (period) • Base64URL Decode each section • Parse first section as JSON object, this is the header • Parse second section as JSON object, this is the payload • Keep third section as byte array, this is the signature 117 ©2016 Bespoke Engineering LLC
  118. 118. @justin__richerhttps://bspk.io/ Validating the signature • Take raw input strings from first and second sections, separated by period, and run them through the signer/verifier with the right key • Don’t try to re-encode the JSON object! – Serialization is not guaranteed 118 ©2016 Bespoke Engineering LLC
  119. 119. @justin__richerhttps://bspk.io/ Generating a signed JWT • Serialize the header JSON object as a string • Serialize the payload JSON object as a string • Base64URL encode the header (no padding) • Base64URL encode the payload (no padding) • Concatenate with a “.” (period) • Run the concatenated string through a signer with the right key • Base64URL encode the signature • Concatenate to the header and payload with a “.” (period) 119 ©2016 Bespoke Engineering LLC
  120. 120. @justin__richerhttps://bspk.io/ Why are JWTs useful? • Carry information inside the token – No need for lookup services • Easily parsed and understood • Simple tools to get to “human readable” content • Safe from re-encoding on the wire 120 ©2016 Bespoke Engineering LLC
  121. 121. @justin__richerhttps://bspk.io/ Some downsides with JWT • Encoding leads to large size – Though still smaller than signed XML • Not directly human-readable • Cache consistency problems when used to carry all token information 121 ©2016 Bespoke Engineering LLC
  122. 122. @justin__richerhttps://bspk.io/ Tool: https://jwt.io/ 122 ©2016 Bespoke Engineering LLC
  123. 123. @justin__richerhttps://bspk.io/ Encryption: JWE • Five-part data structure • Can contain arbitrary payloads and be embedded • Left as an exercise to the reader 123 ©2016 Bespoke Engineering LLC
  124. 124. @justin__richerhttps://bspk.io/ Keys: JWK • Not certificates! • Bare keys – Good replacement for self-signed certs • No signing authority • Usually hosted at HTTPS URIs – Can be rotated easily 124 ©2016 Bespoke Engineering LLC
  125. 125. @justin__richerhttps://bspk.io/ Example RSA JWK { "d": "Sk1qzXfCdP7KafrtRpVT6on_OluizvWNvgYv9pH8Yf0s7p5kdW62ebDKnq9gyRwlX0mLBUI_RWfKmDw1_TCXwp1c- o1xTo9N9DEO5IvUEL81aUR4y4HOk24RbS- 6z2uA5f_BysBomZl7lWVk1zyvHZ8u0jRR8TwW75idf7G_IdVzeXMQLlUx9dIn6kSLsXCJTo3P6c1UjCKd6vgaxyWQNPmWggvZ ze_tBu1aWNewOtSg_1b0hnW7kuPsG-KMiJIuiEQKS1E6E06cszyZH_EskmZ0GIX_uDYXSsuEMK3V9rdPzq6RjnQVmL- O8hY02c2fB69dkeoY_euceHitpJ1JZQ", "e": "AQAB", "n": "5gK_BCFTHhaCGF6ZUh_IqlO45zvhtGGEuppkApZKgrvGogyKVJwhhiC5iJRKQDhINObKuF7CaUMAeM8XLFMC1QCWbHI- XuGedbETknqxZZODKvYlUNF1dvT4aMd4RNsQEHP760bW2dnHhElN_TBcN6araLHBHbwRsuuKnU7We6rZ3- F0qKFklfxMgVNr0roV0EEf3TepA_XyuYfiU0nOB4ShD1WaAw3TD8f513rSwgijyQqubw7_1fVv13B3ahRxTDzVedX4Kn_GbXV SY1CHix6OJJdVOSOclbnVNuw5fkPMHoPYbqyuf2BT3W2QdgXgFxMrPrFdfrz0vv7jxnRVxQ", "kty": "RSA", "kid": "demokey" } 125 ©2016 Bespoke Engineering LLC
  126. 126. @justin__richerhttps://bspk.io/ Example Public RSA JWK { "e": "AQAB", "n": "5gK_BCFTHhaCGF6ZUh_IqlO45zvhtGGEuppkApZKgrvGogyKVJwhhiC5iJRKQDhINObKu F7CaUMAeM8XLFMC1QCWbHI- XuGedbETknqxZZODKvYlUNF1dvT4aMd4RNsQEHP760bW2dnHhElN_TBcN6araLHBHb wRsuuKnU7We6rZ3- F0qKFklfxMgVNr0roV0EEf3TepA_XyuYfiU0nOB4ShD1WaAw3TD8f513rSwgijyQqubw7_ 1fVv13B3ahRxTDzVedX4Kn_GbXVSY1CHix6OJJdVOSOclbnVNuw5fkPMHoPYbqyuf2BT3 W2QdgXgFxMrPrFdfrz0vv7jxnRVxQ", "kty": "RSA", "kid": "demokey" } 126 ©2016 Bespoke Engineering LLC
  127. 127. @justin__richerhttps://bspk.io/ Tool: https://mkjwk.org/ 127 ©2016 Bespoke Engineering LLC
  128. 128. @justin__richerhttps://bspk.io/ USER AUTHENTICATION 128 ©2016 Bespoke Engineering LLC
  129. 129. @justin__richerhttps://bspk.io/ What is authentication? • Indicates who the current user is • Confirms the user’s presence • Carries attributes about the user • Carries information about the user’s original authentication event 129 ©2016 Bespoke Engineering LLC
  130. 130. @justin__richerhttps://bspk.io/ OAuth isn’t authentication • Client has no idea who the user is – But the AS does • No way to carry information about the user – But can be attached to an API • The access token doesn’t mean the user is there – It’s usually used when the user isn’t 130 ©2016 Bespoke Engineering LLC
  131. 131. @justin__richerhttps://bspk.io/ CAN WE BUILD AUTHENTICATION ON OAUTH? 131 ©2016 Bespoke Engineering LLC
  132. 132. @justin__richerhttps://bspk.io/ First attempt: Log in to the resource • Application is the protected resource – After all, we’re “protecting” it by requiring login, right? • What does that look like? 132 ©2016 Bespoke Engineering LLC
  133. 133. @justin__richerhttps://bspk.io/ How can we split the network? 133 ©2016 Bespoke Engineering LLC
  134. 134. @justin__richerhttps://bspk.io/ No good! • Trust domain boundaries get crossed • User doesn’t usually interact directly with the resource • Is there a better mapping? 134 ©2016 Bespoke Engineering LLC
  135. 135. @justin__richerhttps://bspk.io/ Second attempt: Log in to the client • Application is the client • Authorization server and protected resource together are the identity provider • What does this look like? 135 ©2016 Bespoke Engineering LLC
  136. 136. @justin__richerhttps://bspk.io/ A better way to split the network 136 ©2016 Bespoke Engineering LLC
  137. 137. @justin__richerhttps://bspk.io/ That works! • We’re using OAuth to protect the identity • The client consumes the identity 137 ©2016 Bespoke Engineering LLC
  138. 138. @justin__richerhttps://bspk.io/ Building authentication • Use OAuth to protect an identity API • Carry information about the authentication event next to the access token 138 ©2016 Bespoke Engineering LLC
  139. 139. @justin__richerhttps://bspk.io/ DOESN’T THAT MAKE OAUTH AUTHENTICATION? 139 ©2016 Bespoke Engineering LLC
  140. 140. @justin__richerhttps://bspk.io/ CHOCOLATE AND FUDGE A delicious metaphor 140 ©2016 Bespoke Engineering LLC
  141. 141. @justin__richerhttps://bspk.io/ Authorization is Chocolate • Good on its own • Great as part of a larger recipe • Many different recipes can use it 141 ©2016 Bespoke Engineering LLC
  142. 142. @justin__richerhttps://bspk.io/ Authentication is Fudge • Confection with several ingredients • Tends to have one flavor as the most obvious • Could be made using chocolate – But not required 142 ©2016 Bespoke Engineering LLC
  143. 143. @justin__richerhttps://bspk.io/ Agreeing on a recipe • Let’s make a recipe for chocolate fudge: – Standard authentication protocol – Built on top of standard authorization protocol – Interoperable cross domain 143 ©2016 Bespoke Engineering LLC
  144. 144. @justin__richerhttps://bspk.io/ OpenID Connect • IdP offers interactive OAuth flows • ID Token carries authentication information – Formatted as a JWT – Audience is the client, not the resource • UserInfo Endpoint – Standard set of claims and scopes 144 ©2016 Bespoke Engineering LLC
  145. 145. @justin__richerhttps://bspk.io/ The parts of OpenID Connect ©2016 Bespoke Engineering LLC 145
  146. 146. @justin__richerhttps://bspk.io/ Can we use the access token? • Audience of the access token is the protected resource • Audience of an authentication event is the client • Therefore we need a new token 146 ©2016 Bespoke Engineering LLC
  147. 147. @justin__richerhttps://bspk.io/ Why a separate ID Token? • ID token is directed to the client – Client doesn’t send it anywhere – Format is known to the client • ID token is consumed and (usually) discarded 147 ©2016 Bespoke Engineering LLC
  148. 148. @justin__richerhttps://bspk.io/ Inside an ID Token eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwOi8vbG9jY Wxob3N0OjkwMDEvIiwic3ViIjoiOVhFMy1KSTM0LTAwMTMyQSIsImF1Z CI6Im9hdXRoLWNsaWVudC0xIiwiZXhwIjoxNDQwOTg3NTYxLCJpYXQiOj E0NDA5ODY1NjF9. LC5XJDhxhA5BLcT3VdhyxmMf6EmlFM_TpgL4qycbHy7JYsO6j1pGUBmA iXTO4whK1qlUdjR5kUmICcYa5foJUfdT9xFGDtQhRcG3- dOg2oxhX2r7nhCjzUnOIebr5POySGQ8ljT0cLm45edv_rO5fSVPdwYGSa7 QGdhB0bJ8KJ__RsyKB707n09y1d92ALwAfaQVoyCjYB0uiZM9Jb8yHsvy MEudvSD5urRuHnGny8YlGDIofP6SXh5- 1TlR7ST7R7h9f4Pa0lD9SXEzGUG816HjIFOcD4aAJXxn_QMlRGSfL8NlIz2 9PrZ2xqg8w2w84hBQcgchAmj1TvaT8ogg6w 148 ©2016 Bespoke Engineering LLC
  149. 149. @justin__richerhttps://bspk.io/ Inside an ID Token eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwOi8vbG9jY Wxob3N0OjkwMDEvIiwic3ViIjoiOVhFMy1KSTM0LTAwMTMyQSIsImF1Z CI6Im9hdXRoLWNsaWVudC0xIiwiZXhwIjoxNDQwOTg3NTYxLCJpYXQiOj E0NDA5ODY1NjF9. LC5XJDhxhA5BLcT3VdhyxmMf6EmlFM_TpgL4qycbHy7JYsO6j1pGUBmA iXTO4whK1qlUdjR5kUmICcYa5foJUfdT9xFGDtQhRcG3- dOg2oxhX2r7nhCjzUnOIebr5POySGQ8ljT0cLm45edv_rO5fSVPdwYGSa7 QGdhB0bJ8KJ__RsyKB707n09y1d92ALwAfaQVoyCjYB0uiZM9Jb8yHsvy MEudvSD5urRuHnGny8YlGDIofP6SXh5- 1TlR7ST7R7h9f4Pa0lD9SXEzGUG816HjIFOcD4aAJXxn_QMlRGSfL8NlIz2 9PrZ2xqg8w2w84hBQcgchAmj1TvaT8ogg6w 149 ©2016 Bespoke Engineering LLC
  150. 150. @justin__richerhttps://bspk.io/ Body of an ID Token { "iss": "http://localhost:9001/", "sub": "9XE3-JI34-00132A", "aud": "oauth-client-1", "exp": 1440987561, "iat": 1440986561 } 150 ©2016 Bespoke Engineering LLC
  151. 151. @justin__richerhttps://bspk.io/ Body of an ID Token { "iss": "http://localhost:9001/", "sub": "9XE3-JI34-00132A", "aud": "oauth-client-1", "exp": 1440987561, "iat": 1440986561 } 151 ©2016 Bespoke Engineering LLC
  152. 152. @justin__richerhttps://bspk.io/ UserInfo Endpoint { "sub": "9XE3-JI34-00132A", "preferred_username": "alice", "name": "Alice", "email": "alice.wonderland@example.com", "email_verified": true } 152 ©2016 Bespoke Engineering LLC
  153. 153. @justin__richerhttps://bspk.io/ UserInfo Endpoint { "sub": "9XE3-JI34-00132A", "preferred_username": "alice", "name": "Alice", "email": "alice.wonderland@example.com", "email_verified": true } 153 ©2016 Bespoke Engineering LLC
  154. 154. @justin__richerhttps://bspk.io/ WRAPPING UP 154
  155. 155. @justin__richerhttps://bspk.io/ Transactional Authorization 155
  156. 156. @justin__richerhttps://bspk.io/ THANK YOU http://oauthinaction.com/ 156

×