OAuth 2.0 and Mobile Devices: Is that a token in your phone in your pocket or are you just glad to see me?

Is that a token in your phone in your pocket or are you just glad to see me?(the presentation formerly known as Securing Your Pocket to the Cloud) OAuth 2.0 and Mobile Devices Brian Campbell @weeUnquietMind

Agenda Intro Quick overview of OAuth Social logins, mobile apps, the problem and how OAuth can help An abstract OAuth exchange and some terminology A detailed OAuth flow with a mobile client  HTTP exchanges  Code and configuration snippets for Android and iOS Q&A

Who the hell is this guy anyway? @weeUnquietMindAs Senior Architect for Ping Identity, Brian Campbell aspires toone day know what a Senior Architect actually does for a living. Inthe meantime, he tries to make himself useful byideating, designing and building software systems such as Ping‟sflagship product PingFederate. When not making himselfuseful, he contributes to various identity and security standardsincluding a two-year stint as co-chair of the OASIS SecurityServices Technical Committee and a current focus on OAuth 2.0and JOSE within the IETF. He holds a B.A., magna cum laude, inComputer Science from Amherst College in Massachusetts.Despite spending four years in the state, he has to look up how tospell "Massachusetts" every time he writes it.

Disclaimer & Credits I primarily do server side development Some content and jokes were “borrowed” from my esteemed colleague, Dr. Paul Madsen  Because “plagiarism” is such a nasty word Quick Reference  Any content you find humorous or insightful is mine  If you think something‟s dumb and/or you‟re offended by it, it‟s Paul‟s  Hate mail to @paulmadsen Also thanks to Scott Tomilson for many examples  He needs more followers @scotttomilson  As do I…

Bad Idea Jeans ESPN and Facebook are offering to import your friends email addresses from your web email provider. How nice! And all you have to give them is your username and password. •What could possibly go wrong?

Why so bad? (The Password Sharing Anti-Pattern) Requesting sites and apps store the passwords Hosting sites get locked into password authentication Users get trained to be indiscriminate with their passwords The hosting site is not involved in the authorization step No support for granular permissions No easy way to revoke access Changing password (good security hygiene) revokes access to all

Enter OAuth Delegated authorization protocol  Mitigates password anti-pattern  Web and Native OAuth is your valet key to the Interwebs  (Anyone actually drive a car with a valet key?) Standard way to provide a „key‟ to a third-party which allows only limited access to perform specific functions  Without divulging credentials to the third-party  Access grant is revocable  Scope of the access grant can be constrained An open protocol to allow secure API authorization in a simple and standard method from desktop, mobile and web applications. An authorization & authentication framework for RESTful APIs (& more)

Some Historical Context Proprietary Solutions  Google AuthSub, AOL OpenAuth, Yahoo BBAuth, Upcoming API, Flickr API, AWS API, and more OAuth 1.0 in late 2007 Informational RFC 5849 in mid 2010 OAuth WRAP (Web Resource Authorization Profiles) also in 2010 OAuth 2.0 in the final stages of IETF standardization

Premise: All the Cool Sites are Doing It• Social Logins • Less friction • Better conversion rates • Outsources authentication and (some) security • Starting to become a user expectation• Mobile Apps • You‟re at Gluecon so you may have already gotten the memo that mobility is a thing • Anyone heard of this Instagram thing? • Damn kids today! • No distinction: computing is mobile • BYMODD

Social & Mobile - So What? Back in the day, your mobile app could collect a username and password and then access protected APIs using HTTP Basic Authentication But what if you‟re relying on Facebook, Twitter, Google, Yahoo, etc. to authenticate your users? You could…  or not…

OAuth Can Help OAuth offers a standard way to use social logins with mobile applications Leverage existing (and future) investment in browser based authentication for use with mobile applications

Aside: Mobile Application Continuum Web Applications Native ApplicationsWeb Server Web Server Web App HTML/JS/CSS Hybrid Approaches JSON/XMLMobile Device Mobile Device Mobile Web Page Native App Browser

Skinning the Cat Open source libraries Commercial solutions Android Account Manager Do It Yourself Examples herein are DIY and native  Completeness, timeliness, neutrality  One stated design goal for OAuth v2.0 was simplification of the client

Basic Abstract Flow client: An application Authorization obtaining authorization and Server making protected resource Client requests. Resource  Native app on mobile device Server resource server (RS): A server capable of accepting and responding to protected A few other protocol terms resource requests. • Access token (AT) – Presented by client when accessed protected resources at the RS  Protected APIs • Refresh token (RT) - Allows clients to obtain a fresh authorization server (AS): A access token without re-obtaining authorization • Scope – A permission (or set of permissions) defined server capable of issuing by the AS/RS tokens after successfully • Authorization endpoint – used by the client to obtain authenticating the resource authorization from the resource owner via user-agent owner and obtaining redirection • Token endpoint – used for direct client to AS authorization. communication • Authorization Code – One time code issued by an AS to be exchanged for an AT.

Concrete Flow① Client app initiates Cloud! authorization request Authorization② End-user authenticates Token Endpoint Endpoint and approves the requested access③ Server returns control to the app and includes an authorization code 3④ The authorization code is 1 2 traded for access token 4 (and refresh token) 5 Device⑤ Protected APIs invoked using the access token Browser Native 1 App 3

Cloud! Request Authorization Token Authorization Endpoint Endpoint  When user first needs to access some protected resource, client opens a browser and 1 sends user to the authorization endpoint Devicehttps://as.example.com/as/authorization.oauth2?client_id=myapp&response_type Browser=code&scope=update_status Native 1 AppUri authzUrl =Uri.parse("https://as.example.com/as/authorization.oauth2?client_id=myapp&response_type=code&scope=update_status");Intent launchBrowser = new Intent(Intent.ACTION_VIEW, authzUrl);startActivity(launchBrowser);NSString* launchUrl =@"https://as.example.com/as/authorization.oauth2?client_id=myapp&response_type=code&scope=update_status";[[UIApplication sharedApplication] openURL:[NSURL URLWithString: launchUrl]];

Cloud! Authenticate and Approve Token Endpoint Authorization Endpoint The AS authenticates the user  Directly  Indirectly via Facebook, Twitter, Google, Yahoo, etc. 2 Device Browser Native App

Cloud! Approve Token Endpoint Authorization Endpoint User approves the requested access 2 Device Browser Native App

Cloud! Handle Callback Token Authorization Endpoint Endpoint 3 DeviceServer returns control to the app via HTTP Browserredirection and includes an authorization code Native AppHTTP/1.1 302 FoundLocation: x-com.mycorp.myapp://oauth.callback?code=SplxlOBeZQQYbYS6WxSbIA

Cloud! Handle Callback (cont‟d) Token Authorization Endpoint Endpoint Registering a custom URI schemeIn AndroidManifest.xml file: Device<activity android:name=".MyAppCallback” … ><intent-filter> Browser Native <action android:name="android.intent.action.VIEW"/> App 3 <category android:name="android.intent.category.DEFAULT"/> <category android:name="android.intent.category.BROWSABLE"/> <data android:scheme="x-com.mycorp.myapp" /></intent-filter></activity>String authzCode = getIntent().getData().getQueryParameter("code");

Cloud! Handle Callback (cont‟d) Token Authorization Endpoint Endpoint Registering a custom URI scheme In app info plist file: Device Browser Native App 3- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url{ NSString *queryString = [url query]; NSMutableDictionary *qsParms = [[NSMutableDictionary alloc] init]; for (NSString *param in [queryString componentsSeparatedByString:@"&"]) { NSArray *elts = [param componentsSeparatedByString:@"="]; if([elts count] < 2) continue; [qsParms setObject:[elts objectAtIndex:1] forKey:[elts objectAtIndex:0]]; }; NSString *code = [qsParms objectForKey:@"code"];...

Cloud! Trade Code for Token(s) Token Authorization Endpoint Endpoint Token Endpoint RequestPOST /as/token.oauth2 HTTP/1.1Host: as.example.com 4Content-Type: application/x-www-form-urlencoded;charset=UTF-8 Deviceclient_id=myapp&grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA Browser Native App Token Endpoint ResponseHTTP/1.1 200 OKContent-Type: application/json;charset=UTF-8Cache-Control: no-storePragma: no-cache{ "token_type":"Bearer", "expires_in":3600, "access_token":"PeRTSD9RQrbiuoaHVPxV41MzW1qS”, "refresh_token":"uyAVrtyLZ2qPzI8rQ5UUTckCdGaJsz8XE8S58ecnt8”}

Cloud! Using an Access Token Token Endpoint Authorization Endpoint  Once an access token is obtained, it can be used to authenticate/authorize calls to the protected resources at the RS by including it in HTTP Authorization header Device 5POST /api/update-status HTTP/1.1 BrowserHost: rs.example.com NativeAuthorization: Bearer PeRTSD9RQrbiuoaHVPxV41MzW1qS AppContent-Type: application/x-www-form-urlencoded;charset=UTF-8status=Almost%20done.NSString *authzHeader = [NSString stringWithFormat:@"Bearer %@", accessToken];NSMutableURLRequest *request = [[[NSMutableURLRequest alloc] init] autorelease];[request setURL:[NSURL URLWithString:@"https://rs.example.com/api/update-status"]];[request setValue:authzHeader forHTTPHeaderField:@"Authorization"];DefaultHttpClient httpClient = new DefaultHttpClient();HttpPost post = new HttpPost("https://rs.example.com/api/update-status");post.setHeader("Authorization", "Bearer " + accessToken);

If All Goes well, HTTP/1.1 200 OK

And If not, HTTP 401/403 Use refresh token to get a new access token POST /as/token.oauth2 HTTP/1.1 Host: as.example.com Content-Type: application/x-www-form-urlencoded;charset=UTF-8 grant_type=refresh_token&refresh_token=uyAVrtyLZ2qPzI8rQ5UUTckCdGaJsz8XE8S58ecnt8 HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "token_type":"Bearer", "expires_in":3600, "access_token":”G8RTS98dQ9CpLoaH7P3V41MzW1q0”, } And if that doesn‟t work, initiate the authorization request flow again

Thanks! (and time permitting) Questions?(there are no stupid questions, only stupid answers and I‟m tremendously qualified to deliver such answers) Brian Campbell @weeUnquietMind

http://storify.com	188
https://twitter.com	31
https://si0.twimg.com	1

OAuth 2.0 and Mobile Devices: Is that a token in your phone in your pocket or are you just glad to see me?

by Brian Campbell on May 23, 2012

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 220

Statistics

OAuth 2.0 and Mobile Devices: Is that a token in your phone in your pocket or are you just glad to see me? Presentation Transcript