OpenBankProject / OpenBankProject/OBP-API
Why OAuth 1.0a instead of OAuth 2.0?
Nobody has claimed this yet.
- Dominant language
- Scala
- Stars
- 1.7k
- Forks
- 482
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 15
Description
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.
- RFC 6749 - The OAuth 2.0 Authorization Framework
- RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage
- RFC 6819 - OAuth 2.0 Threat Model and Security Considerations
- RFC 7009 - OAuth 2.0 Token Revocation
- RFC 7033 - WebFinger
- RFC 7515 - JSON Web Signature (JWS)
- RFC 7516 - JSON Web Encryption (JWE)
- RFC 7517 - JSON Web Key (JWK)
- RFC 7518 - JSON Web Algorithms (JWA)
- RFC 7519 - JSON Web Token (JWT)
- RFC 7521 - Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants
- RFC 7522 - Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants
- RFC 7523 - JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants
- RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients
- RFC 7662 - OAuth 2.0 Token Introspection
- OAuth 2.0 Multiple Response Type Encoding Practices
- OAuth 2.0 Form Post Response Mode
- OpenID Connect Core 1.0
- OpenID Connect Discovery 1.0
- OpenID Connect Dynamic Client Registration 1.0
- OpenID Connect Session Management 1.0
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No repository files, tests, or entry points are named. Start by reviewing the stated OAuth 1.0a choice against RFC 6749, RFC 7636, and the OpenID Connect specifications linked in the issue. Done would require a resolved decision about the authentication approach and its security rationale.
Written by the indexing model from the issue text.
Assessment
- Domain
- authentication, authorization, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100