Ed Olson-Morgan (he/his), Tuesday March 14th 2023
OAuth, OIDC and protecting
third party credentials
APIsecure 2023

Photo by Danil Aksenov on Unsplash

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

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

Our business problem

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

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

• 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

• 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

Credential abstraction

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

• 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

• 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

• 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

• 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

• 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

Improving our authentication
approach

• OAuth is not an authentication standard
- but it does suggest authentication
methods to use (https://www.rfc-
editor.org/rfc/rfc6749#section-2.3.1)
• 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

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

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

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

• 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

For our purposes, we made the tradeoff
to use client_secret_jwt as it was easier
for clients to build into their applications

Some implementation details

• 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

From this …
… to this

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

Client support
We have sample libraries available in common languages to support adoption

• 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

Putting it all together

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

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 @ wocintechchat.com on Unsplash

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

What comes next?

• 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

• 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

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 (https://www.jvt.me/posts/2021/11/09/avoid-client-secret/) 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