Layer 7's Chief Architect Francois Lascelles will be speaking at The Chicago Mobile Meetup Group's meeting on August 14. He will be discussing mobile apps and API Management. This is an informal professional group focused on developing relationships and fostering mobile technology innovation.
Powerpoint exploring the locations used in television show Time Clash
API Management and Mobile App Enablement
1. API Management and Mobile APP enablement
Francois Lascelles Tom Neinhaus
Chief Architect Consultant
Layer 7 Technologies
2. Enterprise API Management Drivers
Mobile workforce (BYOD)
Big! Developers
SAAS
Subscribers
Mobile apps
Web
!
Enterprise APIs
!
Partners Mobile APIs
! Integration APIs
Public/private APIs
IAAS/PAAS
3. API Management Scope
Developer
Developer Portal
API
App
API Gateway
API Management Infrastructure
Discovery, documentation Access control
Developer onboarding SLA enforcement
API Delivery Threat protection
Performance, scaling Analytics
Integration Monetization
4. API discovery and mobile APP registration
Developer portal
- Discover an API
- Try the API
- Register as a developer
- Register an application
- Get an API key
Demo
5. API access control
You got an API key, now what?
- An app is sometimes identified at runtime by including its API key in
a query parameter (that doesn’t count as access control)
- If you use an API key-style shared secrets how is it provisioned
(confidential vs public client)?
- Typically, the user of the mobile app is authenticated, not the app
itself
- Standard moving fwd: OAuth 2.0
- Multiple grant types possible
- Opaque, bearer tokens is the most common approach
6. Anatomy of an OAuth handshake
(authorization code grant type)
OAuth Authorization Server
Subscriber
(resource owner) consent
1
Authorization endpoint
1
+autz code
2 Token endpoint
Mobile App
(client) +access token
This is a shared secret
…(but an ephemeral one)
7. OAuth handshake from mobile APP
DIY
- Send user to OAuth AS by redirecting it via browser (embedded or not)
- Catch redirection coming back (tricky part)
- On iOS, you set a custom URL scheme for your project so that second redirection
flows through your app (myapp://something)
- Call token endpoint to exchange code for access token (depending on grant type)
- Parse response, extract access token
Libraries
- Libraries for specific API providers, LROAuth2,
https://github.com/nxtbgthng/OAuth2Client, …
1. Most libraries don’t support redirect flows and expect the app to get the secret
from the user (ropc grant type?)
2. Some of these support an earlier draft. OAuth 2.0 has been a moving target
3. Not enough control on scope
8. DIY - Initiate OAuth handshake sample (iOS)
Redirect the end user to grant authorization on OAuth provider
// construct URL for sending user to authorization server
NSURL *url = [NSURL
URLWithString:@"https://apis.my.org/oauth2/authorization?client_id=[pluginAPIk
eyhere]&response_type=code&redirect_uri=[myapp://something]"];
// open browser
[[UIApplication sharedApplication] openURL:url];
// ...
10. Alternative handshakes (grant types)
Authorization code (what we saw so far)
Implicit
+access token
- Like autz code, but simpler
- No code, just an access token
Resource owner password credentials
- Client gets credentials from resource owner
+access token
directly. No Redirection
- Mobile app controls user experience
- Mobile app must be trusted
Client credentials
- Simple, two way handshake +access token
- Not for the typical mobile app
11. Why exchange a secret with an OAuth authorization
server in the first place?
OAuth Provider
A: In order to consume an API
OAuth Authorization Server
Consume REST API
OAuth Resource Server
With access token from handshake
API endpoint
access token -> app, user
Enforce access control policies
13. App and device authentication challenge with mobile
apps
Access token are potentially associated with 3 levels of identity:
- App
- User
- Device
How can each identity be verified at handshake time?
- User: authentication at AS
- App, Device
- Keystore for SSL mutual authentication?
- Shared secret provisioned through private app store?
Is it enough for app and device to be ‘asserted’ by user?
14. Patterns for token provisioning to APPs
Each app does its own
- Each app does its own handshake and manages it’s own oauth access token
- This is facilitated through a library
- Shared OAuth authorization server address through keychain group
Shared token
- Control center app does the handshake, shared token
- Token shared using Keychain access group (iOS)
- Disadvantage: no way to distinguish between apps at api provider side
Native app redirection social-login style
- Each app leverages a specialized app to facilitate the handshake instead of
redirecting through mobile browser
- Specialized app has private key provisioned to
15. Case study: iOS Keychain for Simplified Sign On
Copyright 2012, Eli Lilly and Company
16. Mobile Control Center Concept
Mobile ‘control center’ app as an
extension to API Management
infrastructure
- PKI provisioning
- Authorize/revoke
devices, apps (built-in api)
- Control permissions from any
device for easy revocation by
user
- Enterprise Notifications
- Enterprise App Store
L7 Control Center