3. About me …
"Who the heck is
this guy?
And why should I
listen?"
4. 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
5. 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
7. 5 reasons to love OAuth 2 (for Mobile) ?
1. You've got REST API's, you want a standard
way to secure them
2. Your API's / applications involve sensitive
resources that either your organization or
end users want to control access to
3. Your API will be available to partner
apps, but you still control user authentication
4. You need revocation capabilities
5. You / your company paid for this workshop –
so, why the heck not!
8. 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 RS's.
9. OAuth 2 Terminology (cont'd)
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.
10. OAuth 2 Terminology (cont'd again)
Protocol Terms (cont'd)
• Grant Types - An authorization grant is a credential representing
the resource owner's 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
12. Authorization Code Grant
1.) User accesses Native Mobile Application and
requests action. Action requires user authentication 2
and/or authorization to the Resource Server (RS).
2.) Native Application launches the device's browser 3
and requests the Authorization Server's (AS) Authorization Server
authorization endpoint 4 (PingFederate)
(https://<pf>/as/authorization.oauth2). Request
query string includes the OAuth client ID, request
type and requested scopes.
3.) User authenticates to Authorization Server (AS)
via IdP Adapter, or IdP Connection. After
authentication user sees confirmation page with
requested scopes and clicks "Approve".
5
4.) AS redirects user back to the Native Mobile
Application via a custom registered scheme Browser
(protocol) that the application registered, and
includes 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 Application
a token (access token [and refresh token]) via REST
API call to the AS token endpoint
(https://<pf>/as/token.oauth2).
1
13. Token [ Mobile Application Integration – Redirection Flow
Native Refresh & ] Usage
Token Refresh & Usage
1.) User accesses Native Mobile Application and
[3]
requests action. Action requires user
authentication and/or authorization to the
Resource Server (RS).
2.) Native Mobile Application checks if user has a
valid (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 new
one.
Browser
3.) AS looks up refresh token in its persistent grant
storage, and if valid, issues a new access token (and
possibly refresh token).
Native Mobile [2]
4.) Native Mobile Application inserts the OAuth
access token in an Authorization HTTP header Application
(Bearer type), and makes the REST API call to the
RS.
5.) RS validates incoming access token with AS
using the token endpoint 4
(https://</pf>/as/token.oauth2) with a
PingFederate validation grant type. AS returns 1 Resource Server
validation results including user attributes.
(REST API endpoint)
18. 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]];
}
19. Native Mobile Application Integration
Getting a Token (cont’d)
• Registering a custom URI scheme in iOS:
20. 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];
25. 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
26. Grant Types for Mobile
Grant Type Authentication Authz Refresh Tokens Types of Apps
Step Support?
Authorization Browser based ✔ ✔ • 3rd Party App
Code • Trusted App
using Web
based Authn
Implicit Browser based ✔ ✖ • As above, but
lives in browser;
e.g.: JS app
Resource Application ✖ ✔ • Trusted App,
Owner using only
Password username/pass
Credentials word Authn
28. 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
29. 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
30. 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
32. 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
34. 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
35. Hands-on Playground Fun
1. 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.
37. Mobile Integration Dive
Let's talk about the tricky bits:
• Integration Approaches
• Combining Native Apps and Browsers
– Embedding vs. Invoking the Browser
– Handling callbacks
• Secure Token Handling
• SSO Approaches
38. 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
39. 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 attacks
Cons: Cons:
• May look suspect to savvy users • Different default browsers –
• Doesn't share cookies custom scheme URI's may not
be handled (Opera on Android)
40. Handling Callbacks – Embedded Browser
Ways a native app could get the callback
(authorization code):
1. Cookies – Name of the cookie is agreed
upon
2. 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.
41. Handling Callbacks – Invoked Browser
Ways 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;end
4. Registered MIME Type
43. 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.)
45. 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
47. 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 it's implemented correctly
