The document discusses various authentication and authorization methods for REST APIs, including API keys, signatures, OAuth 1.0, and OAuth 2.0. It provides details on implementing authentication with an API key, secret key, or signature for identity and authorization. The document contrasts OAuth 1.0 and 2.0, covering their concepts, authentication flows, and differences. It also discusses using OAuth for SSO, refreshing tokens, and consuming secured RSS/ATOM feeds, as well as validating state, data consistency, and enforcing authorization with REST services.

1. Igor Bossenko
23.05.2014
SPA & REST security

2. Agenda
Authentication
How protect REST services
API-Key
Secret-key
Signature
Nonce, non-repuduation
OAuth1 vs OAuth2
Authorization
Profiles
Stateless vs stateful
HATEOAS
Atom/RSS

3. „Legacy“ solutions
HTTP Basic authentication
Username/password in URL

4. Google Translate example

5. Authentication with API Key
Simplest way for REST authentication
Used for public or open APIs
Twitter, Google Maps, New York Times, …
API key usually used for
Identify the caller
Check IP addresses of caller
To limit the number of requests
Authentication with API Key only is
unsecure

6. Public Google API
Public API is usually very atomic

7. New Google credential generation
Usually you must have separate API-Key for every API group

8. Authentication with secret key
API-key for identity
Secret-key (symmetric shared key) for
authentication
Authentication with additional secret
in header is not enough secure
(man-in-the-middle attacker risk)

9. Authentication with signature
API-key for identity
Secret-key for authentication, but secret key never sent with
request
Signature header is a HMAC-SHA256 hash of the nonce
concatenated with the full URL and body of the HTTP request,
encoded using your API secret-key.
Authentication with signature is secure.

10. Amazon solution
Request example
Signature calculation

11. Nonce
Nonce is an arbitrary (unique) number/string
Randon number
Number based on timestamp
Nonce included into signature
Requests with signature and nonce is very
secure and protect from replay attacks

12. Oauth (1.0)
In 2006 were no open standards for
API access delegation.
OAuth was designed to solve the
application-to-application security
problem.
OAuth Core 1.0 was released in 2007.

13. OAuth 1.0 concept
Terms
User, Consumer, Service Provider, Protected Resource, Provider
API
5 parameters to work with OAuth 1.0
Consumer key & Consumer secret
Request token URL
Authorize URL
Access token URL
OAuth 1.0 components
Token = Key + Secret
Message = Document + Digital Signature
Application = Consumer + Access to API

14. OAuth 1.0 Authentication Flow

15. OAuth 1.0 summary
OAuth 1.0
=
Fetch Request Token +
Redirect to Authorization +
Fetch Access Token +
Call API +
Signature calculated with secret-key

16. vs
OpenID - protocol for fast user
registration on the current website
(“protocol for users”)
OAuth - protocol for authorized access
to the third-party vendor API („protocol
for robots“ ).

17. Non-repudiation
Non-repuduation - method to ensure that a
transferred message has been sent and
received by the parties claiming to have sent
and received the message
Nonrepudiation can be obtained through the
use of:
Digital signatures
Confirmation services
Timestamp

18. OAuth 1.0 vs Estonian xRoad
xRoad OAuth
PKI public/private
certificates
string as secret key or
public/private certificates
Certificate storage Secure server Any verified certificate
storage, such as AD, ..
Organization RIA (Estonian
Information System
Authority)
Required
API Developed by RIA (in
estonian)
Required
Special software xRoad server No
Scope Estonian standard International standard
Protocol SOAP REST

19. OAuth 2.0
OAuth 2.0 focuses on client developer simplicity
while providing specific authorization flows for
web applications, desktop applications, mobile
phones, and living room devices.
OAuth 2.0 is more a framework than it is a
defined protocol.
OAuth 2.0 is not backwards compatible with
OAuth 1.0.
In July 2012, Eran Hammer resigned his role of lead author for the OAuth
2.0 project, withdrew from the IETF working group, and removed his
name from the specification. Hammer: „OAuth 2.0 is more complex, less
interoperable, less useful, more incomplete, and most importantly, less
secure."

20. List of OAuth service providers (May/2014)
Service provider
OAuth
protocol
Amazon 2.0
AOL 2.0
Basecamp 2.0
Bitbucket 1.0a
Dropbox 1.0, 2.0
Evernote 1
Facebook 2.0 draft 12
Flickr 1.0a
Foursquare 2
GitHub 2
Goodreads 1
Google 2
Google App Engine 1.0a
Instagram 2
Intel Cloud Services 2
LinkedIn 1.0a, 2.0
Microsoft (Hotmail, Windows Live, Messanger, Xbox) 2
Netflix 1.0a
PayPal 2
Twitter 1.0a, 2.0
Ubuntu One 1
Vimeo 1.0a
Yandex 2

21. OAuth 1.0 vs OAuth 2.0
Problems of OAuth 1.0
Authentication and Signatures on client side
User Experience and Alternative Token Issuance Options
Performance at Scale
OAuth 2.0 changes:
OAuth 2.0 relies completely on SSL for some degree of
confidentiality and server authentication.
Cryptography-free option for authentication which is based
on existing cookie authentication architecture.
Simplified signatures
Separation of Roles (SSO support)
Short-lived tokens with Long-lived authorizations

22. OAuth 2.0 flows
Web Server Flow – for clients that are part of a web server
application, accessible via HTTP requests. This is a simpler version
of the flow provided by OAuth 1.0.
User-Agent Flow – for clients running inside a user-agent (browser).
Device Flow – suitable for clients executing on limited devices, but
where the end-user has separate access to a browser on another
computer or device.
Username and Password Flow – used in cases where the user
trusts the client to handle its credentials.
Client Credentials Flow (JWT) – the client uses its credentials to
obtain an access token. This flow supports what is known as the 2-
legged scenario.
Assertion Flow – the client presents an assertion such as a SAML
assertion to the authorization server in exchange for an access
token.

23. OAuth2 Web Server Flow

24. OAuth2 Web Server Flow details

25. SSO
Particular case of Web Server Flow
when Client App and Resource Server
use the same Authorization Server

26. OAuth2 User Agent Flow

27. OAuth2 Resource Owner Password
Credentian Flow

28. OAuth2 Client Credential Flow

29. OAuth2 JSON Web Token (JWT) Flow

30. OAuth2 Revoke/Info request

31. OAuth2 Refresh Token

32. Does OAuth1 better than OAuth2?
Does OAuth1 better than OAuth2?
No, they have different purpose: OAuth1 for
server to server communication and OAuth2 for
user/device to server
Does OAuth1 more secure than
OAuth2?
Yes and No
OAuth 1.0 may be used without HTTPS
But, OAuth2 same secure as SSL

33. When to use OAuth1 & OAuth2?
OAuth 1.0 – server-to-server
OAuth 2.0 – browser/device/client-to-
server

34. I use OAuth. Does my app protected?
No
JSON may be changed before sending
Any URI may be called
OAuth just authentication for your app
and authorization to 3d-party apps
You may wants to do
Authorization and role/privilege check
Check of data consistency
State check or check of allowed actions

35. Authorization
You must check permissions every
time when REST service runs inside
service
You must also identify client and
context by cookie or by certificate

36. Data consistency
REST design
“Big” API vs “small” API
Profiles
Atom/RSS

37. “Big” API vs “small” API
1 REST service or 3 services?

38. Profiles
Тhe server checks the data sent
regarding the xsd or profile or...
Profile example
Servoice LivingSubject Profile „Ivoice 1" Profile „Invoice 2" Profile „Invoice 3"
Recipient/Person N/A M N/A
Recipient/Organization N/A N/A M
Owner/-organization N/A O M
Owner/Person N/A O O
Row/Article M M M
Row/Quantity N/A M M
Row/Sum N/A N/A O
Payment/Sum O O N/A
constraints Row.size()==1 Row.size()==1 Row.size()>0

39. State validation
Stateless
OAuth2 provides token expiration
You can store frequently used data in
HTTP Cookie
Local storage
Memory DB
Cache (like Ehcache)
Use HATEOAS (Hypermedia as the Engine of Application
State or hypermedia-driven system) for form validation
Stateful
You can use it too, but why?

40. HATEOAS
Data and links content separated one from another
Server may store allowed links and refuse all other
REST queries
A simple JSON presentation is traditionally rendered as:
{
"name" : "Alice"
}
A HATEOAS-based response would provide relevant links like this:
{
"name": "Alice",
"links": [ {
"rel": "self",
"href": "http://localhost:8080/customer/1"
} ]
}

41. HATEOAS and the PayPal REST Payment API
[
{
"href": "https://api.sandbox.paypal.com/v1/payments/payment/PAY-6RV70583SB702805EKEYSZ6Y",
"rel": "self",
"method": "GET"
},
{
"href": "https://www.sandbox.paypal.com/webscr?cmd=_express-checkout&token=EC-60U79048BN7719609",
"rel": "approval_url",
"method": "REDIRECT"
},
{
"href": "https://api.sandbox.paypal.com/v1/payments/payment/PAY-6RV70583SB702805EKEYSZ6Y/execute",
"rel": "execute",
"method": "POST"
}
]
https://developer.paypal.com/docs/integration/direct/paypal-
rest-payment-hateoas-links/

42. Use of OАuth
OAuth can be used as an authorizing
mechanism to consume secured
RSS/ATOM feeds
RSS/ATOM feeds
mechanism helps
to manage state

43. Thank you! Questions?