Allows the client to authenticate using the user’s username and password and a protected secret. Use the username-password authentication flow to authenticate when the consumer already has the user’s credentials. Avoid using this flow because you have to send a username and password unencrypted to Salesforce.
Additional requirements
- The client must securely manage client secret AND plain text passwords
- Transmission channel and auth. server request handling must not expose the password.
What else to know
- High-security risk:
- Simple text passwords exposed to multiple systems & channels
- No opportunity for multi-factor authentication
- Prior user approval not checked (unlike JWT / SAML assertion bearer flows)
- Current IETF recommendation – do not use this flow
OAuth 2.0 Username and Password Flow
- Use the user name-password authentication flow to authenticate when the consumer already has the user’s credentials.
- Avoid using this flow because you have to send user-name and password unencrypted to Salesforce.
- Use this flow only when there is no way to connect by using other available flows.
- Salesforce communities don’t support the OAuth 2.0 user-name-password authentication flow.
- In this flow, an external app or client sends client_id,client_secret, user name, and password in the POST request.
- The security token must be added to the end of the password to log in to Salesforce from an un-trusted network. Concatenate the password and token when passing the authentication request.
- No refresh token is issued.
Recording
Considerations for Choosing username-password flow
- High risk of password exposure
- No authorization, so:
- There is no mechanism to track users who have authorized / not authorized
- No opportunity to include multi-factor authentication
- Consider only when:
- Entities are part of the same system (not relevant to Salesforce) OR
- As a last resort when no other OAuth flow is possible, and there is complete trust between systems and transport mechanisms.
