• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
CIS 2012 - Going Mobile with PingFederate and OAuth 2

CIS 2012 - Going Mobile with PingFederate and OAuth 2



Slides from my session at CIS 2012 on Mobile, OAuth 2 and PingFederate

Slides from my session at CIS 2012 on Mobile, OAuth 2 and PingFederate



Total Views
Views on SlideShare
Embed Views



4 Embeds 34

https://twitter.com 21
https://si0.twimg.com 11
https://twimg0-a.akamaihd.net 1
http://www.slashdocs.com 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    CIS 2012 - Going Mobile with PingFederate and OAuth 2 CIS 2012 - Going Mobile with PingFederate and OAuth 2 Presentation Transcript

    • Going Mobile withPingFederate and OAuth 2Scott TomilsonTechnical Product ManagerPing Identity Copyright © 2012. Cloud Identity Summit. All Rights Reserved.
    • About me … "Who the heck is this guy? And why should I listen?"
    • About me … Scott Tomilson• "Inside" Technical Product Manager for PingFederate• Based in Vancouver, Canada• Spent majority of career in Japan & Australia• 12 years in Security / IdM• Engineer, Consultant, Trainer• CISSP photo kindly stolen from Brian D. Campbell
    • Going Mobile - PingFederate and OAuth 2• Agenda – OAuth 2 & You – "Hands-on" with the OAuth 2 Playground – Break (yay!) – Even more "Hands-on" work – Mobile Integration dive: iOS & Android – Wrap-up
    • OAUTH 2 & YOU
    • 5 reasons to love OAuth 2 (for Mobile) ?1. Youve got REST APIs, you want a standard way to secure them2. Your APIs / applications involve sensitive resources that either your organization or end users want to control access to3. Your API will be available to partner apps, but you still control user authentication4. You need revocation capabilities5. You / your company paid for this workshop – so, why the heck not!
    • Speaking OAuth 2 (i.e.: Terminology) "Actors" • Client - Wants access to a resource protected by a Resource Server and interacts with an Authorization Server to obtain tokens. • Resource Server (RS) - Hosts and protects resources and makes them available to properly authenticated and authorized clients. • Authorization Server (AS) - Issues access and refresh tokens to clients on behalf of RSs.
    • OAuth 2 Terminology (contd) Protocol Terms • Access token (AT) - Allows clients to authenticate to an RS and claim authorizations for accessing particular resources. Expires based on time (typically minutes). • Refresh token (RT) - Allows clients to obtain a fresh access token without re-obtaining authorization from the resource owner. Expires based on user revocation or time (typically days). • Authorization Code – One time code issued by an AS to be exchanged for an AT. • Scopes – A permission (or set of permissions) defined and agreed upon by the Client, RS and AS.
    • OAuth 2 Terminology (contd again) Protocol Terms (contd) • Grant Types - An authorization grant is a credential representing the resource owners authorization (to access its protected resources) used by the client to obtain an access token. Grant types dictate how the authorization grant is performed (and thus how the token is released). Examples: • Authorization Code • Implicit • Resource Owner Password Credentials
    • Authorization Code Grant1.) User accesses Native Mobile Application andrequests action. Action requires user authentication 2and/or authorization to the Resource Server (RS).2.) Native Application launches the devices browser 3and requests the Authorization Servers (AS) Authorization Serverauthorization endpoint 4 (PingFederate)(https://<pf>/as/authorization.oauth2). Requestquery string includes the OAuth client ID, requesttype and requested scopes.3.) User authenticates to Authorization Server (AS)via IdP Adapter, or IdP Connection. Afterauthentication user sees confirmation page withrequested scopes and clicks "Approve". 54.) AS redirects user back to the Native MobileApplication via a custom registered scheme Browser(protocol) that the application registered, andincludes an authorization code in the query string Resource Server(e.g.: partnerapp://callback?code=xxxxx). Native Mobile (REST API endpoint)5.) Native Mobile App resolves authorization code to Applicationa token (access token [and refresh token]) via RESTAPI call to the AS token endpoint(https://<pf>/as/token.oauth2). 1
    • Token [ Mobile Application Integration – Redirection Flow Native Refresh & ] Usage Token Refresh & Usage1.) User accesses Native Mobile Application and [3]requests action. Action requires userauthentication and/or authorization to theResource Server (RS).2.) Native Mobile Application checks if user has avalid (non-expired) access token. If none available Authorization Server 5(and a refresh token is available) a request to the (PingFederate)Authorization Server (AS) token endpoint(https://<pf>/as/token.oauth2) to obtain a newone. Browser3.) AS looks up refresh token in its persistent grantstorage, and if valid, issues a new access token (andpossibly refresh token). Native Mobile [2]4.) Native Mobile Application inserts the OAuthaccess token in an Authorization HTTP header Application(Bearer type), and makes the REST API call to theRS.5.) RS validates incoming access token with ASusing the token endpoint 4(https://</pf>/as/token.oauth2) with aPingFederate validation grant type. AS returns 1 Resource Servervalidation results including user attributes. (REST API endpoint)
    • Authorization Code Grant Mobile example demo…14 Copyright © 2011. Cloud Identity Summit. All Rights Reserved.
    • Authorization Code GrantProtocol DetailsRequest:https://as.pingidentity.com/as/authorization.oauth2?client_id=my_app_id&response_type=code ( Login … Authorize )Callback Response:HTTP/1.1 302 FoundLocation: my_app://app.myapp.com/oauth?code=SplxlOBeZQQYbYS6WxSbIA
    • Authorization Code GrantProtocol Details (contd)Request:POST /as/token.oauth2 HTTP/1.1Host: as.pingidentity.comContent-Type: application/x-www-form-urlencoded;charset=UTF-8grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIAResponse:HTTP/1.1 200 OKContent-Type: application/json;charset=UTF-8Cache-Control: no-storePragma: no-cache{"token_type":"Bearer","expires_in":60, "access_token":"PeRTSD9RQrbiuoaHVPxV41MzW1qS"}
    • Token UsageProtocol DetailsGET /some/api/call HTTP/1.1Host: rs.myapp.comAuthorization: Bearer PeRTSD9RQrbiuoaHVPxV41MzW1qS
    • Native Mobile Application Integration Getting a Token (cont’d) • Open browser to authorization endpoint sample code: - (IBAction)doAction:(id)sender { NSLog(@"About to open Safari to OAuth AS Authorization Endpoint..."); // In this example, use a named IDP connection for user authentication NSString* launchUrl = @"https://as.pingidentity.com/as/authorization.oauth2?client_id=mobileclient1&respons e_type=code&idp=partner:entity:id"; [[UIApplication sharedApplication] openURL:[NSURL URLWithString: launchUrl]]; }
    • Native Mobile Application Integration Getting a Token (cont’d) • Registering a custom URI scheme in iOS:
    • Native Mobile Application Integration Getting a Token (cont’d) • Handling parameters – sample code: // Parse of URL query string complete if (error != nil) { // Show error message to user } else { NSString *code = [qsParms objectForKey:@"code"]; // Form HTTP POST to resolve JSON structure NSString *post = [NSString stringWithFormat:@"grant_type=authorization_code&code=%@", code]; NSData *postData = [post dataUsingEncoding:NSASCIIStringEncoding allowLossyConversion:YES];
    • Native Mobile Application Integration Getting a Token (cont’d) • Handling parameters – sample code (contd): NSString *postLength = [NSString stringWithFormat:@"%d", [postData length]]; NSMutableURLRequest *request = [[[NSMutableURLRequest alloc] init] autorelease]; [request setURL:[NSURL URLWithString:@"https://as.idp.com/as/token.oauth2"]]; [request setHTTPMethod:@"POST"]; [request setValue:postLength forHTTPHeaderField:@"Content-Length"]; [request setValue:@"application/x-www-form-urlencoded" forHTTPHeaderField:@"Content-Type"]; [request setHTTPBody:postData]; NSURLConnection *conn=[[NSURLConnection alloc] initWithRequest:request delegate:self]; if (conn) { receivedData = [[NSMutableData data] retain]; } }
    • Native Mobile Application Integration Getting a Token (cont’d) • Handling parameters – sample code (contd): - (void)connectionDidFinishLoading:(NSURLConnection *)connection { // json-framework library: https://github.com/stig/json-framework/ SBJsonParser *jsonParser = [[SBJsonParser alloc] init]; NSString *aStr = [[NSString alloc] initWithData:receivedData encoding:NSASCIIStringEncoding]; NSString *accessToken = nil; NSString *refreshToken = nil; id object = [jsonParser objectWithString:aStr]; if (object) { NSLog(@"JSON parsed successfully."); if ([object isKindOfClass:[NSDictionary class]]) { NSDictionary *nsDict = (NSDictionary*)object; accessToken = [nsDict objectForKey:@"access_token"]; refreshToken = [nsDict objectForKey:@"refresh_token"]; }
    • Native Mobile Application Integration Using a Token (contd) • Sample code: // Form the Bearer token Authorization header NSString *authzHeader = [NSString stringWithFormat:@"Bearer %@", accessToken]; NSMutableURLRequest *request = [[[NSMutableURLRequest alloc] init] autorelease]; [request setURL:[NSURL URLWithString:@"https://rs.idp.com/msg/api"]]; [request setValue:authzHeader forHTTPHeaderField:@"Authorization"]; NSLog(@"Initiating URL connection to RS with access_token..."); NSURLConnection *conn=[[NSURLConnection alloc] initWithRequest:request delegate:self];
    • Grant Types for Mobile• "Using a Token" is easy (for Bearer)• "Getting a Token" requires decisions• Grant Types most applicable to mobile: – Authorization Code – Implicit – Resource Owner Password Credentials
    • Grant Types for Mobile Grant Type Authentication Authz Refresh Tokens Types of Apps Step Support?Authorization Browser based ✔ ✔ • 3rd Party AppCode • Trusted App using Web based AuthnImplicit Browser based ✔ ✖ • As above, but lives in browser; e.g.: JS appResource Application ✖ ✔ • Trusted App,Owner using onlyPassword username/passCredentials word Authn
    • RO Password Credentials Grant Type Mobile example demo…27 Copyright © 2011. Cloud Identity Summit. All Rights Reserved.
    • Comparison of Grant Types & Models Authorization Code ( Resource Owner Embedded browser) Credentials • No need to leave app context • Password shared with 3rd party • Application owns login UI • Enables SSO • Enables strong authn • AS owns login UI • Visual trust cues (SSL lock) • Authentication can leverage stored passwords • Authentication can leverage existing sessions Authorization Code ( Separate browser ) 28
    • One more thing … Client Authentication• So, yeah - what about Client Authn?• Possible additional security requirement before grant• Limited use for mobile / client side apps… 10.1. Client Authentication . . . The authorization server MUST NOT issue client passwords or other client credentials to native application or user-agent-based application clients for the purpose of client authentication. The authorization server MAY issue a client password or other credentials for a specific installation of a native application client on a specific device. . . . http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-10.1
    • Going Mobile - PingFederate and OAuth 2• Agenda – OAuth 2 & You – "Hands-on" with the OAuth 2 Playground – Break – Even more "Hands-on" work – Mobile Integration dive: iOS & Android – Wrap-up
    • PingFederate OAuth 2 Playground• Setup hands-on activity starts now!• On the USB thumb drives: – JDK 1.6 (for Windows - 32 and 64 bit) – PingFederate 6.8 (& trial license) – OAuth 2 Playground – LabReadme.pdf• Follow PDF instruction to set up the lab
    • Going Mobile withPingFederate and OAuth 2BreakBack @ 2:45PM sharp!
    • Going Mobile - PingFederate and OAuth 2• Agenda – OAuth 2 & You – "Hands-on" with the OAuth 2 Playground – Break – Even more "Hands-on" work – Mobile Integration dive: iOS & Android – Wrap-up
    • Hands-on Playground Fun1. Enable Refresh Token grant type and test it. As the end user, revoke the grant.2. Enable "Bypass" of Authorization for the Authorization Code use case. Test it.3. Add a callback Redirect URL scheme to be myapp://. Test it – using browser trace.4. Define additional users for Resource Owner Password Credentials Grant Type, and new AT user attribute for Department. Test it.
    • Mobile Integration DiveLets talk about the tricky bits:• Integration Approaches• Combining Native Apps and Browsers – Embedding vs. Invoking the Browser – Handling callbacks• Secure Token Handling• SSO Approaches
    • OAuth Mobile Integration Integration Approaches • DIY OAuth integration – Effort level is small(-ish). Examples are used in this presentation. Requires: • Launching the browser (externally or embedded) • Detecting callback from the browser • JSON response parsing • Secure token handling • OAuth Client Library – Provides the above functionality with a higher level of abstraction. E.g.: • Google Toolbox for Mac – OAuth 2 Controllers: http://code.google.com/p/gtm-oauth2/ 38
    • Embedding vs. Invoking the Browser Embedding Invoking (Android WebView / iOS UIWebView) (External Browser)Pros: Pros:• Seamless user experience • Full, trusted browser UI• More options for callback • Share existing authn sessions handling (e.g.: cookies, title) (WAM SSO)• Better for some MITM attacksCons: Cons:• May look suspect to savvy users • Different default browsers –• Doesnt share cookies custom scheme URIs may not be handled (Opera on Android)
    • Handling Callbacks – Embedded BrowserWays a native app could get the callback(authorization code):1. Cookies – Name of the cookie is agreed upon2. Window Title – Code is in the HTML <title> tag, which can be read by native app. • May be vulnerable to leaks if the website has cross-site scripting bugs.
    • Handling Callbacks – Invoked BrowserWays a native app could get the callback(authorization code):1. Custom URI Scheme – myapp://2. Registered Intent for Scheme/Host – https://oauthcallback.myapp.com/3. Registered Intent URI – intent:#Intent;action=com.myapp.OAUTH_C ALLBACK;S.code=1234512345;end4. Registered MIME Type
    • Handling Callbacks – Invoked Browser Examples walkthrough…
    • Secure Token Handling• TLS a must• Tokens only shared with required parties• Access tokens – Minimal scope – Typically short lived – (Transient) memory storage is common• Refresh tokens – More sensitive due to long lifetimes – Stored in persistent memory – Application responsible for preventing leakage to other apps (e.g.: local prefs, key store, etc.)
    • Secure Token Handling (contd) The vulnerability was caused by Face.com storing Facebook and Twitter OAuth tokens – unique authentication keys – on its servers in an insecure way that made them accessible to anyone, Soltani said. http://www.macworld.com.au/news/face-com-flaw-could-have-allowed-facebook-twitter-hijacking-59587/44 Copyright © 2011. Cloud Identity Summit. All Rights Reserved.
    • SSO Approaches• External Browser• Central App for Authentication & OAuth – Call out / Call back design required – e.g.: myauthapp://go?callclient=app1• Account Manager – Built in framework available in Android
    • Going Mobile with PingFederate• Takeaways: – OAuth 2 can help deter a variety of API security issues, primarily improving user trust – Protocol itself is easy – challenge is integration with existing systems & policies – Client toolkits may help you – but ultimately understanding the spec and its intentions will help ensure its implemented correctly
    • Going Mobile withPingFederate and OAuth 2Thanks!Scott Tomilsonstomilson@pingidentity.comTwitter: @scotttomilson