Allows apps with a secure client server (one which can protect a secret or private key) to access protected resources. This flow is mainly used by applications hosted on web server. If external application is trusted one and hosted on secure server and can securely store client_secret, then flow can be used. This flow is used mainly to build web application.
- Browser – for user to authenticate and consent
- Client server can protect client secret (or a private key)
- Secure back-channel between client app and auth server
- Up to date security measures
What else to know
- Security recommendations
|CSRF and replay attacks||Implement PKCE, state and/or nonce to prevent CSRF attacks and token replay|
|Stolen tokens||Implement mutual-TLS client authentication on auth & resource servers for certificate-bound tokens. Use short lifetime access tokens with refresh tokens when possible|
- Signed JWT (alternative to client secret)
OAuth 2.0 Web Server Authentication Flow
- This flow is mainly used by applications hosted on web server.
- If external application is trusted one and hosted on secure server and can securely store client_secret, then flow can be used.
- This flow is used mainly to build web application.
- First of all external application will request for access_token and user will be redirected to login page for authentication. After authentication, user will approve salesforce access by external app.
- After successful approval to grant access, authentication code will be returned through callback. External app will utilize this temporary OAuth token( valid for 10 mins) and send POST request to get access_token by sending temporary OAuth code, client_id and client_secret.
- Salesforce will return access_token and refresh_token. Refresh token can be used to regenerate the access token by external app so that user is not required to authenticate every time.
- Instead of sending client credentials as parameters in the body of the access token POST, Salesforce supports the HTTP Basic authentication scheme. This scheme’s format requires the client_id and client_secret in the authentication header of the post as follows: Authorization: Basic64Encode(client_id:secret)
- This flow is not recommended for application (like ETL or middleware’s) which will access salesforce using API’s and no UI is involved.
Considerations for choosing authorisation code flow
- Highly secure
- Good use case for refresh token
- Relatively low risk of compromised auth. code
- Requires a trusted client app server
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.