Auth static token creation with OCI

[thepabloaguilar]

Hello, I'm trying to understand how I can enable static token and continue using OCI! For what I've understood when using OCI the Database is not used/ignored and the Cache is "irrelevant" as everything is already in memory and a believe for static token it should have a persistent storage

So, how can I setup that?

[GeorgeMac]

Hey @thepabloaguilar 👋

Probably the best mechanism to choose here would be the JWT authentication instead.
This method does not have any state storage requirements, but still appropriate for service to Flipt authentication.
You can setup with e.g. RSA key pairs where Flipt runs with the public keys and your clients use the private key parts.

Which language are you integrating with?

[markphelps]

Another thing to clarify

Hello, I'm trying to understand how I can enable static token and continue using OCI! For what I've understood when using OCI the Database is not used/ignored and the Cache is "irrelevant" as everything is already in memory and a believe for static token it should have a persistent storage

This is not entirely true as if you do enable static token authentication it requires a database, and if you add cache this will definitely make the requests faster as we cache tokens for auth as well

We only don't require a database if you are using non-DB storage AND do not enable authentication:

flipt/internal/cmd/authn.go

Lines 51 to 60 in 7620fe8

	// NOTE: we skip attempting to connect to any database in the situation that either the git, local, or object
	// FS backends are configured.
	// All that is required to establish a connection for authentication is to either make auth required
	// or configure at-least one authentication method (e.g. enable token method).
	if !cfg.Authentication.Enabled() && (cfg.Storage.Type != config.DatabaseStorageType) {
	return grpcRegisterers{
	public.NewServer(logger, cfg.Authentication),
	authn.NewServer(logger, storageauthmemory.NewStore()),
	}, nil, shutdown, nil
	}

flipt/internal/cmd/authn.go

Line 79 in 7620fe8

store = storageauthcache.NewStore(store, cacher, logger)

Related to what @GeorgeMac said, you can use JWT auth without a database but our current check does not allow that actually:

flipt/internal/cmd/authn.go

Line 55 in 7620fe8

if !cfg.Authentication.Enabled() && (cfg.Storage.Type != config.DatabaseStorageType) {

@GeorgeMac we should not try to connect to a DB if only the JWT auth method is used and non-DB storage is used

[GeorgeMac]

@markphelps we don’t cache token lookups and this is a good thing. If we did, we would have to make sure we only put the salted and hashed token in the cache, otherwise, it would be a vector for leaking credentials. Also, I’m not sure it would actually make anything noticeably faster. Since this operation is mostly just an indexed lookup in Postgres. Which if paged into memory I’d hope wouldn’t be much slower than redis. Both still require serializing over a network.

You’re right about the starting the db thing, this might be what sylwang observed. Looks like an oversight when we added JWT.

[GeorgeMac]

Oh I take it back we do. I don’t remember us adding that.

Finds PR and sees own approval 🤣

[GeorgeMac]

Hmmm not great practice that we store the tokens plain in redis. That just undoes the benefits of storing them hashed at rest in the db.
Also, not convinced it would be much of a speed improvement. But I see they were added during a load testing path, so I assume that was shown then and my assumption is mistaken.

[markphelps]

I created an issue to track the last point: #2972

[thepabloaguilar]

Got it @markphelps, but even if I use a cache to store the tokens I don't want to use it when OCI (or any declarative method) are being used! There's no way to make this separation rn, right? Like, saying the cache will only be used for auth stuff

[GeorgeMac]

Just to clarify, we actually don’t cache tokens.

[GeorgeMac]

Oh I take it back we do

[GeorgeMac]

But to definitely clarify (😂) the cache is only used to skip a database lookup. Its written through on read from the database. It doesn't use the cache for long term storage of tokens, that is always the database.

This is where JWT authentication is more preferrable as there is no storage necessary (other than putting signing keys in an env var).

[erka]

@thepabloaguilar is everything resolved for you? Or there is some blocker for you?

[thepabloaguilar]

Yea @erka, it resolved! It also clarify better my understanding of how things work!

[thepabloaguilar]

I saw the @GeorgeMac PR, maybe it also be good to put that in the docs, something like:

Note

If you're using any declarative storage the Database/Cache is not required as it'll not be used or will slow a bit the performance (the case of cache)
Also, you're not be able to use any auth method that requires storage (they'll be marked properly in the docs)

P.S.: This is just a simple example 😆

[markphelps]

Will do @thepabloaguilar !