This document provides an overview of OAuth 2.0 and how it can be used to securely authorize access to APIs from mobile applications. It begins with an introduction to OAuth and discusses how it addresses issues with directly sharing passwords between applications. The document then outlines the basic OAuth flow, including key concepts like access tokens, authorization codes, and refresh tokens. It provides code snippets demonstrating an example OAuth flow for both Android and iOS, showing the HTTP requests and responses at each step.
Unraveling Multimodality with Large Language Models.pdf
OAuth 2.0 and Mobile Devices: Is that a token in your phone in your pocket or are you just glad to see me?
1. 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
2. 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
3. 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.
4. 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…
5. 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?
6. 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
7. 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)
8. 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
9. 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
10. 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…
11. 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
12. 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
13. 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
14. 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.
15. 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
16. 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]];
17. 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
18. Cloud!
Approve Token
Endpoint
Authorization
Endpoint
User approves the requested access
2
Device
Browser
Native
App
19. 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
23. 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);
25. 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
26. 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