Allows client to authenticate using user’s username and password together with 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 username and password un-encrypted to Salesforce.
Additional requirements
- Client must securely manage client secret AND plain text passwords
- Transmission channel and auth. server request handling must not expose password
What else to know
- High security risk:
- Plain 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 username-password authentication flow to authenticate when the consumer already has the user’s credentials.
- Avoid using this flow because you have to send username and password un-encrypted 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 username-password authentication flow.
- In this flow, external app or client sends client_id,client_secret, username and password in 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 request for authentication.
- No refresh token is issued.
Recording
Considerations for choosing username-password flow
- High risk in password exposure
- No authorisation, so:
- No mechanism to track users who have authorised / not authorised
- 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
