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?
@weeUnquietMind

As Senior Architect for Ping Identity, Brian Campbell aspires to
one day know what a Senior Architect actually does for a living. In
the meantime, he tries to make himself useful by
ideating, designing and building software systems such as Ping‟s
flagship product PingFederate. When not making himself
useful, he contributes to various identity and security standards
including a two-year stint as co-chair of the OASIS Security
Services Technical Committee and a current focus on OAuth 2.0
and JOSE within the IETF. He holds a B.A., magna cum laude, in
Computer Science from Amherst College in Massachusetts.
Despite spending four years in the state, he has to look up how to
spell "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 Applications
Web Server
Web Server

Web App

HTML/JS/CSS Hybrid Approaches JSON/XML

Mobile 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
Device
https://as.example.com/as/authorization.oauth2?client_id=myapp&response_type
Browser
=code&scope=update_status
Native
1
App

Uri authzUrl =
Uri.parse("https://as.example.com/as/authorization.oauth2?client_id=myapp&response_type=code&scope=update_st
atus");
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

Device
Server returns control to the app via HTTP
Browser
redirection and includes an authorization code Native
App

HTTP/1.1 302 Found
Location: x-com.mycorp.myapp://oauth.callback?code=SplxlOBeZQQYbYS6WxSbIA

Cloud!

Handle Callback (cont‟d) Token Authorization
Endpoint Endpoint
Registering a custom URI scheme

In 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 Request
POST /as/token.oauth2 HTTP/1.1
Host: as.example.com
4
Content-Type: application/x-www-form-urlencoded;charset=UTF-8 Device

client_id=myapp&grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
Browser
Native
App

Token Endpoint Response
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":"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 5

POST /api/update-status HTTP/1.1 Browser
Host: rs.example.com Native
Authorization: Bearer PeRTSD9RQrbiuoaHVPxV41MzW1qS App
Content-Type: application/x-www-form-urlencoded;charset=UTF-8

status=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

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

Recommended

More Related Content

What's hot

What's hot (20)

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

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

More from Brian Campbell

More from Brian Campbell (17)

Recently uploaded

Recently uploaded (20)

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