Token or API Key?

6 min readOct 23, 2023

Token

Token is kind of password for the stateless http APIs. So If I have one token can I use it whenever I want to access any resource?

Token is valid for short term only and its system generated so no need to remember it like password.

Advantages of Token Based Authentication

Improves scalability of the servers, implements loosely coupled systems and is mobile friendly.

Terms related to token validation

Authorization server. A server that gives out access tokens.

Resource. Some piece of data that can be protected.

Resource server. The server that hosts the resource.

Resource owner. The entity that can grant permission to access a resource. (Typically the user.)

Client: The app that wants access to the resource. for example a web browser.

Different types of tokens are used in different usage scenario.

Here is the confusing list of tokens.

. Access tokens

· ID tokens

· Self-signed JWTs

· Refresh tokens

· Federated tokens

· Bearer tokens

Bearer tokens

Bearer tokens are a general class of token that grants access to the party in possession of the token.

Access tokens, ID tokens, and self-signed JWTs are all bearer tokens.

A bearer token means that the bearer (who holds the access token) can access authorized resources. Use HTTPS to security. It should have short expiration times.

Access tokens

To get access to some resource, you need access token. It conforms to the OAuth 2.0 framework.

Access token lifetime: By default, access tokens are good for 1 hour (3,600 seconds). When the access token has expired, your token management code must get a new one.

Token expired/user not authenticated: ‘401 — Unauthorized (invalid credentials)’ error is returned.

It consists of the header, the payload, and the signature. In the payload, claims are defined. Claims are attributes describing the resource owner, privileges, groups, token type, token expiration, encoding algorithm, and more.

Access Token Best Practices

· Keep the signing key secret and reveal it only to services that require it.

· Exclude sensitive data from the payload: Tokens are signed but can be decoded.

· Use as few claims as possible

· Set the expiration time for tokens and make sure their signing keys are revokable.

· Send tokens over HTTPS connections.

· Use refresh tokens, which allow the client to acquire new access tokens.

· Validate your JWTs with middleware.

ID tokens

ID tokens are JWTs that conform to the OpenID Connect (OIDC) specification. ID tokens are valid for up to 1 hour (3,600 seconds). When an ID token expires, you must acquire a new one.

ID Tokens contain claims about a user’s identity, such as their username, email, etc. Access Tokens are used to grant applications permission to access server resources on behalf of the user. Always validate ID tokens before use.

Refresh tokens

By default, access tokens and ID tokens are valid for 1 hour. A refresh token is a special token that is used to obtain additional access tokens or ID tokens. When your application first authenticates, it receives an access token or ID token, as well as a refresh token. Later, if the application needs to access resources again, and the previously provided token has expired, it uses the refresh token to request a new token. After 336 hours (14 days) of inactivity it expires. This cycle can continue for up to 90 days after which the user must log in again.

A refresh_token should be revoked:

· If a user is no longer permitted to make requests on the API, or

· If the access_token or refresh_token have been compromised.

Signed Token

A signature is something that can be checked or verified. The signature helps ensure that the data in the header and payload segments haven’t been tampered with, and the JWT can be trusted. JWT tokens are digitally signed (the signature part) using the payload content and a secret key.

Signing the token with public key and private key.

X.509 SSL Certificates can be used to sign and verify JWT tokens

Federated Identity

Federated identity is a way to use an account from one website to create an account and log in to a different site.

OpenID

OpenID was created for federated authentication, that is, letting a third-party authenticate your users for you, by using accounts they already have.

OAuth

OAuth was created to remove the need for users to share their passwords with third-party applications.

API key

API key authentication uses API keys to authenticate the applications or services that access your APIs. An API key is a token or unique identifier that is passed to an API via request header, cookie, or query string.

API keys can be used to control which applications may access your API, track their usage patterns, or restrict which methods of your API they can use. However, API keys are insufficient for secure authorization.

API keys provide

Project identification — Identify the application or the project that’s making a call to this API

Project authorization — Check whether the calling application has been granted access to call the API and has enabled the API in their project

API keys aren’t as secure as authentication tokens (see Security of API keys), but they identify the application or project that’s calling an API. They are generated on the project making the call, and you can restrict their use to an environment such as an IP address range, or an Android or iOS app.

By identifying the calling project, you can use API keys to associate usage information with that project.

API key use cases and best practices

An API may restrict some or all of its methods to require API keys.
You do want to block anonymous traffic. API keys identify an application’s traffic for the API producer, in case the application developer needs to work with the API producer to debug an issue or show their application’s usage.
You want to control the number of calls made to your API.
You want to identify usage patterns in your API’s traffic. You can see application usage in APIs & services.
You want to filter logs by API key.
API keys control access to specific application features and are used for restricting anonymous traffic, rate limiting and data analysis.
There are two main types of API keys: Public, for accessing public data, and Private, for server-to-server communications.
Proper handling of API keys includes not embedding them in code, using different keys for applications, rotating them regularly, and deleting unused keys.
Common errors when working with APIs can include invalid or missing keys, and testing involves authentication, rate-limiting, permission, data integrity, and security checks.
Correct management of API keys is vital for meeting regulatory compliance standards like GDPR in Europe, HIPAA in healthcare, and CCPA in California.
Use a different API key for each application: Each application that uses an API should have its own unique API key. This helps to ensure that if one application is compromised, the other applications will not be affected
Delete unused API keys: Keys that are no longer in use should be deleted to prevent them from being used by attackers. Unused keys may mistakenly be left in code posted online or in configuration files that are accidentally committed to version control.
Proper management of API keys includes logging, monitoring their usage, encrypting keys in transit and at rest, and rotating them regularly
Prompt notification of data breaches
API keys cannot be used for identifying and authorizing individual users — API keys don’t identify users, they identify projects.