search

OpenBankProject / OBP-API

An open source RESTful API platform for banks that supports Open Banking, XS2A and PSD2 through access to accounts, transactions, counterparties, payments, entitlements and metadata - plus a host of internal banking and management APIs.
https://www.openbankproject.com/
1.55k stars 430 forks source link

Why OAuth 1.0a instead of OAuth 2.0? #15

Open TakahikoKawasaki opened 8 years ago

TakahikoKawasaki commented 8 years ago

Why have you chosen OAuth 1.0a instead of OAuth 2.0 (RFC 6749)? OAuth 1.0a is a futureless specification.

Many specifications have been standardized based on OAuth 2.0 so far. OpenID Connect is a representative example of such specifications. As its FAQ states, major players such as AOL, Deutsche Telekom, Facebook, Google, Microsoft, Mitre Corporation, mixi, Nomura Research Institute, Orange, PayPal, Ping Identity, Salesforce and Yahoo! Japan have contributed to the standardization of OpenID Connect.

All the ongoing discussions in OpenID Connect & OAuth Working Groups are based on OAuth 2.0. If you use OAuth 1.0a, you will not be able to benefit from new specifications such as RFC 7636 which is an important security specification standardizing the countermeasure against the authorization code interception attack. See this mail archive of OAuth WG where Google and other companies announced their support for RFC 7636. Compared to achievements by OpenID Connect & OAuth Working Groups, how secure can OBP-API be?

FYI: The following is an incomplete list of specifications related to OAuth 2.0 and OpenID Connect.

msoos commented 8 years ago

(just to chirp in, I didn't take a look if you are using OAuth 1.0 but it's clearly deprecated: https://developers.google.com/identity/protocols/OAuthForWebApps so I'd be cautious not upgrading to 2.0 if indeed there is no 2.0 option)

TakahikoKawasaki commented 8 years ago

The following is the content of 'Abstract' of RFC 6749 (The OAuth 2.0 Authorization Framekwork).

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 specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849.

It is mentioned also at the top of the HTML version of RFC 5849 (The OAuth 1.0 Protocol) like below.

Obsoleted by: 6749

TakahikoKawasaki commented 8 years ago

If choice of OAuth 1.0 was made based on "OAuth 2.0 and the Road to Hell", it must be noted that OAuth 1.0 signature does not ensure any security for smartphone client applications and web browser-based applications. The blog post insists that OAuth 1.0 is more secure than OAuth 2.0, but the argument requires the assumption that smartphone applications can keep consumer secrets confidential. However, the assumption is naive. The specification of OAuth 2.0 (RFC 6749) clearly recognizes the incapability in 2.1. Client Types as excerpted below.

confidential     Clients capable of maintaining the confidentiality of their     credentials (e.g., client implemented on a secure server with     restricted access to the client credentials), or capable of secure     client authentication using other means.

public     Clients incapable of maintaining the confidentiality of their     credentials (e.g., clients executing on the device used by the     resource owner, such as an installed native application or a web     browser-based application), and incapable of secure client     authentication via any other means.

In addition, 9. Native Applications says as follows.

Native applications that use the authorization code grant type SHOULD do so without using client credentials, due to the native application's inability to keep client credentials confidential.

RFC 5849 (The OAuth 1.0 Protocol) defines HMAC-SHA1, RSA-SHA1 and PLAINTEXT as signature methods. A client application must have a shared key for HMAC-SHA1 or a private key for RSA-SHA1. In either case, the key must be secret. However, it is well known that secret keys are easily extracted from smartphone applications by crackers. On smartphone applications and web browser-based applications, computing oauth_signature using a secret key does not enhance security. It's just a cumbersome calculation without any security enhancement. I mean, compared to the simplicity that an OAuth 2.0 confidential client connects to a server over TLS and just presents client_id and client_secret, it cannot be said that the cumbersome calculation is better in terms of security.

TakahikoKawasaki commented 8 years ago

Open Data Institute released a report titled "The Open Banking Standard" (148 pages) on Feb 08, 2016.

"7c. 2.2 Authentication" (p.41) in the report says as follows.

OAuth 2.0 in conjunction with OpenID Connect are recommended as authentication protocols of choice - future work will be needed to specify the precise model.

In addition, the whole content of "7c. 8. Security and Authentication Aspects of the API Specification" (p.47-p.50) is an explanation about OAuth 2.0.

"Table A6.2 Pros and cons of open authorisation protocols" (p.121) in "Appendix 6. Open banking: risks and mitigants" lists pros and cons of OAuth 1.0, OAuth 2.0 and OpenID Connect. Cons of OAuth 1.0 listed there are as follows.

dendle commented 7 years ago

This was my first thought when reading the spec - I was actually shocked that OAuth 2 was not the obvious choice. OpenID-Connect on top of OAuth 2 is the clear choice, especially if transparency is a core value if the OBP.