Downloaded 36 times
Uploaded byMike Schwartz
The Client is not always right! How to secure OAuth authentication from your app.
The document discusses various security considerations and best practices for implementing OpenID Connect and OAuth 2.0, including client authentication methods, token validation, and state management to prevent vulnerabilities such as CSRF. It emphasizes the importance of cryptographic measures, proper handling of tokens, and maintaining client hygiene to ensure secure identity management. Additionally, it highlights the significance of mutual TLS and secure coding practices for protecting sensitive user data in client-server interactions.
More Related Content
Similar to The Client is not always right! How to secure OAuth authentication from your app.
![OpenID Connect - a simple[sic] single sign-on & identity layer on top of OAut...](https://cdn.slidesharecdn.com/ss_thumbnails/gluecon2014-oidc-140521065808-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
The Client is not always right! How to secure OAuth authentication from your app.
- 1. The Client isnot always right! Michael Schwartz, CEO Gluu
- 2.
- 3.
- 4. User Agent, UA, Browser Client, RelyingParty, 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 tokenfront channel token public clientConfidential client
- 7.
- 8. No access tokensas 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 clientcreds 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 thesignature! 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- Maybeyou 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’sGuides Basic Client: http://openid.net/specs/openid-connect-basic-1_0.html Implicit Client http://openid.net/specs/openid-connect-implicit-1_0.html
- 15.
- 16. Hybrid Flow “response_type”: “codeid_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 orRequest 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 perOP 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 needto 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 allpublic 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 forthe 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 toTLS TLS Channel 1 TLS Channel 2 OAuth 2.0 Token Binding: add SH256 hash of TLS Channel ID to id_token
- 23. Specifying ACR (authncontext 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 keyswith 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 doI 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 clientregistration... “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 Hallof 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 Schedulea follow up: https://gluu.org/booking Try OXD client software for free: https://oxd.gluu.org
Editor's Notes
- #3 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.
- #5 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.
- #6 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.
- #7 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.
- #10 Note: private key client authentication doesn’t send the secret. Most commercial agents are doing the same for years.
- #11 The main point is to send a state param, and check to verify it in the response. For more details, see Twobo’s blog.
- #12 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.
- #14 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.
- #28 These are the clients that I recommend to developers