The document discusses securing APIs using OAuth 2.0. It begins by describing some of the issues with early methods of API access that involved directly sharing usernames and passwords. It then provides an overview of how OAuth addresses these issues by allowing users to authorize API clients to access specific resources without sharing credentials. The key stages of the OAuth authorization code and token flows are described, including how tokens are used to make API requests. The document also covers some additional OAuth topics like JSON Web Tokens, other grant types, and some limitations and challenges with OAuth. In closing, it invites any questions or comments.

1. 1
SecuringAPIsusingOAuth
Adam Lewis – Motorola Solutions – Chief Technology Office
Securing APIs using OAuth 2.0

2. SecuringAPIsusingOAuth2.0
Source: ProgrammableWeb.com
http://www.programmableweb.com/news/which-apis-are-handling-billions-requests-day/2012/05/23

3. 3
SecuringAPIsusingOAuth
Source: ProgrammableWeb.com
Growth of APIs

4. 4
SecuringAPIsusingOAuth
Most of these APIs will need to know some very
fundamental things: who is the user of the API, and what
are they authorized to do?

5. 5
SecuringAPIsusingOAuth
In the Beginning …
I have an APII would like to use your API to get access
to my user’s protected resources
I cannot just give you that information.
To prove that user really wants to you
To access their information, I need their
username & password
Please give me your username & password
so that I can access your resources on your behalf
Here is my username & password
(Please be good with it)
webapp

6. 6
SecuringAPIsusingOAuth
And that was bad. Bad. BAD.
(very bad!)

7. 7
SecuringAPIsusingOAuth
The Password “anti-pattern”
Users became promiscuous
with their passwords, handing
them over directly to any API
client that asked for them
Client might not be trustworthy
Even if the client is trustworthy, it might not be
secure and might inadvertently leak the user’s
password or be otherwise prone to attack
If a password is
compromised, or if the client
was rogue to begin with, then
the only way to revoke that
client’s ability to access the
user’s resources would be for
the user to change their
password
And because many other clients
have also stored the user’s password
to access other resource on behalf of
the user, those clients also lose their
ability to access resources.
Finally, giving a third party client access to primary credentials enables the
client to access ALL of user’s information, rather than just a scope of it. For
example, a user might wish to allow a third-party client to access their
Facebook photos, but not to access their Facebook posts. Or they might allow
the client to read their posts, but not make posts on their behalf.

8. 8
SecuringAPIsusingOAuth

9. 9
SecuringAPIsusingOAuth
Defined by the IETF
There was a version 1.0 before it
– But it required client-side crypto,
developers didn’t like it
– 2.0 takes community feedback into account
(more on that later)

10. 10
SecuringAPIsusingOAuth
OAuth gives the user the ability to delegate an authorization
decision to an API client to access their protected resources
without divulging their credentials to that API client
Upon granting the API client authorization, the API client is
issued an access token, representing scope of that
authorization
Both API clients and API servers are abstracted from
requiring a password (really BIG deal!)

11. 11
SecuringAPIsusingOAuth
Client
Resource Server
Authorization
Endpoint
Token
Endpoint
UA
Authorization Server
End User
(possibly RO)

12. 12
SecuringAPIsusingOAuth
User logs into web page
Redirect user’s browser to authorization endpoint
OAuth Authorization Request (requested scope of authorization)
User Authentication Happens Here
Redirect user’s browser back to web app (API client) with authorization code
code
Token Request (authorization_code)
Token Response (access_token)
https://server.com?photos (access token)
“webapp” is requesting
access to the following
resources within your
account: do you whish
to grant this access?
Yes!
webapp

13. 13
SecuringAPIsusingOAuth
User logs into web page
Redirect user’s browser to authorization endpoint
OAuth Authorization Request (response_type=code)
User Authentication Happens Here
Redirect user’s browser back to web app (API client) with authorization code
code
Token Request (authorization_code)
Token Response (access_token)
https://server.com?photos (access token)
GET https://server.example.com/authorize?response_type=code&
client_id=s6BhdRkqt3&redirect_uri=https://client.example.com/cb
&scope=calendar.read_only
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
“webapp” is requesting
access to the following
resources within your
account: do you whish
to grant this access?
Yes!
webapp

14. 14
SecuringAPIsusingOAuth
DEMO

15. 15
SecuringAPIsusingOAuth
About that Token
• Bearer – whoever holds it may use it
– Original OAuth utilized client-side crypto, but developers didn’t
exactly flock to it
– Bearer tokens were a compromise: better than giving passwords to
API clients, less secure than client-side signing
• Structure undefined, but in practice:
– Opaque (requires introspection)
– JWT
• kid, x5t
• Can be embedded in other protocols besides HTTP (SIP, RTSP, etc.)

16. 16
SecuringAPIsusingOAuth
JSON Web Tokens
{
"alg": "RS256",
"x5t": "eZsobkgyfNGOyVpjEHgS2i8QhKQ"
}.
{
"Username": “alice@domain.com",
"exp": 1432744471,
"scope": [
“calendar_api.read_only“,
“contacts.read_only”,
“email.all”
],
"client_id": "s6BhdRkqt3"
}.
U4cL9RFKu_CwdqlpGReAVGA5sxw8d8tLXM4_1Cx7l49KQxeHYkV2ARlv6Qo7sdUSv7k50yhNPR80wFx0WqqtoLY
AKSJ2sXhfqbVTEZrUdDFZUVVYeKOWEyZzZD1w3NCqRm6xhLWmOu05A4gLDUuC7jWagMYquZPywW06SFX
FTa5MN0Nyol3V-QfrFf-XdXTBBUko00ooQf6SsyTcAP08kLuWIl9M2oRLPF_N_f5j1I4oAk5LUMFhdNyGeQ32K-
aU_kLoGxzb20eUlsZVO82zm-94tEdeKZWtp6BtwLICc9wvR1DnMJje7O_dOql1L1DYXNrJ0s7rWRlLwAxthbytww

17. 17
SecuringAPIsusingOAuth
User launches Native App
Redirect user’s browser to authorization endpoint
OAuth Authorization Request (response_type=code)
User Authentication Happens Here
Redirect user’s browser back to web app (API client) with authorization code
code
Token Request (authorization_code)
Token Response (access_token)
https://server.com?photos (access token)
Native
App

18. 18
SecuringAPIsusingOAuth
User launches Native App
Redirect user’s browser to authorization endpoint
OAuth Authorization Request (response_type=code)
User Authentication Happens Here
Redirect user’s browser back to API client with authorization code
code
Token Request (authorization_code)
Token Response (access_token)
https://server.com?photos (access token)
Native
App
SAML request
SAML response
SAML assertion

19. 19
SecuringAPIsusingOAuth
Other WG efforts
• Proof of Possession
• New grant types (SAML, JWT)
• Usage beyond REST
• Building block for OpenID Connect, NAPPS

20. 20
SecuringAPIsusingOAuth
But the grass isn’t all green
• 1.0 was a protocol, 2.0 is a “Framework”
• Flexibility == Complicated
• Interoperability issues
• No standardized access token format
• Not well understood
• It’s NOT for authentication
• Clients often ask for to broad
of a scope

21. 21
SecuringAPIsusingOAuth
But it’s still really good
• Clients never see user credentials
• Resource owners can approve only a limited scope
• Very developer friendly
• Options underway for even higher security

22. 22
SecuringAPIsusingOAuth
And in Closing …
• Questions?
• Comments?
• Scrutiny?
• Thank you! :-)
adam.lewis@motorolasolutions.com