API Management and Mobile App Enablement


Published on

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.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

API Management and Mobile App Enablement

  1. 1. API Management and Mobile APP enablement Francois Lascelles Tom Neinhaus Chief Architect Consultant Layer 7 Technologies
  2. 2. Enterprise API Management Drivers Mobile workforce (BYOD) Big! Developers SAASSubscribers Mobile apps Web ! Enterprise APIs ! Partners  Mobile APIs !  Integration APIs  Public/private APIs IAAS/PAAS
  3. 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. 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. 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. 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. 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. 8. DIY - Initiate OAuth handshake sample (iOS) Redirect the end user to grant authorization on OAuth provider// construct URL for sending user to authorization serverNSURL *url = [NSURLURLWithString:@"https://apis.my.org/oauth2/authorization?client_id=[pluginAPIkeyhere]&response_type=code&redirect_uri=[myapp://something]"];// open browser[[UIApplication sharedApplication] openURL:url];// ...
  9. 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 = [NSStringstringWithFormat:@"grant_type=authorization_code&code=%@", code]; NSData *postEncoded = [postStr dataUsingEncoding:NSASCIIStringEncodingallowLossyConversion:YES]; [req setHTTPBody:postEncoded]; NSURLConnection *c=[[NSURLConnection alloc] initWithRequest:req delegate:self]; // parse json response, isolate access token, etc...}
  10. 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. 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. 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:reqdelegate:self];//... Read response, etc
  13. 13. App and device authentication challenge with mobileapps 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. 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. 15. Case study: iOS Keychain for Simplified Sign On Copyright 2012, Eli Lilly and Company
  16. 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