Optional compression for bearer tokens

[bogbert]

When using enable-compress-token: true without encryption (enable-encrypted-token: false,
force-encrypted-cookie: false), bearer tokens obtained directly from Keycloak
(e.g. via Authorization: Bearer <token>) are rejected by gatekeeper (gatekeeper expects compressed token)

Configuration to reproduce

enable-compress-token: true
enable-encrypted-token: false
force-encrypted-cookie: false

What happens

1. Client obtains an access token directly from Keycloak
2. Client sends request with Authorization: Bearer <raw_token>
3. Gatekeeper calls DecompressToken on the raw (uncompressed) bearer token
4. Error: gzip: invalid header → request rejected

Root cause

pkg/proxy/session/token.go, GetIdentity, the compressedOnly branch does not distinguish between bearer tokens and cookie tokens:

if enableEncryptedToken || forceEncryptedCookie && !isBearer {
    // decrypt path ( applied to cookie tokens when forceEncryptedCookie is used)
} else if enableCompressToken {
    // applied to ALL tokens including bearer tokens from Keycloak
    token, err = DecompressToken(token)
    if err != nil {
        return "", errors.Join(apperrors.ErrDecompressToken, err)
    }
}

Proposed fix

Add && !isBearer to the else if enableCompressToken condition, mirroring the encryption path:

} else if enableCompressToken && !isBearer {
    // Only decompress cookie tokens, never bearer tokens
    token, err = DecompressToken(token)
    if err != nil {
        return "", errors.Join(apperrors.ErrDecompressToken, err)
    }
}

Note on operator precedence (reported by Claude)

The existing test

if enableEncryptedToken || forceEncryptedCookie && !isBearer {

is evaluated as enableEncryptedToken || (forceEncryptedCookie && !isBearer) due to Go operator precedence (&& binds tighter than ||). This means when enableEncryptedToken=true, bearer tokens enter the decrypt block of
!isBearer. The enableOptionalEncryption fallback masks this for the encryption case. The intended expression is likely:

if (enableEncryptedToken || forceEncryptedCookie) && !isBearer {

[p53]

@bogbert hi thanks for opening issue, but described behaviour is intended, you probably want new feature aka --enable-optional-compression

[p53]

Actually I wasn't very happy with optional encryption feature as it makes things less clear and lowers security...

[bogbert]

I suppose "optional" encryption or "optional" compression would be configurations where gatekeeper accepts encrypted/compressed as well as not encrypted/not compressed tokens.
Regarding the configuration parameters enable-encrypted-token and force-encrypted-cookie, their naming is a bit confusing, I think most users (including myself) will think the 2nd one will apply (or require) encryption in more cases (because of the word "force"), while in fact, if I understand correctly, we should ignore the word "force" and rather pay attention to the words "token" vs "cookie" in the parameter names. The fist parameter wants encryption for all tokens (bearer tokens and cookies) while the second one only for cookies.
So what I would want is rather enable-compress-cookie (or force-compress-cookie to follow the current naming scheme).
In my use cases, bearer tokens are always used in headless calls, where the access token is obtained directly from Keycloak by the client (so it's not encrypted nor compressed).

[p53]

ah ok, understand now your use case (some names are historical project things...), hmm i will need to think about it from perspective of security it would be probably better to have --force-compress-cookie so that scope is clear, but what if somebody will have opposite use case: encrypted bearers and not encrypted cookies, less probable. By the way do you know that you can use gatekeeper as forwarding-proxy, means gatekeeper will fetch access tokens for you and refresh them, only thing is that right now it has only HMAC signatures functionality not encryption/compression, maybe it would be nice to add them there too...

[p53]

Actually when I think about it you probably would like to enable compression/encryption per path because I guess you have frontend and API on different paths

[p53]

as encryption/compression per path would require significant refactor probably force-compress-cookie would be way to go for now

[bogbert]

Actually, I would have no use for compression/encryption per path. The same APIs can be used either from an interactive session or by headless scripts. What really matters (for me) is the way the token is passed (cookie or bearer)

[p53]

@bogbert 4.8.0-rc1, added option --compress-token-only-auth-scheme, allowed values are empty string, cookie, bearer