Why Don’t These APIs Just Use Passwords for Authorization?
Usernames and passwords are typically the lowest common denominator for authentication and authorization on the Web. They are used for HTTP Basic and HTTP Digest authentication and on countless login pages. However, asking a user for their password has a number of side effects:
- Trust
A user may not trust providing their password to your application.
- Decreased user sensitivity to phishing
Even if the user is comfortable providing their password to your application, making the user comfortable doing this around the Web can have negative long-term effects, such as making phishing scams more effective.
- Expanded access and risk
When the user provides their password to your application, you get access to not only the data your application needs, but all other data in the user’s account. The application has an obligation to its users to securely store these passwords and prevent them from leaking. Many developers do not want the risk exposure of having this additional responsibility.
- Limited reliability
When a user changes their password, your application no longer has access to their data.
- Revocation challenges
The only way a user can revoke access to your application is by changing their password, which also revokes access to all other apps.
- Passwords become required
When an API provider supports federated authentication mechanisms such as OpenID or SAML (see Federated Authentication), users may not have passwords on their accounts. This ...