Summary
Session tokens are currently identified by a bend-v1- prefix in the Bearer token string (e.g. bend-v1-s-..., bend-v1-r-...). This is a fragile convention that couples token routing to token content.
Proposal
Use a dedicated HTTP header (e.g. X-DATABEND-AUTH-METHOD: session) to distinguish session tokens from other Bearer tokens (JWT, key-pair), consistent with how key-pair auth uses X-DATABEND-AUTH-METHOD: keypair.
This would:
- Decouple token format from routing logic
- Make the auth dispatch in
session.rs cleaner and more extensible
- Align all auth methods under a single header-based dispatch model
Current behavior
// src/query/service/src/servers/http/middleware/session.rs
if SessionClaim::is_databend_token(&token) { // checks bend-v1- prefix
...
} else if is_keypair { // checks X-DATABEND-AUTH-METHOD header
...
} else {
// JWKS JWT
}Context
Noticed during key-pair auth implementation (#19786) — the header-based approach for key-pair is cleaner than the prefix-based approach for session tokens.
Summary
Session tokens are currently identified by a
bend-v1-prefix in the Bearer token string (e.g.bend-v1-s-...,bend-v1-r-...). This is a fragile convention that couples token routing to token content.Proposal
Use a dedicated HTTP header (e.g.
X-DATABEND-AUTH-METHOD: session) to distinguish session tokens from other Bearer tokens (JWT, key-pair), consistent with how key-pair auth usesX-DATABEND-AUTH-METHOD: keypair.This would:
session.rscleaner and more extensibleCurrent behavior
Context
Noticed during key-pair auth implementation (#19786) — the header-based approach for key-pair is cleaner than the prefix-based approach for session tokens.