SlideShare a Scribd company logo

The Client is not always right! How to secure OAuth authentication from your app.

•Download as PPTX, PDF•
•
Mike Schwartz
Mike Schwartz

The OpenID Connect or OAuth frameworks can be used to achieve a range of security levels. Properly used, it mitigates many risks. However, OpenID Connect’s flexibility, combined with its shared ontogeny with OAuth 2.0, creates opportunities for error--developers may not use (or even know about ) certain features necessary to achieve the transaction integrity they desire. The good news is that client software and middleware services can do some of the heavy lifting. You can have the best of both worlds--maximizing security and developer joy. Whether you’re a developer or security architect, what should you look for in an application that acts as an OpenID Connect client?

Related slideshows

Introduction to SAML 2.0
Introduction to SAML 2.0Introduction to SAML 2.0
Introduction to SAML 2.0
 
Single Sign On 101
Single Sign On 101Single Sign On 101
Single Sign On 101
 
Authentication and Authorization Architecture in the MEAN Stack
Authentication and Authorization Architecture in the MEAN StackAuthentication and Authorization Architecture in the MEAN Stack
Authentication and Authorization Architecture in the MEAN Stack
 
1 of 28
The Client is not always right! Michael Schwartz, CEO Gluu
ServerClient
Level setting
User Agent, UA, Browser Client, Relying Party, RP Subject, sub, User, End User, Person, “Meat” OpenID Provider, Identity Provider, Authorization Server, OP, IDP, AS
Source: Nat Sakimura, CIS 2016 Supporting low to high assurance with OpenID
back channel token front channel token public clientConfidential client
Basic Client Hygiene
No access tokens as query parameters BAD, BAD, BAD, BAD!!!! (I know none of you would do this…) Don’t forget about Form Post Response Mode: the fragment shows up in the browser history http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
Not all client creds are created equal Method Secret Not Sent in the Clear Signed Only client has secret client_secret_basic Client_secret_post client_secret_jwt X X private_key_jwt X X X
Cross Site Request Forgery 1. Use non-static state values to make sure the response received at your callback corresponds to a request you actually made. Verify either state or s_hash in response. CSRF: The Most Common OAuth 2 Vulnerability http://www.twobotechnologies.com/blog/2014/02/importance-of-state-in-oauth2.html
2. iss - verify that the token was issued by the correct OpenID Provider 3. aud - verify this is your client_id 4. nonce - verify it matches the nonce value you sent in your request. 5. exp - verify that the assertion is not expired! Minimal id_token claim validation { "iss": "https://idp.example.com", "aud": "9bac-4ada-9c64", "nonce": "1d58c9a9-cb05-4e7f", "at_hash": "77QmUPjzWtFAnKRQ", "exp": 1494702905, "sub": "3046f517963f" }
6. Verify the signature! TLS is not perfect... Symmetric - use your client secret to verify Asymmetric - use the public key of the OP to verify signature
9. iat- Maybe you want an id_token that was issued with a certain time frame? 10. auth_time - check if too much time has elapsed since the user authenticated. If necessary send the user back for re- authentication with the prompt=login authorization endpoint parameter. Optional id_token claim validation { "at_hash": "ae09d...897d91b", "s_hash": "febb18...29802", "iat": "1494702905", "auth_time": "1494323431" } 7. at_hash - verify that you are using the correct access token. Required for implicit. 8. s_hash - in lieu of the state param, verifies the state without leaking it.
OpenID Connect Implementer’s Guides Basic Client: http://openid.net/specs/openid-connect-basic-1_0.html Implicit Client http://openid.net/specs/openid-connect-implicit-1_0.html
Advanced Client Hygiene
Hybrid Flow “response_type”: “code id_token” Returns id_token from authorization endpoint in addition to code Adds c_hash, enables verification you got the right code. Send code only to the token endpoint of the issuer to prevent IDP mix-up attack. You can also request a token, but why? Don’t ask for an access token unless you can answer that. (And please come see me after and tell me your use case…)
Request Object or Request URI Prevents attacker from tampering with your request parameters. Examples of this attack are the Malicious Endpoint Attack and the IDP Confusion Attack Some OP’s may provide a Request URI endpoint, where the request can be registered (enables state and nonce to be dynamic)
Distinct redirect_uri per OP Check to make sure the response was received at the endpoint intended for this issuer. Cross reference with the state and nonce
Do you need to protect the id_token from the browser (hybrid flow)? Will a JWT be passed to parties that you don’t want to see it? id_token_encrypted_response_alg id_token_encrypted_response_enc userinfo_encrypted_response_alg Userinfo_encrypted_response_enc Do you want to protect the request from the browser? request_object_encryption_alg request_object_encryption_enc Encryption
PKCE Use for all public clients to prevent Authorization Code Interception Attack Require this if third parties use your OP from mobile apps Use SHA 256 as the code challenge method
Mutual TLS Protection for the token endpoint TLS 1.2 or later as defined in RFC 5246 following best practices from RFC 7525. IETF Draft: “Mutual TLS Profiles for OAuth Clients” https://tools.ietf.org/html/draft-campbell-oauth-mtls-01
Token Binding to TLS TLS Channel 1 TLS Channel 2 OAuth 2.0 Token Binding: add SH256 hash of TLS Channel ID to id_token
Specifying ACR (authn context class reference) acr_values param can be sent in the OpenID Connect authentication request default_acr_values can be registered for a client Verify id_token for acceptable acr claim RECOMMENDATION: Use FIDO U2F USB tokens to prevent MITM attacks--authentication stops if the browser and server are not directly connected!
Crypto guidelines RSA keys with a minimum 2048 bits if using RSA cryptography; Elliptic Curve keys with a minimum of 160 bits if using Elliptic Curve cryptography Client secret should have a minimum of 128 bits if using symmetric key cryptography Sign with PS256 (RSASSA-PSS using SHA-256 and MGF1 with SHA-256) or ES256 (ECDSA using P-256 and SHA-256)
Trust: how do I know the public key is authentic? OpenID Connect Federation Draft Spec: http://openid.net/specs/openid-connect-federation-1_0.html Client can download the signing_keys ahead of time, or obtain them from a trusted source like a multi-party federation (check out Kantara OTTO…) Signature enables client to detect if jwks_uri is not authentic
Software statements Restrict client registration... “JWT that asserts metadata values about the client software as a bundle” https://tools.ietf.org/html/rfc7591#section-2.3 Use OpenID Connect RP Metadata Statement as software statement during registration? Extra claims: scopes and claims Signed by federation
OIDC Client Hall of Fame Mod_auth_openidc https://github.com/pingidentity/mod_auth_openidc OIDC-Client-JS https://github.com/IdentityModel/oidc-client-js OXD (Middleware) https://oxd.gluu.org App Auth (iOS / Android) https://github.com/openid Bias Warning… This is Gluu’s client software.
THANK YOU! Questions? sales@gluu.org Schedule a follow up: https://gluu.org/booking Try OXD client software for free: https://oxd.gluu.org

More Related Content

The Client is not always right! How to secure OAuth authentication from your app.

  • 1. The Client is not always right! Michael Schwartz, CEO Gluu
  • 4. User Agent, UA, Browser Client, Relying Party, RP Subject, sub, User, End User, Person, “Meat” OpenID Provider, Identity Provider, Authorization Server, OP, IDP, AS
  • 5. Source: Nat Sakimura, CIS 2016 Supporting low to high assurance with OpenID
  • 6. back channel token front channel token public clientConfidential client
  • 8. No access tokens as query parameters BAD, BAD, BAD, BAD!!!! (I know none of you would do this…) Don’t forget about Form Post Response Mode: the fragment shows up in the browser history http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
  • 9. Not all client creds are created equal Method Secret Not Sent in the Clear Signed Only client has secret client_secret_basic Client_secret_post client_secret_jwt X X private_key_jwt X X X
  • 10. Cross Site Request Forgery 1. Use non-static state values to make sure the response received at your callback corresponds to a request you actually made. Verify either state or s_hash in response. CSRF: The Most Common OAuth 2 Vulnerability http://www.twobotechnologies.com/blog/2014/02/importance-of-state-in-oauth2.html
  • 11. 2. iss - verify that the token was issued by the correct OpenID Provider 3. aud - verify this is your client_id 4. nonce - verify it matches the nonce value you sent in your request. 5. exp - verify that the assertion is not expired! Minimal id_token claim validation { "iss": "https://idp.example.com", "aud": "9bac-4ada-9c64", "nonce": "1d58c9a9-cb05-4e7f", "at_hash": "77QmUPjzWtFAnKRQ", "exp": 1494702905, "sub": "3046f517963f" }
  • 12. 6. Verify the signature! TLS is not perfect... Symmetric - use your client secret to verify Asymmetric - use the public key of the OP to verify signature
  • 13. 9. iat- Maybe you want an id_token that was issued with a certain time frame? 10. auth_time - check if too much time has elapsed since the user authenticated. If necessary send the user back for re- authentication with the prompt=login authorization endpoint parameter. Optional id_token claim validation { "at_hash": "ae09d...897d91b", "s_hash": "febb18...29802", "iat": "1494702905", "auth_time": "1494323431" } 7. at_hash - verify that you are using the correct access token. Required for implicit. 8. s_hash - in lieu of the state param, verifies the state without leaking it.
  • 14. OpenID Connect Implementer’s Guides Basic Client: http://openid.net/specs/openid-connect-basic-1_0.html Implicit Client http://openid.net/specs/openid-connect-implicit-1_0.html
  • 16. Hybrid Flow “response_type”: “code id_token” Returns id_token from authorization endpoint in addition to code Adds c_hash, enables verification you got the right code. Send code only to the token endpoint of the issuer to prevent IDP mix-up attack. You can also request a token, but why? Don’t ask for an access token unless you can answer that. (And please come see me after and tell me your use case…)
  • 17. Request Object or Request URI Prevents attacker from tampering with your request parameters. Examples of this attack are the Malicious Endpoint Attack and the IDP Confusion Attack Some OP’s may provide a Request URI endpoint, where the request can be registered (enables state and nonce to be dynamic)
  • 18. Distinct redirect_uri per OP Check to make sure the response was received at the endpoint intended for this issuer. Cross reference with the state and nonce
  • 19. Do you need to protect the id_token from the browser (hybrid flow)? Will a JWT be passed to parties that you don’t want to see it? id_token_encrypted_response_alg id_token_encrypted_response_enc userinfo_encrypted_response_alg Userinfo_encrypted_response_enc Do you want to protect the request from the browser? request_object_encryption_alg request_object_encryption_enc Encryption
  • 20. PKCE Use for all public clients to prevent Authorization Code Interception Attack Require this if third parties use your OP from mobile apps Use SHA 256 as the code challenge method
  • 21. Mutual TLS Protection for the token endpoint TLS 1.2 or later as defined in RFC 5246 following best practices from RFC 7525. IETF Draft: “Mutual TLS Profiles for OAuth Clients” https://tools.ietf.org/html/draft-campbell-oauth-mtls-01
  • 22. Token Binding to TLS TLS Channel 1 TLS Channel 2 OAuth 2.0 Token Binding: add SH256 hash of TLS Channel ID to id_token
  • 23. Specifying ACR (authn context class reference) acr_values param can be sent in the OpenID Connect authentication request default_acr_values can be registered for a client Verify id_token for acceptable acr claim RECOMMENDATION: Use FIDO U2F USB tokens to prevent MITM attacks--authentication stops if the browser and server are not directly connected!
  • 24. Crypto guidelines RSA keys with a minimum 2048 bits if using RSA cryptography; Elliptic Curve keys with a minimum of 160 bits if using Elliptic Curve cryptography Client secret should have a minimum of 128 bits if using symmetric key cryptography Sign with PS256 (RSASSA-PSS using SHA-256 and MGF1 with SHA-256) or ES256 (ECDSA using P-256 and SHA-256)
  • 25. Trust: how do I know the public key is authentic? OpenID Connect Federation Draft Spec: http://openid.net/specs/openid-connect-federation-1_0.html Client can download the signing_keys ahead of time, or obtain them from a trusted source like a multi-party federation (check out Kantara OTTO…) Signature enables client to detect if jwks_uri is not authentic
  • 26. Software statements Restrict client registration... “JWT that asserts metadata values about the client software as a bundle” https://tools.ietf.org/html/rfc7591#section-2.3 Use OpenID Connect RP Metadata Statement as software statement during registration? Extra claims: scopes and claims Signed by federation
  • 27. OIDC Client Hall of Fame Mod_auth_openidc https://github.com/pingidentity/mod_auth_openidc OIDC-Client-JS https://github.com/IdentityModel/oidc-client-js OXD (Middleware) https://oxd.gluu.org App Auth (iOS / Android) https://github.com/openid Bias Warning… This is Gluu’s client software.
  • 28. THANK YOU! Questions? sales@gluu.org Schedule a follow up: https://gluu.org/booking Try OXD client software for free: https://oxd.gluu.org

Editor's Notes

  1. As many of you know, the Gluu Server is an OpenID Connect Provider. The nature of our business is that Gluu writes the server, and our customers write the Clients. One of the challenges we face (and worry about…), is that we can write a really good server, but if you don’t write the client correctly, what you get is not secure.
  2. Our industry has been really excellent at making up lots of jargon for roughly equivalent things… in this talk, I’m going to try to stick with User, Browser, Client and OP.
  3. This is an excellent diagram presented by Nat Sakimura at CIS last year. I don’t want to get you bogged down in the technical stuff (yet)... but what I want you to focus on is the fact that using OpenID Connect you can achieve different security levels. OpenID Connect was designed to make “Simple things Simple; Complex things Possible.” Depending on the transaction value, you can use OpenID Connect to mitigate varying levels of risk during authentication.
  4. Note: Implicit flow ain’t got not client creds… by definition a public client can’t protect them. So when you think back to the “Security Levels”... of course a confidential client is more secure.
  5. Note: private key client authentication doesn’t send the secret. Most commercial agents are doing the same for years.
  6. The main point is to send a state param, and check to verify it in the response. For more details, see Twobo’s blog.
  7. An id_token is very much like a SAML assertion. Instead of a signed XML, it’s a signed JSON. SAML assertions also contain the issuer, audience, subject, expiration and optionally, user claims.
  8. An id_token is very much like a SAML assertion. Instead of a signed XML, it’s a signed JSON. SAML assertions also contain the issuer, audience, subject, expiration and optionally, user claims.
  9. These are the clients that I recommend to developers