The document discusses the integration of API management with mobile app enablement, highlighting the importance of OAuth 2.0 for secure access control. It outlines various techniques for API discovery, developer onboarding, and mobile app registration, along with details on OAuth handshakes and token provisioning. The content also touches upon different authentication challenges and suggests a mobile control center app for managing permissions and device access.

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];
// ...

9. DIY - Complete OAuth handshake sample (iOS)
 Catch browser redirection back to the application
(BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
// extract code value from url
// exchange code for access token
NSMutableURLRequest *req = [[[NSMutableURLRequest alloc] init] autorelease];
[req setURL:[NSURL URLWithString:@"https://apis.my.org/oauth2/authorization"]];
[req setHTTPMethod:@"POST”];
[req setValue:@"application/x-www-form-urlencoded" forHTTPHeaderField:@"Content-
Type"];
NSString *postStr = [NSString
stringWithFormat:@"grant_type=authorization_code&code=%@", code];
NSData *postEncoded = [postStr dataUsingEncoding:NSASCIIStringEncoding
allowLossyConversion:YES];
[req setHTTPBody:postEncoded];
NSURLConnection *c=[[NSURLConnection alloc] initWithRequest:req delegate:self];
// parse json response, isolate access token, etc...
}

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

12. DIY - API consumption using access token
 Sample (iOS)
//Syntax is Authorization: Bearer [insert_token_here]
NSString *httpAutzHeaderValue = [NSString stringWithFormat:@"Bearer %@", token];
NSMutableURLRequest *req = [[[NSMutableURLRequest alloc] init] autorelease];
[req setValue:httpAutzHeaderValue forHTTPHeaderField:@"Authorization"];
[req setURL:[NSURL URLWithString:@"https://myapi/resource/foo"]];
NSURLConnection *conn=[[NSURLConnection alloc] initWithRequest:req
delegate:self];
//... Read response, etc

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