These notes on OAuth 2.0 User Agent Flow were made studying for Identity and Access Management Architect Salesforce certification.
OAuth 2.0 User Agent Flow:
To implement the User Agent Flow, we need to create a connected app (see this article here) which is then used as authentication from desktop or mobile clients to the protected resource. The connected app will have a callback URL which enables Salesforce to redirect the user to the URL where the resource resides with the proper tokens after authentication. A Callback URL received the responses from the identity provider after a successful login.
The client application that uses the connected app to access the resource should not be distributed outside your organisation and only trusted on a per-user access token. Because client secrets can be exposed easily to use this flow, additional security measures and mitigations beyond the simple User Agent flow need to be implemented.
How are the client secrets or access tokens exposed? They can be leaked via browser referrals or history. It is also not possible to bind the access tokens to the client.
When is it Used?
It is used with Salesforce Mobile SDK and Mobile Publisher. In the design of the Mobile app, the tokens are stored in a URL hash fragment instead of a query string parameter and Sessions IDs are returned for re-authentication without having to rely on 3rd party cookies. Need to consider implementing code to assist in the removal of token callback from browser histories.
Authorisation Code Flow with PKCE:
Due to the security issues with this type of authorisation flow, it is recommended to use Authorisation Code Flow with Proof Key for Code Exchange (PKCE). This can be used where no secure Client Server is involved.
Authorisation Code Flow with PKCE is used for distributed mobile apps or desktop app. A browser is required for users to authenticate and consent to access. The client app needs to also be able to generate and securely store a code verifier. This should be using hashes. Security should always be up to date.
The code verifier is generated and stored in the browser and a code challenge is created. The browser sends a request to the authorisation endpoint. It contains the scopes etc. set in the Connected App. The code challenge is stored in the authorisation server and a series of authentication requests happen including the User’s login to the authorisation server, consenting to the scopes requested, checking the redirect URI matches an approved callback url. When this has been checked, the code verifier is sent in a request to the token endpoint on the authorisation server and then the Client app is sent an access token. The authorisation Server also checks the Client id, the authorisation, and redirect URI before sending the access token. It will also check that the hashed code verifier hashed value matches the code challenge associated with the authorisation flow. Following that the access token is used by the Client app to access the Resource Server.
Access token leakage is reduced as the request / response for all items protects against access token injection.