Integration Using Web Server Flow
Allows apps with a secure client-server (private key or anything that can protect the private key) to access protected resources. This flow is primarily used by applications hosted on web servers. If your external application is trusted, hosted on a secure server, and you can store your client_secret securely, you can use Flow. This flow is primarily used for building web applications.
- Browser - for user authentication and consent.
- Client-server can protect client's secrets (or private key).
- Secure return channel between the client app and authentication server.
- Current Security Measures.
Don't forget to check out: Develop Lightning Web Components Faster with Local Development Server | Developer Quick Takes
What Else to Know?
- Security recommendations
|CSRF and replay attacks||Implement PKCE, State or Nonce to prevent CSRF attacks and token replay|
|Stolen tokens||Implement mutual TLS client authentication to the authentication server and resource server for certificate-bound tokens. Use short-lived access and refresh tokens whenever possible|
- Signed JWT (alternative to client secret)
OAuth 2.0 Web Server Authentication Flow
- This flow is primarily used by applications hosted on web servers.
- If your external application is trusted, hosted on a secure server, and you can store your client_secret securely, you can use Flow.
- This flow is primarily used for building web applications.
- First, the external application requests an access_token and the user is redirected to the login page for authentication. After authenticating, the user is granted access to Salesforce through the external app.
- A successful permission authorization returns an authorization code via a callback. The external app uses this temporary OAuth token (valid for 10 minutes) and sends a POST request to get the access_token by sending the temporary OAuth code, client_id and client_secret.
- Salesforce returns an access_token and a refresh_token. The access token can be regenerated by an external app using the refresh token so that the user does not have to authenticate each time.
- Instead of sending client credentials as parameters in the POST access token body, Salesforce supports HTTP basic authentication. The format of this scheme requires a client_id and client_secret in the authorization header of the post, like this: Authorization: Basic64Encode(client_id:secret)
- This flow is not recommended for applications that access Salesforce via an API and don't require a UI (such as ETL or middleware).
Check out another amazing blog by Mohit here: Learn About Users Permissions and Access in Salesforce
Considerations for Choosing Authorization Code Flow
- Highly secure
- A good use case for a refresh token
- Relatively low risk of compromised auth code
- Requires a trusted client app server