TL;DR - It's not okay, don't use it. Instead, go with the authorization code grant type (aka Web Server flow in Salesforce world).
The user-agent flow in Salesforce is based on oAuth implicit grant type with one difference - refresh token.
You only get the refresh token if you ask for it explicitly with
scope = refresh_token and your flow meets other documented constraints such as custom protocol on the callback URL. This is a Salesforce "extension", it is not compliant with implicit grant type in oAuth spec. If memory serves, it was created by SF for mobile apps a while ago. While some might still be using it, it's more or less a legacy option as of now.
Even if you don't ask for a refresh token and use spec-compliant implicit grant type (which is possible via User-Agent in Salesforce), this option is no longer recommended. From oAuth Security Best Current Practice (BCP):
The implicit grant (response type "token") and other response types
causing the authorization server to issue access tokens in the
authorization response are vulnerable to access token leakage and
access token replay
...and another relevant note in oAuth Browser-based Apps BCP:
9.8.4. Historic Note
Historically, the Implicit flow provided an advantage to
manipulate the fragment portion of the URL without triggering a
page reload. This was necessary in order to remove the access token
from the URL after it was obtained by the app.
Modern browsers now have the Session History API which provides a
mechanism to modify the path and query string component of the URL
without triggering a page reload. This means modern browser-based
apps can use the unmodified OAuth 2.0 authorization code flow, since
they have the ability to remove the authorization code from the query
string without triggering a page reload thanks to the Session History
The oAuth Security BCP goes on to say you might be able to use it if you mitigate certain issues. Salesforce helps you with some of these issues by e.g. enforcing same-origin on user agent. Still, the threat model is extensive and mitigation strategies are fragile. Thus, the authorization code grant with PKCE is the recommended way to go nowadays for any public client, native mobile or browser-based. See oAuth 2.1 draft for updated guidance. (The language in 2.1 is not "law" since it's still a draft but aside from brand new 2.1 stuff, the rest of it applies wholesale to any oAuth 2.0 solution).
Now let's look at the recommended option - authorization code grant (aka Web Server flow in Salesforce). In this flow there are 3 types of tokens or codes being used:
An authorization code is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token. It's an intermediary construct in the authorization flow sequence, you don't need to "manage" it in your application.
Access tokens are credentials used to access protected resources. Example of a protected resource is a REST API exposed by Salesforce.
Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires.
See oAuth 2.0 spec (RFC 6749) for more details on these.
The term authentication code is ambiguous, it probably refers to authorization code in the flow above.