Recommended
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
- 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.
- 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 )
- 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?
- 36. JWT Sign Function Verifying a JWT Header Payload SecretSignature = Header Payload Signature == base64ue base64ue base64ue base64ue base64ue Signature Signature Is Valid?
- 37. JWT Sign Function Verifying a JWT Header Payload SecretSignature = Header Payload Signature == base64ue base64ue base64ue base64ue base64ue Signature Signature Is Valid?
- 38. 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
- 40. JWT and Drivers License Dilbert Adams
- 41. JWT and Drivers License Dilbert Adams
- 42. JWT and Drivers License Dilbert Adams
- 43. JWT and Drivers License Dilbert Adams
- 44. 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
- 52. 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
- 53. 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
- 54. 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
- 56. OpenID Connect Discovery Endpoint Example https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
- 57. OpenID Connect Discovery Endpoint Example https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
- 58. OpenID Connect Discovery Endpoint Example https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
- 59. 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*
- 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
- 79. Device Code Grant Flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code
- 80. Device Code Grant Flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code
- 81. Device Code Grant Flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code
- 82. Device Code Grant Flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code
- 83. Device Code Grant Flow https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code
- 84. 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
- 90. COFFEE BY WIFI BY CHILDCARE BY
Editor's Notes
- Cons of this approach Have to lookup database each time or save state about session Non standard ways of storing passwords Password management
- Malicious actor Weakest link exposes everything
- Existing trust relationship
- They are what the subject is or is not. It is up to the application receiving the incoming claim to map the is/is not claims to the may/may not rules of the application.
- Pros No credentials are given to the application Standardized way of storing credentials and managing passwords by well known IdPs.
- Utilize existing trust relationships Self contained token: Drivers License Reference Token: Visa application number Story about 3 store and pin
- Why protocols are important Why SAML was popular (Swiss army knife)
- Why protocols are important Why SAML was popular (Swiss army knife)
- Why JWT are more modern Light weight Self contained Verifiable
- HS256 Symmetric (Shared secret) RS256 Asymmetric key (certificate key pair)
- HS256 Symmetric (Shared secret) RS256 Asymmetric key (certificate key pair)
- HS256 Symmetric (Shared secret) RS256 Asymmetric key (certificate key pair)
- HS256 Symmetric (Shared secret) RS256 Asymmetric key (certificate key pair) Wax seal
- HS256 Symmetric (Shared secret) RS256 Asymmetric key (certificate key pair)
- HS256 Symmetric (Shared secret) RS256 Asymmetric key (certificate key pair)
- HS256 Symmetric (Shared secret) RS256 Asymmetric key (certificate key pair)
- HS256 Symmetric (Shared secret) RS256 Asymmetric key (certificate key pair)
- HS256 Symmetric (Shared secret) RS256 Asymmetric key (certificate key pair)
- HS256 Symmetric (Shared secret) RS256 Asymmetric key (certificate key pair)
- HS256 Symmetric (Shared secret) RS256 Asymmetric key (certificate key pair)
- HS256 Symmetric (Shared secret) RS256 Asymmetric key (certificate key pair)
- OAuth began in November 2006 when Blaine Cook was developing the Twitter OpenID implementation The OAuth 1.0 protocol was published as RFC 5849, in April 2010. The OAuth 2.0 framework was published as RFC 6749, in October 2012.
- OAuth began in November 2006 when Blaine Cook was developing the Twitter OpenID implementation The OAuth 1.0 protocol was published as RFC 5849, in April 2010. The OAuth 2.0 framework was published as RFC 6749, in October 2012.
- OpenID Connect specifications were launched on 2014. Google, Microsoft, PingIdentity and PayPal
- ClientId upon registration
- ClientId upon registration
- ClientId upon registration
- ClientId upon registration
- Admin must consent to client application scopes Non interactive flow
- Butler example Delegation JWT Bearer Authorization Grant (RFC 7523) Token Exchange Flow Application needs to request scopes for API A and B up front
- Input constrained devices
- Input constrained devices
- Input constrained devices
- Input constrained devices
- Input constrained devices
- Input constrained devices
- Convert legacy applications to use OAuth
- Proof key for code exchange
- Sponsors