Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

The adoption of Mobile and Cloud applications drives API traffic across domains. OAuth 2.0 is being implemented in complex enterprise environments where new authorization endpoints are combined with various existing identity components, in various configurations.

Handshakes are federated to help provide a single sign-on experience across applications and enhance adoption. Mediation between tokens at the edge of each domain helps extend existing data to new channels. Core grant types, extension grant types, custom schemes, standards, patterns and use cases – let us count the ways in which API access control is applied.

This presentation will examine the role of API management infrastructure in API Security, API Access Control and API Federation and its interaction with enterprise infrastructure, social identity and application developers.

This is very similar to saml web browsersso except that there is no complex saml to parse and digital signatures to validate

25m

Show a domain of apps sharing a auth context in the form of a JWT issued from an openid connect handshake, then each app getting its own access token based on thatWeb-&gt;domain cookieMobile apps -&gt; a JWT stored in a shared keychain-&gt; ‘Mobile SSO’, ‘Layer 7 MAG”

23.
Nested handshakes
 When users interact with an authorization server, they need to
be authenticated
 What happens when the API provider wants to delegate
authentication to a social login/openid connect provider?
Username: _________
Password: _________ [Login]
Log in with [Google] [facebook] […]
23
API Security and Federation Patterns
Step 1
App wants to consume API
on behalf of user, redirects
to API provider’s
authorization server to get
back access token
app

24.
Nested handshakes
Step 2
User redirected to IdP of choice so that the first
authorization server gets an access token from the
2nd authorization server
app
Do you authorize app* to get basic info
about you?
Yes [x]
No [ ]
24
API Security and Federation Patterns

25.
Nested handshakes
Step 3
User redirected back, its identity now known to the
first authorization server, expresses consent.
Do you authorize app* to [scope] on
your behalf?
Yes [x]
No [ ]
25
API Security and Federation Patterns
app

34.
Fishing on mobile
 On the web, the user-agent is responsible for redirecting to
the callback address
– On the web, DNS resolves addresses and HTTPS validates server-side
trust
 With native mobile apps, each app registers its own URL
scheme instead
APPLE:
“If more than one third-party app registers to handle
the same URL scheme, there is currently no process
for determining which app will be given that scheme.
”
--link
34
API Security and Federation Patterns

35.
Public vs confidential clients
 It’s either confidential, or it isn’t
– Don’t ‘hide’ a secret on a public app
store or render on a web page
(badly hidden witch)
35
API Security and Federation Patterns

39.
MAC, is it really more secure?
 Pros
– Better protected against man-in-the-middle
– If a request is intercepted, no big deal
 Cons
– You have to keep two secrets safe on the server side (per client)
39
API Security and Federation Patterns