The document discusses the evolution and security challenges of web APIs, outlining the shift from traditional APIs to web APIs that interact over the internet. It emphasizes the need for a new security model that includes short-lived access tokens and involves user participation in the authentication process, primarily through OAuth 2.0. The document also highlights the importance of regular scrutiny of app access privileges to ensure safer web API exposure.

1. Trust No One
The New Security Model for Web APIs
Greg Kliewer
Principal Consultant, Solutions Architect
Layer 7, a CA Technologies company
October 8, 2013
© 2013 CA. All rights reserved.

2. What are Web APIs?

3. Old School APIs: Application Programming Interfaces
My API
Your Code
My Code
APIs are for connecting “software machines”
 Modules within a program
 Programs on a server
 Programs over local networks
My Server
Your Client
3
© 2013 CA. All rights reserved.

4. Web APIs are for connecting “web machines”
 Over the World Wide Web
 Exploiting a globally-connected network
My API
4
© 2013 CA. All rights reserved.

5. How Web APIs Evolved

6. Before there were Web APIs, there were Web Apps


No programmatic access from the
Public Internet

6
APIs protected by network separation
Safety through total isolation and
control
© 2013 CA. All rights reserved.

7. Then came Web Services
SOA / SOAP services
 Used web technologies like HTTP, SSL/TLS, and
language-independent, text-based grammar
 Applied mostly for internal application
integration, like old school APIs
 BUT there was some limited uptake of SOAP web services for
allowing programmatic access to core services by business
partners and corporate customers
7
© 2013 CA. All rights reserved.

8. Security for Web Services
The model most of us are familiar with

CA
Establish TRUST with public key infrastructure
– Private key / public certificate pairs
– Have certificates signed by recognized CA / RA
Partner
– Exchange that certificate with similarly-assured
certificate from partners
Company

Apply asymmetric crypto at runtime to validate
digital signatures / decrypt encrypted content
VALIDATE
– SSL/TLS Mutual Authentication
SSL/TLS
SIGN
Partner
VERIFY
– XML-DSIG/XML-ENC applied to SOAP documents
Company

8
TRUST partner / corporate customer to treat
crypto material with care and caution
© 2013 CA. All rights reserved.

9. But now the disrupters are here
My Business
9
© 2013 CA. All rights reserved.

10. Mobile, Social, Cloud, and Embedded Applications
Require programmatic access
Do not support PKI / Asymmetric Crypto*
*to prove their identity
10
© 2013 CA. All rights reserved.

11. How can we safely
expose Web APIs?
11
© 2013 CA. All rights reserved.

12. The new security model for Web APIs

13. In the new world
there are exponentially more Apps to be served
Enterprise Apps, Portals, and Web Apps
are being decomposed into Apps…
notes
calendar
mail
13
© 2013 CA. All rights reserved.

14. In the new world
there are exponentially more Apps to be served
…and released into the wild
14
© 2013 CA. All rights reserved.

15. So if we are going to publish APIs to these new Apps…
My API
15
© 2013 CA. All rights reserved.

16. …we had better require more regular and active
scrutiny of the Apps’ access privileges…
 First of all, DO NOT issue long-lasting certificates to the Apps (e.g. x.509 expires in 1 yr)
 Instead, issue short-lived access tokens that can be revoked at any time
Request Access
access token
How long should the Apps
have access without reauthenticating?
1 hour for info services
Security
Architect
16
CISO
© 2013 CA. All rights reserved.
5 mins for financial txns

17. …we had better require more regular and active
scrutiny of the Apps’ access privileges…
 Next, include the end user in authenticating / authorizing the App
 Explicitly grant access
 To a limited scope
Declare
Scope
This App would like to
access your profile data
and bill to your account.
grant
Request Access
access token
17
© 2013 CA. All rights reserved.

18. Introducing OAuth
The new security model for Web APIs

“
Open standard specification by IETF WG
The OAuth 2.0 authorization framework enables a third-party application to obtain limited
access to an HTTP service, either on behalf of a resource owner by orchestrating an approval
interaction between the resource owner and the HTTP service, or by allowing the third-party
application to obtain access on its own behalf.
This App would like to
Declare
access your profile data
Scope and bill to your account.
grant
Request
Access
access token
Requests with access token
18
© 2013 CA. All rights reserved.
OAuth Auth Server
”

19. OAuth adoption
The big guys…
19
© 2013 CA. All rights reserved.

20. OAuth adoption
…and YOU
20
© 2013 CA. All rights reserved.

21. How to learn more

22. Where to learn more


Come talk to us!
Primers
– Booth #505
– We’re here today and tomorrow

– By Aaron Parecki
– By Jakob Jenkov

API Academy
– Online resources
– The 5 OAuth essentials
– Workshops

Publications

OAuth Online
Blogs
– By Francois Lascelles
– http://oauth.net/
– https://www.ietf.org/mailman/listinfo/oauth
22
© 2013 CA. All rights reserved.

23. Greg Kliewer
Principal Consultant, Systems Architect
greg.kliewer@ca.com
@cainc
slideshare.net/CAinc
linkedin.com/company/ca-technologies
ca.com