DDD Melbourne 2019 : Modern Authentication 101

1. Dasith Wijesiriwardena A Story of Identity, Set Amongst The Clouds

2. About Me

3. 1. Identity & Trust > Identity, authentication and authorization > Trust and claims based identity > Parties involved > What do they solve? > Concepts and Acronyms > Main Flows 3. OAuth and OpenID Connect 2. Tokens > SAML and JWT

5. Definitions Identity: Unique name of a person, device, or combination of both. Authentication: Process of verifying that identity. Authorization: Function of specifying access rights/privileges to resources.

6. Definitions Access Token An object which represents the right to perform some operation. Identity Token An object that aids in proving the user's identity and authenticating that user.

7. Traditional Approach Credentials Application Lookup User Database User / Browser / UI

8. Identity Islands Pet Sitting Service Rent A Car Flight Bookings @#*()!~<+|> You have been pwned Breach

10. Scenario: Renting a Car Hi. I’m Dilbert. I like to rent your finest car. Hi Dilbert. My name is Amy. Can you please provider a driver’s license or passport? Trust

11. Claims Based Identity A claim is a statement that one subject, such as a person or organization, makes about itself or another subject. The subject making the claim or claims is the provider. - Wikipedia.org

12. Dilbert Adams Drivers License as an Identity Token Claims about the Subject • Name • Address • Date of birth • Photo Issuer (Identity Provider) • VicRoads Validation • Holographic Logo

13. • User • Subject (Sub) • Resource Owner (RO) • Relying Party (RP) • Client • Audience (Aud) • Resource • Identity Provider (IdP) • Authorization Server (AS) • Issuing Authority (ISS) • Token Issuer • Security Token Service (STS) • Login Server So many names… Application

14. Modern Approach Identity Provider Trust Credentials Token Token Application User / Browser / UI Validation

15. Recap • Authentication vs Authorization • Claims based identity • Parties involved • Traditional and modern approaches • Leveraging existing trust relationships • Terms • User, Subject, Resource Owner • Relying Party, Client • Id Provider, Auth Server, Token Issuer

17. Passwords 1. Password 2. Password Access TokensVS 1. Password2. Token 3. Token If token is a reference token, exchange it for identity claims from the IdP 4. Ref Token 5. Claims

18. Security Assertion Markup Language Open standard for exchanging authentication and authorization data between parties.

19. https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

20. Anatomy of a SAML Token

21. Assertion Anatomy of a SAML Token

22. Anatomy of a SAML Token Subject

23. Anatomy of a SAML Token Conditions

24. Anatomy of a SAML Token Auth Stmnt

25. Anatomy of a SAML Token Attributes

26. JSON Web Tokens Internet standard for creating JSON-based tokens Header Algorithm & Token Type { "alg": "HS256", "typ": "JWT" } Payload Data { "sub": "1234567890", "name": "John Doe", "iat": 1516239022 } Signature Verification HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), Client Secret )

27. eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjFMVE16YWtpaGlSbGFfOHoyQkVKVlhlV01xbyJ9. eyJ2ZXIiOiIyLjAiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vOTE4ODA0MG QtNmM2Ny00YzViLWIxMTItMzZhMzA0YjY2ZGFkL3YyLjAiLCJzdWIiOiJBQUFBQUFBQUFBQUFBQUFB QUFBQUFJa3pxRlZyU2FTYUZIeTc4MmJidGFRIiwiYXVkIjoiNmNiMDQwMTgtYTNmNS00NmE3LWI5O TUtOTQwYzc4ZjVhZWYzIiwiZXhwIjoxNTM2MzYxNDExLCJpYXQiOjE1MzYyNzQ3MTEsIm5iZiI6MTUz NjI3NDcxMSwibmFtZSI6IkFiZSBMaW5jb2xuIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiQWJlTGlAbWljcm9 zb2Z0LmNvbSIsIm9pZCI6IjAwMDAwMDAwLTAwMDAtMDAwMC02NmYzLTMzMzJlY2E3ZWE4MSIsI nRpZCI6IjMzMzgwNDBkLTZjNjctNGM1Yi1iMTEyLTM2YTMwNGI2NmRhZCIsIm5vbmNlIjoiMTIzNTIzIi wiYWlvIjoiRGYyVVZYTDFpeCFsTUNXTVNPSkJjRmF0emNHZnZGR2hqS3Y4cTVnMHg3MzJkUjVNQjV CaXN2R1FPN1lXQnlqZDhpUURMcSFlR2JJRGFreXA1bW5PcmNkcUhlWVNubHRlcFFtUnA2QUlaOGp ZIn0=. 1AFWW-Ck5nROwSlltm7GzZvDwUkqvhSQpm55TQsmVo9Y59cLhRXpvB8n- 55HCr9Z6G_31_UbeUkoz612I2j_Sm9FFShSDDjoaLQr54CreGIJvjtmS3EkK9a7SJBbcpL1MpUtlfygow3 9tFjY7EVNW9plWUvRrTgVk7lYLprvfzw-CIqw3gHC- T7IK_m_xkr08INERBtaecwhTeN4chPC4W3jdmw_lIxzC48YoQ0dB1L9- ImX98Egypfrlbm0IBL5spFzL6JDZIRRJOu8vecJvj1mq-IUhGt0MacxX8jdxYLP- KUu2d9MbNKpCKJuZ7p8gwTL5B7NlUdh_dmSviPWrw Anatomy of a JWT

28. eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjFMVE16YWtpaGlSbGFfOHoyQkVKVlhlV01xbyJ9. eyJ2ZXIiOiIyLjAiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vOTE4ODA0MG QtNmM2Ny00YzViLWIxMTItMzZhMzA0YjY2ZGFkL3YyLjAiLCJzdWIiOiJBQUFBQUFBQUFBQUFBQUFB QUFBQUFJa3pxRlZyU2FTYUZIeTc4MmJidGFRIiwiYXVkIjoiNmNiMDQwMTgtYTNmNS00NmE3LWI5O TUtOTQwYzc4ZjVhZWYzIiwiZXhwIjoxNTM2MzYxNDExLCJpYXQiOjE1MzYyNzQ3MTEsIm5iZiI6MTUz NjI3NDcxMSwibmFtZSI6IkFiZSBMaW5jb2xuIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiQWJlTGlAbWljcm9 zb2Z0LmNvbSIsIm9pZCI6IjAwMDAwMDAwLTAwMDAtMDAwMC02NmYzLTMzMzJlY2E3ZWE4MSIsI nRpZCI6IjMzMzgwNDBkLTZjNjctNGM1Yi1iMTEyLTM2YTMwNGI2NmRhZCIsIm5vbmNlIjoiMTIzNTIzIi wiYWlvIjoiRGYyVVZYTDFpeCFsTUNXTVNPSkJjRmF0emNHZnZGR2hqS3Y4cTVnMHg3MzJkUjVNQjV CaXN2R1FPN1lXQnlqZDhpUURMcSFlR2JJRGFreXA1bW5PcmNkcUhlWVNubHRlcFFtUnA2QUlaOGp ZIn0=. 1AFWW-Ck5nROwSlltm7GzZvDwUkqvhSQpm55TQsmVo9Y59cLhRXpvB8n- 55HCr9Z6G_31_UbeUkoz612I2j_Sm9FFShSDDjoaLQr54CreGIJvjtmS3EkK9a7SJBbcpL1MpUtlfygow3 9tFjY7EVNW9plWUvRrTgVk7lYLprvfzw-CIqw3gHC- T7IK_m_xkr08INERBtaecwhTeN4chPC4W3jdmw_lIxzC48YoQ0dB1L9- ImX98Egypfrlbm0IBL5spFzL6JDZIRRJOu8vecJvj1mq-IUhGt0MacxX8jdxYLP- KUu2d9MbNKpCKJuZ7p8gwTL5B7NlUdh_dmSviPWrw Header Anatomy of a JWT

29. eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjFMVE16YWtpaGlSbGFfOHoyQkVKVlhlV01xbyJ9. eyJ2ZXIiOiIyLjAiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vOTE4ODA0MG QtNmM2Ny00YzViLWIxMTItMzZhMzA0YjY2ZGFkL3YyLjAiLCJzdWIiOiJBQUFBQUFBQUFBQUFBQUFB QUFBQUFJa3pxRlZyU2FTYUZIeTc4MmJidGFRIiwiYXVkIjoiNmNiMDQwMTgtYTNmNS00NmE3LWI5O TUtOTQwYzc4ZjVhZWYzIiwiZXhwIjoxNTM2MzYxNDExLCJpYXQiOjE1MzYyNzQ3MTEsIm5iZiI6MTUz NjI3NDcxMSwibmFtZSI6IkFiZSBMaW5jb2xuIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiQWJlTGlAbWljcm9 zb2Z0LmNvbSIsIm9pZCI6IjAwMDAwMDAwLTAwMDAtMDAwMC02NmYzLTMzMzJlY2E3ZWE4MSIsI nRpZCI6IjMzMzgwNDBkLTZjNjctNGM1Yi1iMTEyLTM2YTMwNGI2NmRhZCIsIm5vbmNlIjoiMTIzNTIzIi wiYWlvIjoiRGYyVVZYTDFpeCFsTUNXTVNPSkJjRmF0emNHZnZGR2hqS3Y4cTVnMHg3MzJkUjVNQjV CaXN2R1FPN1lXQnlqZDhpUURMcSFlR2JJRGFreXA1bW5PcmNkcUhlWVNubHRlcFFtUnA2QUlaOGp ZIn0=. 1AFWW-Ck5nROwSlltm7GzZvDwUkqvhSQpm55TQsmVo9Y59cLhRXpvB8n- 55HCr9Z6G_31_UbeUkoz612I2j_Sm9FFShSDDjoaLQr54CreGIJvjtmS3EkK9a7SJBbcpL1MpUtlfygow3 9tFjY7EVNW9plWUvRrTgVk7lYLprvfzw-CIqw3gHC- T7IK_m_xkr08INERBtaecwhTeN4chPC4W3jdmw_lIxzC48YoQ0dB1L9- ImX98Egypfrlbm0IBL5spFzL6JDZIRRJOu8vecJvj1mq-IUhGt0MacxX8jdxYLP- KUu2d9MbNKpCKJuZ7p8gwTL5B7NlUdh_dmSviPWrw Payload Anatomy of a JWT

30. eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjFMVE16YWtpaGlSbGFfOHoyQkVKVlhlV01xbyJ9. eyJ2ZXIiOiIyLjAiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vOTE4ODA0MG QtNmM2Ny00YzViLWIxMTItMzZhMzA0YjY2ZGFkL3YyLjAiLCJzdWIiOiJBQUFBQUFBQUFBQUFBQUFB QUFBQUFJa3pxRlZyU2FTYUZIeTc4MmJidGFRIiwiYXVkIjoiNmNiMDQwMTgtYTNmNS00NmE3LWI5O TUtOTQwYzc4ZjVhZWYzIiwiZXhwIjoxNTM2MzYxNDExLCJpYXQiOjE1MzYyNzQ3MTEsIm5iZiI6MTUz NjI3NDcxMSwibmFtZSI6IkFiZSBMaW5jb2xuIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiQWJlTGlAbWljcm9 zb2Z0LmNvbSIsIm9pZCI6IjAwMDAwMDAwLTAwMDAtMDAwMC02NmYzLTMzMzJlY2E3ZWE4MSIsI nRpZCI6IjMzMzgwNDBkLTZjNjctNGM1Yi1iMTEyLTM2YTMwNGI2NmRhZCIsIm5vbmNlIjoiMTIzNTIzIi wiYWlvIjoiRGYyVVZYTDFpeCFsTUNXTVNPSkJjRmF0emNHZnZGR2hqS3Y4cTVnMHg3MzJkUjVNQjV CaXN2R1FPN1lXQnlqZDhpUURMcSFlR2JJRGFreXA1bW5PcmNkcUhlWVNubHRlcFFtUnA2QUlaOGp ZIn0=. 1AFWW-Ck5nROwSlltm7GzZvDwUkqvhSQpm55TQsmVo9Y59cLhRXpvB8n- 55HCr9Z6G_31_UbeUkoz612I2j_Sm9FFShSDDjoaLQr54CreGIJvjtmS3EkK9a7SJBbcpL1MpUtlfygow3 9tFjY7EVNW9plWUvRrTgVk7lYLprvfzw-CIqw3gHC- T7IK_m_xkr08INERBtaecwhTeN4chPC4W3jdmw_lIxzC48YoQ0dB1L9- ImX98Egypfrlbm0IBL5spFzL6JDZIRRJOu8vecJvj1mq-IUhGt0MacxX8jdxYLP- KUu2d9MbNKpCKJuZ7p8gwTL5B7NlUdh_dmSviPWrw Anatomy of a JWT Signature

31. Sign Function Constructing a JWT Header Payload SecretSignature = Header Payload SignatureJWT = base64ue base64ue base64ue base64ue base64ue Header Payload JSON Data= = JSON Data

32. Sign Function Constructing a JWT Header Payload SecretSignature = Header Payload SignatureJWT = base64ue base64ue base64ue base64ue base64ue Header Payload JSON Data= = JSON Data base64ue base64ue Header Payload

33. Header Payload Sign Function Constructing a JWT Header Payload SecretSignature = Header Payload SignatureJWT = base64ue base64ue base64ue base64ue base64ue Header Payload JSON Data= = JSON Data

34. Header Payload Sign Function Constructing a JWT Header Payload SecretSignature = Header Payload SignatureJWT = base64ue base64ue base64ue base64ue base64ue Header Payload JSON Data= = JSON Data

35. JWT Sign Function Verifying a JWT Header Payload SecretSignature = Header Payload Signature == base64ue base64ue base64ue base64ue base64ue Signature Signature Is Valid?

39. JWT and Drivers License Dilbert Adams

45. Recap • Passwords vs Tokens • Why tokens are preferred • SAML (Security Assertion Markup Language) • JWT (JSON Web Token) • Header, Payload, Signature • Constructing • Verifying

47. OAuth 2.0 OAuth 2.0 is the industry-standard protocol for authorization. It focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. - OAuth.net

48. History of OAuth 2007 December OAuth 1.0 Final Draft 2010 April Standardized via IETF 2012 October OAuth 2.0 Implicit, Auth Code, Resource Owner, Client Credentials flows Today Device Code, Token Exchange etc

49. Limitation of OAuth • Only specifies a solution to authorization concerns • No standard way of describing claims Enter “OpenID Connect”

50. OpenID Connect OpenID Connect is an interoperable authentication protocol based on the OAuth 2.0 family of specifications. It uses straightforward REST/JSON message flows. - OpenID.net (Identity, Authentication) + OAuth 2.0 = OpenID Connect

51. OpenID Connect Concepts Registration Sign Up Client / Relying PartySubject Issuer / IdP  Store ClientId and Secret  Pick correct flow for public vs confidential clients  Construct a HTTP request  Handle call-back  Verify token and manage lifetime  Allow client and user registration  Discovery endpoint for meta data “.well-known/openid- configuration”  Issuer, signing certificate public key, supported claims, scopes etc..  Implement endpoints for Token, Authorization and UserInfo  Register and sign in to the IdP  Inspect and grant consent to the requested scopes

55. OpenID Connect Discovery Endpoint Example https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration

60. Token Types Key representing access to a resource. Can be self contained or a reference token. access_token Contains identity information in the form of a (self contained) JWT. id_token A reference token that can be used to obtain a new access_token when the current one is no longer valid. refresh_token A reference token that can be exchanged for the access_token. code (authorization code)

61. Endpoints Authorization Token Userinfo Performs the authorization and returns a supported combination of access_token, id_token , refresh_token, and/or code Exchanges a reference token (code or refresh_token) to an access_token, id_token and/or refresh_token. Exchange the access_token for a set of claims about the identity of the subject.

62. Application Types Confidential Clients Public Clients Other WebApp (running on backend) Single Page Apps (Javascript) Input Constrained Devices WebApi Native App Native App Daemon Apps

63. Some OAuth 2.0 Flows • Implicit grant • Authorization code grant • Hybrid flow • Token Exchange (On-behalf-of) • Client credentials grant • Device code grant • Resource owner password grant*

64. Implicit Grant Flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-implicit-grant-flow

65. Implicit Grant Flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-implicit-grant-flow GET https://idp.com/authorize? client_id=my_client_id &response_type=id_token &redirect_uri=callback_url &scope=openid&response_mode=fragment &state=12345&nonce=678910

66. Implicit Grant Flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-implicit-grant-flow

67. Implicit Grant Flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-implicit-grant-flow GET https://localhost/myapp/# access_token=jwt_here &token_type=Bearer &expires_in=3599 &scope=valid_scopes &id_token=jwt_here &state=12345

68. Implicit Grant Flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-implicit-grant-flow Authorization: Bearer access_token

69. Authorization Code Grant Flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow

70. Authorization Code Grant Flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow GET https://idp.com/authorize? client_id=my_client_id &response_type=code &redirect_uri=callback_url &scope=openid &response_mode=query &state=12345 &nonce=678910

71. Authorization Code Grant Flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow

72. Authorization Code Grant Flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow GET https://localhost/webapp? code=reference_token_here &state=12345

73. Authorization Code Grant Flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow GET https://idp.com/token? client_id=my_client_id &client_secret=some_secret &grant_type=authorization_code &code=reference_token_here &redirect_uri=callback_url

74. Authorization Code Grant Flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow { "access_token": jwt_here "token_type": "Bearer", "expires_in": 3599, "scope": consented scopes, "refresh_token": ref_token "id_token": jwt_here }

75. Authorization Code Grant Flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow Authorization: Bearer access_token

76. Hybrid Flow • Same as the implicit flow • With additional reference token (authorization code). • Exchange it for an access token using the token endpoint. https://YOUR_REDIRECT_URI /#access_token=opaque_token &expires_in=7200 &token_type=Bearer &code=AUTHORIZATION_CODE &id_token=jwt

77. Client Credentials Grant Flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow Credentials Admin consent required Authorization Server Dilbert’s Driving History

78. Token Exchange Flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow Authorization Server

79. Device Code Grant Flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code

85. Resource Owner Password Grant Flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc

86. Picking the right OAuth flow Public Client ? Native or SPA ? Implicit Auth Code + PKCE Has an active user ? Client Credentials Input Constrained ? Legacy App ?Resource Owner Password Cred… Device Code Auth Code Yes No No Yes No No Yes Yes SPA Native

87. Recap • OAuth • What it solves • OpenID Connect • What it solves • Concepts • Endpoints • Picking an appropriate OAuth flow

88. Want More? • Protocol Reference: https://oauth.net • Starter Kit: https://connect2id.com/learn • Choosing Flows: https://auth0.com/docs/api- auth/which-oauth-flow-to-use • MS Identity Platform (Azure AD) Documentation • IdentityServer: https://identityserver.io • Rob Moore & Matt Davies : Modern Auth @ NDC 2016

89. Thank you! @dasiths dasith.me

90. COFFEE BY WIFI BY CHILDCARE BY

DDD Melbourne 2019 : Modern Authentication 101

DDD Melbourne 2019 : Modern Authentication 101

Recommended

More Related Content

What's hot

What's hot(15)

Similar to DDD Melbourne 2019 : Modern Authentication 101

Similar to DDD Melbourne 2019 : Modern Authentication 101(20)

Recently uploaded

Recently uploaded(20)

DDD Melbourne 2019 : Modern Authentication 101

Editor's Notes