Username and password flow
Amit Chaudhary

Amit Chaudhary

Amit Chaudhary is Salesforce Application & System Architect and working on Salesforce Platform since 2010. He is Salesforce MVP since 2017 and have 17 Salesforce Certificates. He is a active blogger and founder of Apex Hours.

Username-Password Flow

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

Share this article

Leave a reply

Keep in Touch

Subscribe for Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 3,229 other subscribers

Search

Our Supporter

RECENT POSTS

Apex Hours

Apex Hours is one stop platform to learn Salesforce skills and technology

Join our Newsletter and get tips and tricks how to explore the salesforce for free!