SlideShare a Scribd company logo

OAuth 2.0 Security Reinforced

•
•
T
Torsten Lodderstedt

The OAuth working group recently decided to discourage use of the implicit grant. But that’s just the most prominent recommendation the working group is about to publish in the upcoming OAuth 2.0 Security Best Current Best Practice (https://tools.ietf.org/html/draft-ietf-oauth-security-topics), which will elevate OAuth security to the next level. The code flow shall be used with PKCE only and tokens should be sender constraint to just mention a few. Development of this enhanced recommendations was driven by several factors, including experiences gathered in the field, security research results, the increased dynamics and sensitivity of the use cases OAuth is used protect and technological changes. This session will present the new security recommendations in detail along with the underlying rationales.

Related slideshows

OAuth 2.0 and OpenId Connect
OAuth 2.0 and OpenId ConnectOAuth 2.0 and OpenId Connect
OAuth 2.0 and OpenId Connect
 
OAuth 2
OAuth 2OAuth 2
OAuth 2
 
OAuth2 - Introduction
OAuth2 - IntroductionOAuth2 - Introduction
OAuth2 - Introduction
 
1 of 27
Download to read offline
OAuth 2.0 Security Reinforced Dr. Torsten Lodderstedt @tlodderstedt yes® European Identity & Cloud Conference 2019
Who uses OAuth?
The OAuth 2.0 Success Story ● Tremendous adoption since publication as RFC 6749 in 2012 ● Driven by large service providers and OpenID Connect ● Key success factors: simplicity & versatility But: Is it secure?
Security Challenges for OAuth
Implementations … ● [Li et al., 2014] 60 chinese clients, more than half vulnerable to CSRF ● [Yang et al., 2016] Out of 405 clients, 55% do not handle state (CSRF protection) correctly ● [Shebab et al., 2015] 25% of OAuth clients in Alexa Top 10000 vulnerable to CSRF ● [Chen et al., 2014] 89 of 149 mobile clients vulnerable to one or more attacks ● [Wang et al., 2013] Vulnerabilities in Facebook PHP SDK and other OAuth SDKs ● [Sun et al., 2012] 96 Clients, almost all vulnerable to one or more attacks … plus known hacks of
Challenge 1: Implementation Flaws ● We still see many implementation flaws
Challenge 1: Implementation Flaws ● We still see many implementation flaws ● Known anti-patterns are still used ○ Insufficient redirect URI checking (code/token is redirected to attacker) ○ state parameter is not used properly to defend against CSRF ○ …
Challenge 1: Implementation Flaws ● We still see many implementation flaws ● Known anti-patterns are still used ○ Insufficient redirect URI checking (code/token is redirected to attacker) ○ state parameter is not used properly to defend against CSRF ○ … ● Technological changes bring new problems ○ E.g., URI fragment handling in browsers changed → Vulnerability when used with open redirectors Open Redirector: Parameterized, unchecked redirection. E.g.: https://client.example/anything?resume_at=https://evil.example Redirects to https://evil.example
Challenge 2: High-Stakes Environments New Use Cases, e.g., Open Banking, require a very high level of security Also: eIDAS/QES (legally binding electronic signatures) and eHealth Far beyond the scope of the original security threat model!
Challenge 3: Dynamic and Complex Setups Originally anticipated: One trustworthy OAuth provider, statically configured per client Client Resource ServerResource Server Authorization ServerResource Server OAuth Provider
OAuth Provider B Challenge 3: Dynamic and Complex Setups Client Resource ServerResource Server Authorization Server Resource Server Resource Server OAuth Provider C Resource Server Authorization ServerResource Server OAuth Provider A Resource ServerResource Server Authorization Server Resource Server Dynamic relationships Multiple AS/RS per client Today: Not all entities are trustworthy! AS M ix-Up Attack! Found through formal analysis
● OAuth Security Workshop ● New RFC draft: OAuth Security Best Current Practice AS Mix-Up Attack: Fallout #osw2019
OAuth 2.0 Security Best Current Practice RFC ● Currently under development at the IETF ● Refined and enhanced security guidance for OAuth 2.0 implementers ● Complements existing security guidance in RFCs 6749, 6750, and 6819 ● Updated, more comprehensive Threat Model ● Description of Attacks and Mitigations ● Simple and actionable recommendations
The Seven Most Important Recommendations in the OAuth Security BCP
User ① Do not use the OAuth Implicit Grant any longer! GET /authorize?… Redirect to Authorization Server AS/RS User authenticates & consents Redirect to rp.com/authok#access_token=foo23&… Use access_token (Single-Page Apps) Access token available in web application Send access_token (Non-SPA) Use access_token Threat: Access token leakage from web application (XSS, browser history, proxies, operating systems, ...) Threat: Access token replay! Threat: Access token injection! Client
The Implicit Grant ... ● sends powerful and potentially long-lived tokens through the browser, ● lacks features for sender-constraining access tokens, ● provides no protection against access token replay and injection, and ● provides no defense in depth against XSS, URL leaks, etc.! Why is Implicit even in RFC6749? No Cross-Origin Resource Sharing in 2012! ⇒ No way of (easily) using OAuth in SPAs. ⇒ Not needed in 2019! Recommendation “Clients SHOULD NOT use the implicit grant [...]” “Clients SHOULD instead use the response type code (aka authorization code grant type) [...]”
AS/RSUser Use the Authorization Code Grant! GET /authorize?code_challenge=sha256xyz&... Redirect to Authorization Server ... Redirect to rp.com/authok?code=bar42&... POST /token, code=bar42 &code_verifier=xyz... Use access_token Send code Send access_token Mitigation: Sender-Constrained Token E.g., access token bound to mTLS certificate. Mitigation: Single-use Code Double use leads to access token invalidation! Client Mitigation: Proof Key for Code Exchange (PKCE) - Code only useful with code_verifier - Code replay/injection prevented by PKCE.
Authorization Code Grant with PKCE & mTLS … ● protects against code and token replay and injection, ● supports sender-constraining of access tokens, ● provides defense in depth! Recommendation “Clients utilizing the authorization grant type MUST use PKCE [...]” “Authorization servers SHOULD use TLS-based methods for sender-constrained access tokens [...]”
② Prevent Mix-Up Attacks! ● Clients must be able to see originator of authorization response ○ Clients should use a separate redirect URI for each AS ○ Alternative: issuer in authorization response for OpenID Connect ● Clients must keep track of desired AS (“explicit tracking”)
③ Stop Redirects Gone Wild! ● Enforce exact redirect URI matching ○ Simpler to implement on AS side ○ Adds protection layer against open redirection ● Clients MUST avoid open redirectors! ○ Use whitelisting of target URLs ○ or authenticate redirection request
④ Prevent CSRF Attacks! ● RFC 6749 and RFC 6819 recommend use of state parameter ● Updated advice (proposed): ○ If PKCE is used, state is not needed for CSRF protection ○ state can again be used for application state
⑤ Limit Privileges of Access Tokens! ● Sender-constraining (mTLS or HTTP Token Binding) ● Receiver-constraining (only valid for certain RS) ● Reduce scope and lifetime and use refresh tokens - defense in depth!
AS/RSUser Refresh Tokens ... POST /token, code=... Use access_token¹ Send code access_token¹ refresh_token¹ Access Token: Narrow scope and limited lifetime! Access Token expires. POST /token, refresh_token¹ access_token² refresh_token² Use access_token² Client
⑥ Protect Refresh Tokens! ● Attractive target since refresh tokens represent overall grant ● Requirement: Protection from theft and replay ○ Client Binding and Authentication ■ Confidential clients only ○ Sender-Constrained Refresh Tokens ■ mTLS now supports this even for public clients ○ Refresh Token Rotation ■ For public clients unable to use mTLS
⑦ Do not use the R.O.P.C.G.* any longer! *Resource Owner Password Credentials Grant AS/RSUser Username/Password for AS Username/Password for AS Use access_token Send access_token ● Client sees username/password of user ● Complicated or impossible to integrate 2-factor-authentication ● Stopgap solution for migrating to OAuth flows ● Grant name too long, even for Germans ;-) Client
Summary ● OAuth 2.0 implementations often vulnerable ● Protocol needs updated security guidance ○ Protection against new attacks ○ Adaptations to evolving web environment ○ Accounting for new use cases ● New IETF OAuth Security BCP (https://tools.ietf.org/html/draft-ietf-oauth-security-topics) ○ Addresses new and old security vulnerabilities ○ Provides actionable solutions
Q&A! Latest Drafts & Publications OAuth 2.0 Security BCP https://tools.ietf.org/html/draft-ietf-oauth-security-topics OpenID Connect 4 Identity Assurance https://openid.net/specs/openid-connect-4-identity-assurance.html Transaction Authorization or why we need to re-think OAuth scopes https://cutt.ly/oauth-transaction-authorization Cross-Browser Payment Initiation Attack https://cutt.ly/cross-browser-payment-initation JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) https://openid.net/specs/openid-financial-api-jarm-ID1.html OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer https://tools.ietf.org/html/draft-fett-oauth-dpop Dr. Torsten Lodderstedt CTO, yes.com torsten@yes.com @tlodderstedt yes® Talk to me about - Details on attacks and mitigations - The OAuth Security Workshop - Other emerging OAuth & OpenID stuff - Working at yes.com

More Related Content

OAuth 2.0 Security Reinforced

  • 1. OAuth 2.0 Security Reinforced Dr. Torsten Lodderstedt @tlodderstedt yes® European Identity & Cloud Conference 2019
  • 3. The OAuth 2.0 Success Story ● Tremendous adoption since publication as RFC 6749 in 2012 ● Driven by large service providers and OpenID Connect ● Key success factors: simplicity & versatility But: Is it secure?
  • 5. Implementations … ● [Li et al., 2014] 60 chinese clients, more than half vulnerable to CSRF ● [Yang et al., 2016] Out of 405 clients, 55% do not handle state (CSRF protection) correctly ● [Shebab et al., 2015] 25% of OAuth clients in Alexa Top 10000 vulnerable to CSRF ● [Chen et al., 2014] 89 of 149 mobile clients vulnerable to one or more attacks ● [Wang et al., 2013] Vulnerabilities in Facebook PHP SDK and other OAuth SDKs ● [Sun et al., 2012] 96 Clients, almost all vulnerable to one or more attacks … plus known hacks of
  • 6. Challenge 1: Implementation Flaws ● We still see many implementation flaws
  • 7. Challenge 1: Implementation Flaws ● We still see many implementation flaws ● Known anti-patterns are still used ○ Insufficient redirect URI checking (code/token is redirected to attacker) ○ state parameter is not used properly to defend against CSRF ○ …
  • 8. Challenge 1: Implementation Flaws ● We still see many implementation flaws ● Known anti-patterns are still used ○ Insufficient redirect URI checking (code/token is redirected to attacker) ○ state parameter is not used properly to defend against CSRF ○ … ● Technological changes bring new problems ○ E.g., URI fragment handling in browsers changed → Vulnerability when used with open redirectors Open Redirector: Parameterized, unchecked redirection. E.g.: https://client.example/anything?resume_at=https://evil.example Redirects to https://evil.example
  • 9. Challenge 2: High-Stakes Environments New Use Cases, e.g., Open Banking, require a very high level of security Also: eIDAS/QES (legally binding electronic signatures) and eHealth Far beyond the scope of the original security threat model!
  • 10. Challenge 3: Dynamic and Complex Setups Originally anticipated: One trustworthy OAuth provider, statically configured per client Client Resource ServerResource Server Authorization ServerResource Server OAuth Provider
  • 11. OAuth Provider B Challenge 3: Dynamic and Complex Setups Client Resource ServerResource Server Authorization Server Resource Server Resource Server OAuth Provider C Resource Server Authorization ServerResource Server OAuth Provider A Resource ServerResource Server Authorization Server Resource Server Dynamic relationships Multiple AS/RS per client Today: Not all entities are trustworthy! AS M ix-Up Attack! Found through formal analysis
  • 12. ● OAuth Security Workshop ● New RFC draft: OAuth Security Best Current Practice AS Mix-Up Attack: Fallout #osw2019
  • 13. OAuth 2.0 Security Best Current Practice RFC ● Currently under development at the IETF ● Refined and enhanced security guidance for OAuth 2.0 implementers ● Complements existing security guidance in RFCs 6749, 6750, and 6819 ● Updated, more comprehensive Threat Model ● Description of Attacks and Mitigations ● Simple and actionable recommendations
  • 14. The Seven Most Important Recommendations in the OAuth Security BCP
  • 15. User ① Do not use the OAuth Implicit Grant any longer! GET /authorize?… Redirect to Authorization Server AS/RS User authenticates & consents Redirect to rp.com/authok#access_token=foo23&… Use access_token (Single-Page Apps) Access token available in web application Send access_token (Non-SPA) Use access_token Threat: Access token leakage from web application (XSS, browser history, proxies, operating systems, ...) Threat: Access token replay! Threat: Access token injection! Client
  • 16. The Implicit Grant ... ● sends powerful and potentially long-lived tokens through the browser, ● lacks features for sender-constraining access tokens, ● provides no protection against access token replay and injection, and ● provides no defense in depth against XSS, URL leaks, etc.! Why is Implicit even in RFC6749? No Cross-Origin Resource Sharing in 2012! ⇒ No way of (easily) using OAuth in SPAs. ⇒ Not needed in 2019! Recommendation “Clients SHOULD NOT use the implicit grant [...]” “Clients SHOULD instead use the response type code (aka authorization code grant type) [...]”
  • 17. AS/RSUser Use the Authorization Code Grant! GET /authorize?code_challenge=sha256xyz&... Redirect to Authorization Server ... Redirect to rp.com/authok?code=bar42&... POST /token, code=bar42 &code_verifier=xyz... Use access_token Send code Send access_token Mitigation: Sender-Constrained Token E.g., access token bound to mTLS certificate. Mitigation: Single-use Code Double use leads to access token invalidation! Client Mitigation: Proof Key for Code Exchange (PKCE) - Code only useful with code_verifier - Code replay/injection prevented by PKCE.
  • 18. Authorization Code Grant with PKCE & mTLS … ● protects against code and token replay and injection, ● supports sender-constraining of access tokens, ● provides defense in depth! Recommendation “Clients utilizing the authorization grant type MUST use PKCE [...]” “Authorization servers SHOULD use TLS-based methods for sender-constrained access tokens [...]”
  • 19. ② Prevent Mix-Up Attacks! ● Clients must be able to see originator of authorization response ○ Clients should use a separate redirect URI for each AS ○ Alternative: issuer in authorization response for OpenID Connect ● Clients must keep track of desired AS (“explicit tracking”)
  • 20. ③ Stop Redirects Gone Wild! ● Enforce exact redirect URI matching ○ Simpler to implement on AS side ○ Adds protection layer against open redirection ● Clients MUST avoid open redirectors! ○ Use whitelisting of target URLs ○ or authenticate redirection request
  • 21. ④ Prevent CSRF Attacks! ● RFC 6749 and RFC 6819 recommend use of state parameter ● Updated advice (proposed): ○ If PKCE is used, state is not needed for CSRF protection ○ state can again be used for application state
  • 22. ⑤ Limit Privileges of Access Tokens! ● Sender-constraining (mTLS or HTTP Token Binding) ● Receiver-constraining (only valid for certain RS) ● Reduce scope and lifetime and use refresh tokens - defense in depth!
  • 23. AS/RSUser Refresh Tokens ... POST /token, code=... Use access_token¹ Send code access_token¹ refresh_token¹ Access Token: Narrow scope and limited lifetime! Access Token expires. POST /token, refresh_token¹ access_token² refresh_token² Use access_token² Client
  • 24. ⑥ Protect Refresh Tokens! ● Attractive target since refresh tokens represent overall grant ● Requirement: Protection from theft and replay ○ Client Binding and Authentication ■ Confidential clients only ○ Sender-Constrained Refresh Tokens ■ mTLS now supports this even for public clients ○ Refresh Token Rotation ■ For public clients unable to use mTLS
  • 25. ⑦ Do not use the R.O.P.C.G.* any longer! *Resource Owner Password Credentials Grant AS/RSUser Username/Password for AS Username/Password for AS Use access_token Send access_token ● Client sees username/password of user ● Complicated or impossible to integrate 2-factor-authentication ● Stopgap solution for migrating to OAuth flows ● Grant name too long, even for Germans ;-) Client
  • 26. Summary ● OAuth 2.0 implementations often vulnerable ● Protocol needs updated security guidance ○ Protection against new attacks ○ Adaptations to evolving web environment ○ Accounting for new use cases ● New IETF OAuth Security BCP (https://tools.ietf.org/html/draft-ietf-oauth-security-topics) ○ Addresses new and old security vulnerabilities ○ Provides actionable solutions
  • 27. Q&A! Latest Drafts & Publications OAuth 2.0 Security BCP https://tools.ietf.org/html/draft-ietf-oauth-security-topics OpenID Connect 4 Identity Assurance https://openid.net/specs/openid-connect-4-identity-assurance.html Transaction Authorization or why we need to re-think OAuth scopes https://cutt.ly/oauth-transaction-authorization Cross-Browser Payment Initiation Attack https://cutt.ly/cross-browser-payment-initation JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) https://openid.net/specs/openid-financial-api-jarm-ID1.html OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer https://tools.ietf.org/html/draft-fett-oauth-dpop Dr. Torsten Lodderstedt CTO, yes.com torsten@yes.com @tlodderstedt yes® Talk to me about - Details on attacks and mitigations - The OAuth Security Workshop - Other emerging OAuth & OpenID stuff - Working at yes.com