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 makes it impossible for those users to use applications powered by the API.
- Difficulty implementing stronger authentication
If an API provider requires passwords for API authentication, it becomes challenging to improve account security with technologies like CAPTCHAs or multifactor authentication (such as one-time password tokens).
Get Getting Started with OAuth 2.0 now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
