🎿
API Key Authentication
The user is going to be logged in to a specific(required) tenant in Asset Service.
Request for an API key with a payload:
{
app_name: "scheduler",
...
}
Method - 1: JWT Token as API Key
API Key Authentication 1
Issuing Api Key:
Return a JWT token with a payload containing tenant-id (logged-in tenant),
app_name, etc.
JWT Payload
{
app_name : "scheduler",
tenant_id: "uuid",
user_id: "uuid" (logge
...
}
Validating Api Key:
From the scheduler, we will get a JWT token as a request header with the
name api-key.
In tenancy middleware, check for api-key header presence in request
headers.
If present
verify JWT, decode tenant-id from the payload and get the
tenant connection
If not
proceed with current logic to get tenant connection.
Pros:
No storage is required as we don’t store this JWT token in the DB.
Cons:
One-time Token, the user needs to create again if he loses the JWT token.
Expiration time.
Problem:
Need to check how to manage JWTAuthGaurd decorator, if the request comes
with only api-key?
solution :
API Key Authentication 2
From the scheduler, we will get the JWT token in the authorization header.
"Authorization": "api-key <jwt-token>"
In the tenancy middleware, we can check the authorization header.
If it contains “api-key”, fetch JWT and use it for the tenant connection.
else proceed with the current logic to get a tenant connection.
In JWTAuthGaurd
we can use multiple extractors to extract JWT.
Method - 2 : (Storing API Keys)
Issuing Api Key:
Maintain Application entity in public Schema to store generated API keys
and its tenant id etc.
{
id : "uuid",
app_name: "string",
tenant_id: "uuid",
permissions: "string[]",
api_key: "alpha_numeric_string"
}
when the user requests an API key,
store the generated API key and its details like logged-in tenant id, etc in
the application entity
Return api-key (not a JWT) in the response.
Validating Api Key:
From the scheduler, we will get a api_key as a request header with the name
api-key.
In tenancy middleware, check for api-key header presence in request
headers.
If present
API Key Authentication 3
verify whether the API key is present in the application table,
and get the tenant id from the database for the tenant
connection.
If not
proceed with current logic to get tenant connection.
Pros:
No expiry time.
The user can get the same API key again from the asset service console if
he lost it.
Cons:
stored api keys can be stolen from the database.
Extra query is needed to get a tenant connection.
Problem: [SOLVED]
Need to check how to manage the JWTAuthGaurd decorator, if the request
comes with an api-key but without a JWT token in the authorization header?
Method -3 : (Hashing Stored API Keys)
Issuing Api Key :
Maintain Application entity in public Schema.
{
id : "uuid", //api-key
app_name: "string",
tenant_id: "uuid",
permissions: "string[]",
api_key: "hashed_key"
}
store hashed value of api-key
Return the raw api-key (not a JWT) in the response.
Validating Api Key:
we will get a raw api token as a header with the name api-key.
API Key Authentication 4
In tenancy middleware, check for api-key header presence in request
headers.
If present
verify by hashing the raw API key in the request and compare
the hashed key with the hash stored within our database
Get the tenant id from the database for the tenant connection
If not
proceed with current logic to get tenant connection.
Pros:
No expiry time.
No unauthorized access can steal our API keys.
Cons:
One-time Token, the user needs to create again if he loses the raw API
token as we are storing hashed keys
Problem: [SOLVED]
Need to check how to manage the JWTAuthGaurd decorator, if the request
comes with an api-key but without a JWT token in the authorization header?
API Key Authentication 5
