Here’s the relevant text from the VA OAuth 2.0 profile:

1. OAuth 2.0 Client Profiles

All clients MUST conform to applicable recommendations found in the Security Considerations sections of RFC6749 [4] and those found in the OAuth 2.0 Threat Model and Security Considerations document [8].

1.1. Client Types

The following profile descriptions give patterns of deployment for use in different types of client applications based on the OAuth grant type. The resource owner password credentials grant type defined in RFC6749 [4] is intentionally omitted from this discussion, and its use is not permitted under these profiles. Additional grant types, such as assertions, chained tokens, or other mechanisms, are out of scope of this profile and must be covered separately by appropriate profile documents.

1.1.1. Full Client with User Delegation

This client type applies to clients that act on behalf of a particular resource owner and require delegation of that user’s authority to access the protected resource. Furthermore, these clients are capable of interacting with a separate web browser application to facilitate the resource owner’s interaction with the authentication endpoint of the authorization server.

These clients MUST use the authorization code flow of OAuth 2 by sending the resource owner to the authorization endpoint to obtain authorization. The user MUST authenticate to the authorization endpoint. The user’s web browser is then redirected back to a URI hosted by the client, from which the client can obtain an authorization code passed as a query parameter. The client then presents that authorization code along with its own credentials to the authorization server’s token endpoint to obtain an access token.

The authorization code flow is supported only for confidential clients. Examples of this client type include web applications and native applications that can store installation-instance-specific client credentials securely. Client credentials MUST NOT be shared among instances of a given piece of client software.

This client type MAY request and be issued a refresh token if the security parameters of the access request allow for it.

1.1.2. Browser-embedded Client with User Delegation

This client type applies to clients that act on behalf of a particular resource owner and require delegation of that user’s authority to access the protected resource. Furthermore, these clients are embedded within a web browser and effectively share an active session between systems.

These clients use the implicit flow of OAuth 2 by sending a resource owner to the authorization endpoint to obtain authorization. The user MUST authenticate to the authorization endpoint. The user’s web browser is then redirected back to a URI hosted by the client, from which the client can directly obtain an access token. Since the client itself never authenticates to the server and the token is made available directly to the browser, this flow is appropriate only for clients embedded within a web browser, such as a JavaScript client with no back-end server component. Wherever possible, it is preferable to use the authorization code flow due to its superior security properties.

This client type MUST NOT request or be issued a refresh token. Access tokens issued to this type of client MUST be short lived and SHOULD be tied to the user’s authentication session with the client.

1.1.3. Direct Access Client

This profile applies to clients that connect directly to protected resources and do not act on behalf of a particular resource owner, such as those clients that facilitate bulk transfers.

These clients use the client credentials flow of OAuth 2 by sending a request to the token endpoint with the client’s credentials and obtaining an access token in the response. Since this profile does not involve an authenticated user, this flow is appropriate only for trusted applications, such as those that would traditionally use a developer key.

For example, a partner system that performs bulk data transfers between two systems would be considered a direct access client.

This client type MUST NOT request or be issued a refresh token.