JSON bearer tokens in HTTP request headers #163

New issue

Open

opened 2024-11-14 09:31:52 +00:00 by potyarkin · 1 comment

potyarkin commented

2024-11-14 09:31:52 +00:00

Member

FrostFS SDK supports two serialization formats for bearer tokens:

Raw protobuf binary form
JSON encoded tokens

Most FrostFS tools consider these variants equal and are able to handle serialized tokens in either format, e.g. frostfs-cli.

frostfs-http-gw accepts only base64 encoded protobuf binaries, and does not support JSON bearer tokens:

 		if buf = parse(&ctx.Request.Header); buf == nil {
 			continue
 		} else if data, err := base64.StdEncoding.DecodeString(string(buf)); err != nil {
 			lastErr = fmt.Errorf("can't base64-decode bearer token: %w", err)
 			continue
 		} else if err = tkn.Unmarshal(data); err != nil {
 			lastErr = fmt.Errorf("can't unmarshal bearer token: %w", err)
 			continue
 		}

I think we should discuss whether adding support for JSON bearer tokens to frostfs-http-gw makes sense.

Pros:

JSON tokens are much more human friendly (operator can view token fields without using any special tools).

Cons:

JSON tokens will still need to be base64 encoded for including in HTTP headers to avoid problems with unexpected Unicode characters
JSON serialized objects are always larger than protobuf binaries (even after compacting whitespace). This will make HTTP header even longer

I'm writing an application which uses bearer tokens for access to FrostFS container. Originally I was using JSON for on-disk token format because it's more human friendly and easier to debug/troubleshoot.

In my use case I needed to expose some objects via HTTP endpoint - and then I've found out that JSON tokens will not work with frostfs-http-gw. I've switched to protobuf binaries for on-disk format, so I'm not blocked in any way. But now I need a separate tool to view token fields whenever I'm troubleshooting access issues.

Describe the solution you'd like

Add support for JSON bearer tokens is HTTP request headers. This might be useful to third party app developers.

Describe alternatives you've considered

Leave token parser as is. After all, protobuf tokens work and are not that much of a hassle.

FrostFS SDK supports two serialization formats for bearer tokens: - Raw [protobuf binary](https://pkg.go.dev/git.frostfs.info/TrueCloudLab/frostfs-sdk-go@v0.0.0-20241113074125-afdc2d8340bb/bearer#Token.Marshal) form - [JSON encoded](https://pkg.go.dev/git.frostfs.info/TrueCloudLab/frostfs-sdk-go@v0.0.0-20241113074125-afdc2d8340bb/bearer#Token.MarshalJSON) tokens Most FrostFS tools consider these variants equal and are able to handle serialized tokens in either format, e.g. [frostfs-cli](https://git.frostfs.info/TrueCloudLab/frostfs-node/src/commit/d77a218f7c1a449369eb6d63e00ae1906984aed4/cmd/frostfs-cli/internal/common/token.go#L42-L66). frostfs-http-gw accepts only base64 encoded protobuf binaries, and does not support JSON bearer tokens: https://git.frostfs.info/TrueCloudLab/frostfs-http-gw/src/commit/d5b92446bd34ef518f5687b2c607efadbf1ff8d6/tokens/bearer-token.go#L85-L93 I think we should discuss whether adding support for JSON bearer tokens to frostfs-http-gw makes sense. Pros: - JSON tokens are much more human friendly (operator can view token fields without using any special tools). Cons: - JSON tokens will still need to be base64 encoded for including in HTTP headers to avoid problems with unexpected Unicode characters - JSON serialized objects are always larger than protobuf binaries (even after compacting whitespace). This will make HTTP header even longer ## Is your feature request related to a problem? Please describe. I'm writing an application which uses bearer tokens for access to FrostFS container. Originally I was using JSON for on-disk token format because it's more human friendly and easier to debug/troubleshoot. In my use case I needed to expose some objects via HTTP endpoint - and then I've found out that JSON tokens will not work with frostfs-http-gw. I've switched to protobuf binaries for on-disk format, so I'm not blocked in any way. But now I need a separate tool to view token fields whenever I'm troubleshooting access issues. ## Describe the solution you'd like Add support for JSON bearer tokens is HTTP request headers. This might be useful to third party app developers. ## Describe alternatives you've considered Leave token parser as is. After all, protobuf tokens work and are not that much of a hassle.

potyarkin referenced this issue from TrueCloudLab/frostfs-node

2024-11-14 10:50:02 +00:00

View bearer token in human readable format #1498

alexvanin commented

2024-11-14 14:24:41 +00:00

Owner

I think the size of the JSON was the issue last time we talked about it.

Since then allowImpesonate flag was introduced, which provides very short bearer tokens.

On the other hand, bearer tokens with APE require binary encoded data anyway (see APEOverride -> Chains -> Raw).

Also JSON looks very weird in HTTP header, however cookies may store JSON token just fine.

I have no strong opinions for or against. If it makes someones life easier, we can do it.

I think the size of the JSON was the issue last time we talked about it. Since then `allowImpesonate` flag was introduced, which provides very short bearer tokens. On the other hand, bearer tokens with APE require binary encoded data anyway (see [APEOverride](https://git.frostfs.info/TrueCloudLab/frostfs-api/src/commit/4c51a9b9d63e53ca0b430d9e4aa6d7e692465821/acl/types.proto#L238) -> Chains -> [Raw](https://git.frostfs.info/TrueCloudLab/frostfs-api/src/commit/4c51a9b9d63e53ca0b430d9e4aa6d7e692465821/ape/types.proto#L31)). Also JSON looks very weird in HTTP header, **however** cookies may store JSON token just fine. I have no strong opinions for or against. If it makes someones life easier, we can do it.