Más contenido relacionado

Similar a APIsecure 2023 - OAuth, OIDC and protecting third-party credentials, Ed Olson Morgan (Marsh McLennan)(20)

Más de apidays(20)


APIsecure 2023 - OAuth, OIDC and protecting third-party credentials, Ed Olson Morgan (Marsh McLennan)

  1. Ed Olson-Morgan (he/his), Tuesday March 14th 2023 OAuth, OIDC and protecting third party credentials APIsecure 2023
  2. Photo by Danil Aksenov on Unsplash
  3. Ed Olson-Morgan • Engineer -> management consultant -> engineer • Part of the founding team of two digital consulting practices • ADAPT@Bain • Oliver Wyman Digital • Core API & Innovation Lead at Marsh McLennan since 2021 About me
  4. Agenda for today • Explain the business problem we’re trying to solve: protecting third party credentials when working with vendors and multiple development teams • Discuss the credential abstraction pattern and how it helps us here • Review some of the issues that came up and how OAuth / OIDC standards helped us solve them • Talk through some of the technical implementation details • Show how we put it all together to better protect our environments • Share what we’re looking at doing next
  5. Our business problem
  6. Who is Marsh McLennan? • Big, global professional services fi rm: insurance and reinsurance broking, human resources and bene fi ts consulting, management consulting • Celebrated 150th anniversary last year; over $20BB in revenue • Four main operating companies (Marsh, Mercer, Guy Carpenter, Oliver Wyman) • Central technology capability (MMC Tech) established in 2020; accelerate and standardize the adoption of technology throughout the business
  7. APIs are at the heart of our reuse strategy The “reuse taxonomy” • We build software for ourselves, our clients, our clients’ employees and our clients’ clients across multiple lines of business • Doing so e ff ectively requires focusing on solving the unique problems of each application and reusing common solutions everywhere else Templates Code snippets Libraries APIs Increasingly e ffi cient to reuse and maintain; decreased developer fl exibility
  8. • Part of reuse is also not creating things in the fi rst place: there are many technology areas that are not core to our business • As such, we partner with over a hundred SaaS providers (from household names like Microsoft and Docusign to boutique providers) to support our work • In most cases, this requires some form of shared trust (single-sign-on, shared credentials etc.) Working with SaaS partners Photo by Cytonn Photography on Unsplash
  9. • One particular challenge we face is sharing long-lived credentials with our vendors • This broadens the attack surface if these credentials are leaked or otherwise compromised • When these credentials are for another vendor / third-party (e.g. Microsoft Graph API), we also risk issues with security miscon fi guration or excessive authorization • We use credential abstraction patterns to reduce this risk Protecting our credentials Photo by Markus Winkler on Unsplash
  10. Credential abstraction
  11. Calling application Authentication service Intermediate proxy 1 Validate caller credentials Underlying service Obtain service credentials Rewrite URI 2 3 4 5 Communicate response 6 7 Credential abstraction: an overview
  12. • Using a credential abstraction pattern requires providing an alternative method for callers to authenticate themselves • Because these are typically service-to-service calls, we use the OAuth Client Credentials grant to generate short-lived tokens for the calling applications to use • We’ll come back to some of the challenges this posed later Authenticating the application Photo by Volodymyr Kondriianenko on Unsplash
  13. • The calling application then presents the short-lived credentials to the credential abstraction service • The abstraction service is then responsible for validating these with the issuer before allowing the call to proceed any further • When using OAuth, this should make a call back to the credential issuer to make sure that the provided credentials are still valid, rather than just validating the token using the provided signature Validating application credentials Photo by Levi Ventura on Unsplash
  14. • The abstraction service then reviews the request being made to the underlying service • Each calling application should be granted least-privilege permissions at the endpoint/method level • If this check is passed, the abstraction service then removes the credentials supplied by the application and replaces those with valid credentials for the underlying service • Where possible, these credentials should be application-speci fi c and tightly scoped Obtaining service credentials Photo by Maria Ziegler on Unsplash
  15. • The abstraction service then needs to re-write the URI so that the request can be passed onto the underlying service • This may also involve adding in incremental headers or other components (query parameters, message body elements etc.) needed to meet the requirements of the underlying service Rewrite the URI Photo by Luca Bravo on Unsplash
  16. • After the call has been made to the underlying service, the abstraction service needs to pass on the response • All secrets and sensitives still attached to the call should be removed prior to returning it to the calling application • Errors should be handled and replaced / masked where necessary Communicate the response Photo by Diana Light on Unsplash
  17. Improving our authentication approach
  18. • OAuth is not an authentication standard - but it does suggest authentication methods to use (https://www.rfc- • Over time, those have become ubiquitous - either using HTTP basic authentication methods or providing credentials in the body of a request • While the standard requires TLS, this becomes vulnerable to man-in-the- middle attacks, inadvertent logging, early TLS termination … OAuth 2.0
  19. to the rescue? • Section 9 of OIDC Core 1.0 lists out four recommended approaches for client authentication • The two methods from the OAuth standard, now called client_secret_basic and client_secret_post • Two new methods: client_secret_jwt and private_key_jwt • The two new methods no longer require sending your client secret as part of your token request OIDC Core 1.0
  20. Using symmetric secrets • The client_secret_jwt authentication approach is the simpler of the two options • Clients / calling applications are still given a client ID and client secret, but instead of providing those in the request, the calling application generates a JWT containing the client ID and signs it with the client secret • Because the authentication server has both of these elements, it can verify the JWT and then return a token if successful • The main downside here is that a shared secret is still required between the client and authentication server • This secret needs to be passed out of band between the two environments client_secret_jwt Photo by Robin Spielmann on Unsplash
  21. Using asymmetric keys • In private_key_jwt, the calling application uses asymmetric cryptography to protect the request instead • The calling application generates a key pair and signs the request with the private key • It then shares the public key with the API server • The API server can then use the public key to verify the signature • In addition, if the calling application shares a URL rather than the key itself, any updates required to the key pair are shared automatically private_key_jwt Photo by Johannes Ortner on Unsplash
  22. • Open ID Connect also provides lightweight guidance on how to handle custom claims in the auth request “The JWT MAY contain other Claims. Any Claims used that are not understood MUST be ignored.” • We implement this feature by embedding a list of authorized claims within the con fi guration of each calling application, and then embedding those in the returned token if they are found in the request Embedding custom claims Photo by Theodor Vasile on Unsplash
  23. For our purposes, we made the tradeoff to use client_secret_jwt as it was easier for clients to build into their applications
  24. Some implementation details
  25. • We use Apigee Hybrid as our API gateway, and this already served as our OAuth token issuer for machine-to-machine calls • Unfortunately Apigee’s standard policies only accommodated the older authentication approaches (client_secret_basic and client_secret_post) that we were trying to avoid Leveraging our API gateway Photo by Piyush Wadhwa on Unsplash • We decided to enhance the authentication components of our proxy so that it could validate and transform the call into a form that Apigee could then validate as standard
  26. From this … … to this
  27. Enhancements 1 2 3 The proxy extracts the supplied JWT from the request and decodes it to extract the client id from the token The proxy veri fi es the client ID is valid, looks up the corresponding client secret and uses that to verify the token’s signature The proxy then checks that the jti value supplied with the token is unique, and if so assigns the credentials to the request body
  28. Client support We have sample libraries available in common languages to support adoption
  29. • We implemented the remainder of the credential abstraction pattern inside of Apigee Hybrid as well, using it to validate the JWT, substitute in the credentials for the underlying service and do any rewriting of the URL that is required Applying credential abstraction Photo by Meghan Rodgers on Unsplash
  30. Putting it all together
  31. Example 1 • Third-party billing provider required ability to send e-mails and review e-mail inboxes for replies using Marsh McLennan identities • Implemented credential facade in front of Microsoft Graph APIs in Apigee Hybrid, using client_secret_jwt to authenticate request for OAuth Client Credentials token APAC healthcare provider Photo by Sincerely Media on Unsplash
  32. Example 2 • Third-party HR software required ability to send e-mails using Marsh McLennan identities • Implemented credential facade in front of Microsoft Graph APIs in Apigee Hybrid, using client_secret_jwt to authenticate request for OAuth Client Credentials token EMEA HR Vendor Photo by Christina @ on Unsplash
  33. Example 3 • Client bank had embedded Marsh digital broking services inside of a combined auto loan / insurance product • Implemented client_secret_jwt to authenticate request for OAuth Client Credentials token, using custom claims to provide additional veri fi ed data about the customer EMEA Bank Photo by Matthew Henry on Unsplash
  34. What comes next?
  35. • We still see private_key_jwt as the better of the two new methods provided by OIDC Core, and are looking to support key-pair signed tokens for auth credentials • We also want to create a signing infrastructure for our internal developers so that they don’t need to stand up their own capabilities and key management Adding private_key_jwt Photo by regularguy.eth on Unsplash
  36. • To date, we’ve been using common patterns to solve speci fi c client or internal challenges but not reusing the underlying code • We’re starting to see some shared patterns (such as the MS Graph API) that we think we can solve once for many users • This will involve moving towards increased con fi guration for each new application that is onboarded, rather than copies and customization Create standardized facades Photo by Mika Baumeister on Unsplash
  37. Thanks and acknowledgements • Core API team: Brian Geoghegan, Hugh Greenish, Arushi Goel, Susanne Hart and Kambui Nurse • MMC Enterprise Architecture: Richard Giles, Mike Coe, Jason Bent, Steve Mycock • MMC Information Security: Mike Nepomnyashy, Ben Cheng, AJ Colangelo, Mark Mittendorf • MMC Tech community: Ray Taylor, Thomas Siu • Jamie Tanna, whose blog ( set me o ff down this road • Apidays and APIsecure 2023 for having me here • All the artists on Unsplash who provided visuals for this talk