The document explores integrating OAuth and data access control into the Anypoint platform, emphasizing a zero-trust security model that prioritizes understanding and validating identities and contexts over traditional perimeter defense. It details the implementation of OAuth 2.0 and OpenID Connect for secure API communication, highlighting various authorization flows and the importance of scopes, claims, and token validation. Additionally, it discusses common pitfalls, lessons learned, and alternative security methods to enhance API protection.

1. Incorporating OAuth and data
access control into the
Anypoint Platform
Mike Moore
Customer Success Architect

2. All contents © MuleSoft Inc.
Modern Security Posture
2
● Security has changed from keeping the bad
guys out and the good guys in, to TRUST
NOBODY (zero-trust model). Insider
Threats are more prevalent than previously
understood
● Security by Obscurity is unacceptable.
Protection is about applying industry
standards across layers of security and
defense in depth (OWASP, SANS, NIST, PCI,
ISACA ISO27k)
● The strategy is no longer security by “no”, it
is now security by ”know”
https://www.business.com/articles/cybersecurity-
inside-outside-threats/

3. All contents © MuleSoft Inc.
What is Zero-Trust?
• Take a capabilities-led view
– Bounded domains and functions
– Targeted and focused protections
• Deploy a distributed enforcement model
– Protect both the front-end presentation layer and the back-end connectivity to the
data source
• Asset discovery
– Know and understand assets in use and their relationships
• Adopt a continuous approach
– Monitor and iterate, surface anomalies
• Provide verifiable identities to APIs and Consumers
– Grant access based on what we know about the caller and its context
• The client and the user context

4. All contents © MuleSoft Inc.
What is Zero-Trust?
• Take a capabilities-led view - API-Led // 3 Tier Architecture
– Bounded domains and functions
– Targeted and focused protections
• Deploy a distributed enforcement model - API Management // Last Mile
– Protect both the front-end presentation layer and the back-end connectivity to the
data source
• Asset discovery - Exchange // Visualizer
– Know and understand assets in use and their relationships
• Adopt a continuous approach - Visualizer // Monitoring
– Monitor and iterate, surface anomalies
• Provide verifiable identities to APIs and Consumers ??
– Grant access based on what we know about the caller and its context
• The client and the user context

5. All contents © MuleSoft Inc.
Some assembly required
5

6. All contents © MuleSoft Inc.
Different Layer with different security concerns
- Client Application must be
authorized to access the API
- Allow the user to authenticate
without sharing credentials to the
API/system
- Share user context and a revocable
access token
- APIs need to be identified and
authorized to call each other
- Cannot leverage the original end
user token
- Needs to authenticate headlessly
(No human interaction)
- Only serve data to approved API
clients
- Be able to validate the end user
and its context for data
filtering/masking or enrichment

7. All contents © MuleSoft Inc.
OAuth and OpenID Connect
7
• OAuth 2.0
– Delegated Auth
– Open framework for Authorization
– Does not define how to perform authentication
– Generic - open to interpretation
and implementation
• Flexible - IOT, API access
management, social media
• Can be used completely differently
across organizations
– Grant access to a client (application) to a resource by requesting
permissions from a 3rd party (IDP - Identity Provider)
– Contents and Structure of tokens are undefined by default
• OpenID Connect (OIDC)
– Extends OAuth 2 by adding a strict definition of tokens and user
authentication flows
– Adds Dynamic Client Registration - API Manager creates clients in the IDP

8. All contents © MuleSoft Inc.
OIDC Standards
8
• {{Auth-Provider-Base-Uri}}/.well-known/openid-configuration
– API Contract/Source of Truth for interacting with the IDP
• Platform bound to this contract
– Highly useful in troubleshooting interactions between Anypoint Platform and
the IDP
– Provides details on:
• Endpoints
– Authorize an application
– Obtain an access token
– Introspect/Validate an access token, ID token, or refresh token
– Register a client application
– Obtain user info
– Invalidate a session
• Grant Types
– How a Client Application will be Authorized and obtain an access token
• Supported Scopes and Claims

9. All contents © MuleSoft Inc.
OIDC/OAuth Standards
9
• Grant Types
– Authorization Code optionally with Proof Key for Code Exchange
• PKCE adds a code challenge/verifier during the Authorization code exchange for
Mobile/Single page apps where secrets may not be secure
• Allows user authentication and authorization directly with the IDP for the Client
App to obtain an access token on behalf of the user
• Credentials are not passed to the API/app
• Can support provide a refresh token
• Native and Web Apps can use Authorization Code Grant
– Can protect the client secret to the IDP
– Client Credentials
• Used for machine-to-machine or when the resource owner is not a person
• Credentials are exchanged with the IDP for an access token to call a downstream
API
– Implicit Grant
• Similar to Authorization Code but an access token is immediately passed back to
the client app
• Authorization Code with PKCE is recommended vs implicit

10. All contents © MuleSoft Inc.
OAuth - Authorization Code (delegated access)
10

11. All contents © MuleSoft Inc.
OAuth at the Experience/Edge
11

12. All contents © MuleSoft Inc.
OAuth - Authorization Code Grant
12
Client App
User Context
Scope of
Access and
Actions at a
domain

13. All contents © MuleSoft Inc.
OAuth Client Credentials (System to System)
13
Process API Identity
Provider
System API

14. All contents © MuleSoft Inc.
Access token validation policy
14
Optional!

15. All contents © MuleSoft Inc.
OIDC/OAuth Standards
15
• Scopes
– What information you can obtain or access about the authenticated user
– openid - required scope for OIDC clients
– Usually will be nouns and verbs that can map to API resources and methods
• accounts-read, orders-read, orders-write
• Claims
– Additional key/value pairs related to the user context
– Can be used for fine grained data access control/filtering
• Tokens
– Access Token
• Used to access a resource, possibly with a user context, and a specific set of
claims and scopes
• JWT - Signed or Unsigned, or Opaque Tokens
– ID Token
• Provides user context, claims and scopes
– Can be validated locally (JWT validation) or against the IDP introspection
endpoint (Opaque or JWT)

16. All contents © MuleSoft Inc.
Validating Tokens
16
• OpenID Connect Access Token Validation Policy
– Validates token in the Authorization header against the IDP (cannot reference a
different target)
– By default validates token issued to valid client app
• Can be disabled!
– Allows token to be validated by downstream API it was not issued for
– Expose Headers will make all claim/user info available to the API for RBAC/ABAC
• JWT Validation
– Locally validates the contents of the token against the configured policy and IDP
public key
– Can validate token was issued to the expected client app/ID
– Can validate custom claims against literals or DW expressions
• claim : vars.claimSet.claim == attributes.queryParams.claim
– Cannot be used if the IDP is issuing Opaque tokens
– Token can be encrypted, and signed (IDP configuration)
– Claim information passed to the API
#[authentication.properties.claims.<claimName>]

17. All contents © MuleSoft Inc.
Applying OAuth to all the layers
- Use Authorization Code Grant to
Authenticate the user directly to the IDP
and exchange an Authorization Code for an
Access token
- Access token Validation policy will
communicate and cache the IDP response
for the validity of the access token
- Optionally scopes and claims can be
extracted to headers for Experience or
downstream APIs
- Intra-VPC/Subnet API Calls can
leverage Client Credentials Grant
with OIDC Access Token
Enforcement Policy
- Client ID based policy enforcement
could be used for IDPs that do not
support Client Credentials Grant
(Not OAuth)
- RBAC or ABAC access control can
be enforced on any layer of API
- Customers may prefer at the
system API to avoid unnecessary
data transmission
- Extract user information from
Headers, ID Token, Access Token
via JWT validation or token
validation against IDP

18. Demo

19. All contents © MuleSoft Inc.
Pitfalls and Lessons learned
19
• Not even OIDC is consistent (Up to the IDP)
– +/- Dynamic Client Registration (OneLogin, Azure AD)
– +/- Support for Client Credentials Grants (Salesforce, Okta)
– Leverage what you can from OIDC and augment with other API Security controls
• Register system to system clients with Auth code grant types, but only use client
ID/secret policies, or add Client Credentials if supported
• Anypoint Platform depends on the well-known-configuration data
– You may have to build interactions directly to the IDP
– You may have to build custom validation policies
• Client Based policies can be driven by access token validation
– Reference #[authentication.principal]
• OAuth Spec has a gap that has not been addressed
– On-behalf-of tokens to allow systems to obtain tokens needed to fulfill an
experience call - In-draft
– Azure AD has implemented a flow to accomplish this
– Example presented today gets close

20. All contents © MuleSoft Inc.
Other Security methods
20
• Client ID/Secret
– Similar to client credentials grant
– Client ID/Secret validated by Anypoint Platform rather than an access token
from the IDP
• Basic Auth
– Delegate authentication to the service implementation using client
credentials
• SAML Token
• Additional security measures
– Two way SSL
– IP Filtering
– JSON/XML threat protection
– Rate limiting, throttling, spike arrests

21. Thank you

22. All contents © MuleSoft Inc.
Securing APIs using OAuth 2.0
22
OOTB Token validation policies with OpenID Connect, PingFederate and
OpenAM.

23. All contents © MuleSoft Inc.
Policies
23

24. All contents © MuleSoft Inc.
External Identity configuration
24

25. All contents © MuleSoft Inc.
External Identity - SAML 2.0
25

26. All contents © MuleSoft Inc.
External Identity - Client Management
26