A simpler flow for clients which should not hold a global secret (e.g. distributed apps), but can be trusted with per-user access token. This flow is recommended when you build mobile or desktop application and your application can be distributed to anyone. So these kind of application are not considered as safe to store client secret because source code of application will be accessible to everyone and client secret can be exposed easily.
Additional requirements
Browser – for token requests, authentication/consent and token redirects
Client can protect access token
Up to date security measures and mitigations beyond current spec
What else to know
Historically* recommended for browser apps
Risks of this flow:
Access tokens in URLs are easily leaked:
In browser referrals
From browser history
No mechanism to cryptographically bind access tokens to client – access token injection relatively straightforward through CSRF
Refresh tokens not advised
But without these, silent re-authentication relies on 3rd party cookies
*Current IETF recommendation is to not use this flow: https://ift.tt/3uPcD4u
Currently used for Salesforce Mobile SDK and Mobile Publisher
Mitigations in Salesforce implementation:
Tokens / sessions included in URL hash fragment (not query string parameter)
Recommendation to programmatically remove token callback from browser history
Session IDs returned (with hybrid_token option) for re-authentication without 3rd party cookies
OAuth 2.0 User Agent Flow
This flow is recommended when you build mobile or desktop application and your application can be distributed to anyone. So these kind of application are not considered as safe to store client secret because source code of application will be accessible to everyone and client secret can be exposed easily.
This flow is used when external system application wants to login into salesforce using salesforce login credentials. Once user logged in, then he/she to approve that external application can fetch salesforce data(scope defined in connected app).
In this flow, external application will pass only client id and user login page opens and user authenticate themselves to get access token, refresh tokens.
External application can use use refresh token to get new access token if it get expired and can avoid logging user again in salesforce.
With the user-agent authentication flow, the client app receives the access token as an HTTP redirection. The client app requests the authorization server to redirect the user-agent to another web server or to an accessible local resource. The server can extract the access token from the response and pass it to the client app. For security, the token response is provided as a hash (#) fragment on the URL. It prevents the token from being passed to the server or to any other servers in referral headers
Recording
Considerations for choosing implicit grant flow
Salesforce implementation has been established for some time and avoids a custom alternative for Mobile SDK apps
Multiple security vulnerabilities possible
Complications for cross-domain use cases when 3rd party cookie support disabled / retired
Current IETF recommendation is not to use this flow
March 03, 2021 at 06:30PM Click here for more details...
=============================
The original post is available in Apex Hours by Amit Chaudhary
this post has been published as it is through automation. Automation script brings all the top bloggers post under a single umbrella.
The purpose of this blog, Follow the top Salesforce bloggers and collect all blogs in a single place through automation.
============================
Post a Comment