Igor Bossenko

23.05.2014

SPA & REST security

Agenda

AuthenticationHow protect REST services

API-Key

Secret-key

Signature

Nonce, non-repuduation

OAuth1 vs OAuth2

AuthorizationProfiles

Stateless vs stateful

HATEOAS

Atom/RSS

„Legacy“ solutions

HTTP Basic authentication

Username/password in URL

Google Translate example

Authentication with API Key

Simplest way for REST authentication

Used for public or open APIsTwitter, 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

Public Google API

Public API is usually very atomic

New Google credential generation

Usually you must have separate API-Key for every API group

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)

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.

Amazon solution

Request example

Signature calculation

Nonce

Nonce is an arbitrary (unique) number/stringRandon number

Number based on timestamp

Nonce included into signature

Requests with signature and nonce is very secure and protect from replay attacks

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.

OAuth 1.0 concept

TermsUser, Consumer, Service Provider, Protected Resource, Provider API

5 parameters to work with OAuth 1.0Consumer key & Consumer secret 

Request token URL

Authorize URL

Access token URL

OAuth 1.0 componentsToken = Key + Secret

Message = Document + Digital Signature

Application = Consumer + Access to API

OAuth 1.0 Authentication Flow

OAuth 1.0 summary

OAuth 1.0

=

Fetch Request Token +

Redirect to Authorization +

Fetch Access Token +

Call API +

Signature calculated with secret-key

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“ ).

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

OAuth 1.0 vs Estonian xRoadxRoad 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

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."

List of OAuth service providers (May/2014)

Service providerOAuth protocol

Amazon 2.0AOL 2.0Basecamp 2.0Bitbucket 1.0aDropbox 1.0, 2.0Evernote 1Facebook 2.0 draft 12Flickr 1.0aFoursquare 2GitHub 2Goodreads 1Google 2Google App Engine 1.0aInstagram 2Intel Cloud Services 2LinkedIn 1.0a, 2.0

Microsoft (Hotmail, Windows Live, Messanger, Xbox) 2Netflix 1.0aPayPal 2Twitter 1.0a, 2.0Ubuntu One 1Vimeo 1.0aYandex 2

OAuth 1.0 vs OAuth 2.0

Problems of OAuth 1.0Authentication 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

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.

OAuth2 Web Server Flow

OAuth2 Web Server Flow details

SSO

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

OAuth2 User Agent Flow

OAuth2 Resource Owner Password Credentian Flow

OAuth2 Client Credential Flow

OAuth2 JSON Web Token (JWT) Flow

OAuth2 Revoke/Info request

OAuth2 Refresh Token

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

When to use OAuth1 & OAuth2?

OAuth 1.0 – server-to-server

OAuth 2.0 – browser/device/client-to-server

I use OAuth. Does my app protected?

NoJSON 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 doAuthorization and role/privilege check

Check of data consistency

State check or check of allowed actions

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

Data consistency

REST design“Big” API vs “small” API

Profiles

Atom/RSS

“Big” API vs “small” API

1 REST service or 3 services?

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/ARecipient/Organization N/A N/A MOwner/-organization N/A O MOwner/Person N/A O ORow/Article M M M Row/Quantity N/A M M Row/Sum N/A N/A OPayment/Sum O O N/Aconstraints Row.size()==1 Row.size()==1 Row.size()>0

State validation

StatelessOAuth2 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

StatefulYou can use it too, but why?

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" } ]}

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/

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

Thank you! Questions?