We should be well past the age where simple challenge and response username-password pairs can provide unfettered access to a complete work process. The fact that a single, upfront challenge and response can lead to changing or deletion of data at the back end without further checks, should send shivers of fear down the spine of any enterprise data administrator.
But what's the alternative?
Modern applications involve the passing of workflows and data between different services. It is critical that each service maintains its security and minimizes the potential for attack. What is needed is a means -- or set of means -- to create immutable identifiers that can securely identify and facilitate actions between different services. These means must also allow for time-based access, session repudiation and auditability.
To this end, there are four main ways to provide the extra security required for such flows of application and data:
- ID tokens
- Access tokens
- Auth tokens
- API keys
ID tokens, access tokens and auth tokens
Tokens are bits of information that have no meaning on their own that require an external system to turn the information into a usable set of data. Tokens generally consist of a header that defines the type of token and security algorithm used; a payload that contains user information and metadata such as token duration and time of creation; and a signature to verify the sender's identity and the message's authenticity.
ID tokens and access tokens are based around the security standard brought forward by OAuth. OAuth (now in V2) enables calling services to access other services without the need for each service to know any physical passwords. Originally designed to secure the use of web front ends against back-end services and databases, OAuth now includes inter-service activities as well.
ID tokens are an assertion of a user's identity. They contain basic user details, such as a validated email address. In many cases, the ID token will be part of the user's credentials obtained during the initial handshake between the client and the server-based system.
Do not take the ID token at face value: It must be checked. For this, check the token's signature against the issuing agent's public keys. Also check the expiration time of the token, and other aspects -- such as that the client is calling your service -- to ensure that token is not being used either as a man-in-the-middle attack or through using legal tokens issued for other uses.
Access token vs. ID token
An access token is similar to an ID token but does not contain user details such as a validated email address. As such, the access token is a far simpler entity -- but less can be done with it. An ID token can be an access token -- by not using any of the identification data -- but an access token cannot provide all the information needed for a full verification of the individual.
Access tokens are therefore smaller and faster, but less granular, than ID tokens. In general, access tokens are used for service-to-service flows, whereas ID tokens are used as initial verification of the user, with the access token being stored as a cookie on the client device for the duration of the session.
As an example of ID and access tokens, OpenID Connect (OIDC), which is built on OAuth, facilitates secure connections between clients and back-end services and then between the services themselves. An OIDC request should result in the creation of both an ID token and an access token. These tokens present as encrypted strings, which can be decrypted using the OIDC standard. These two tokens are similar but accomplish different tasks.
Minimize the use of API keys. Write applications to support the standards of OAuth and JWT. That way, different services can more simply interoperate with others using standard approaches. A proprietary approach to access tokens via APIs leaves room for error and creates issues both in continuing support and in future API updates.
API keys are less standard than tokens and tend to be used on a per-application basis.
Securing application workflows
With each approach, the system must allow for the automatic termination of used tokens. There should also be a means to force tokens to refresh where necessary, for example, where a session runs for too long. In certain circumstances, developers will also find a need for central administrators to rescind tokens to prevent individuals or groups from accessing a service or set of services.
The correct use of tokens makes life easier for the user: They do not have to remember a raft of different login combinations as they move from one service to another. Administrators have fewer worries, as the tokens are self-generated and temporary, which will lead to far fewer opportunities for malicious entities to break through the security layers. Help desk staff are better off, as there will be no "I've forgotten my password" calls.
To boost tokens' efficacy, use multifactor authentication (MFA), where a user's username and password are not the ultimate arbiter of the individual's identity. Instead, this is backed up either with a physical token such as an RSA key, an SMS or email message -- neither of which are recommended these days -- or a code generated by an authenticator app on the user's device.
Placing MFA and token-based access together into a single sign-on, such as available from Okta (which is acquiring Auth0 in 2021), Ping Identity and Centrify.
The need for better security is a never-ending struggle between developers and malicious entities. Users get caught in the middle of this -- and it is important to shield them from the complexities of process flow security. Token-based authentication helps do this.