API Management and Mobile APP enablement

Francois LascellesChief ArchitectLayer 7 Technologies

Tom NeinhausConsultant

Enterprise API Management Drivers

Mobile APIs

Integration APIs

Public/private APIs

SAAS

Mobile apps

IAAS/PAAS

Developers

Subscribers

Mobile workforce (BYOD)

Partners

Web!

!

!

Enterprise APIs

Big!

API Management Scope

Discovery, documentation

Developer onboarding

API Delivery

Performance, scaling

Integration

Access control

SLA enforcement

Threat protection

Analytics

Monetization

Developer Portal

API Gateway

Developer

AppAPI

API Management Infrastructure

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

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

Anatomy of an OAuth handshake

Subscriber(resource owner)

OAuth Authorization Server

+access token

+autz code

This is a shared secret

Authorization endpoint

Token endpoint

Mobile App(client)

1

1

2

redire

ct

redirect

(authorization code grant type)

consent

…(but an ephemeral one)

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

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=[pluginAPIkeyhere]&response_type=code&redirect_uri=[myapp://something]"];

// open browser

[[UIApplication sharedApplication] openURL:url];

// ...

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...

}

Alternative handshakes (grant types)

Authorization code

Implicit

- Like autz code, but simpler

- No code, just an access token

Resource owner password credentials

- Client gets credentials from resource owner directly. No Redirection

- Mobile app controls user experience

- Mobile app must be trusted

Client credentials

- Simple, two way handshake

- Not for the typical mobile app

+access token

+access token

+access token

(what we saw so far)

Why exchange a secret with an OAuth authorization server in the first place?

A: In order to consume an APIOAuth Provider

OAuth Authorization Server

OAuth Resource ServerConsume REST API

With access token from handshake

API endpoint

access token -> app, user

Enforce access control policies

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

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?

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

Case study: iOS Keychain for Simplified Sign On

Copyright 2012, Eli Lilly and Company

Mobile Control Center Concept

L7 Control Center

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