CODEWITHSUNDEEP
javaopenid-connectquarkus
Martin Lowe
Martin Lowe

Reputation: 11

How to share OIDC auth state across containers in Quarkus

I've been looking into synchronizing OIDC auth state across pods in an authenticated Quarkus app. This is to remove the need for sticky sessions and keep things in sync as the request bounces around the server.

There is a solution for this when using standard login using the quarkus.http.auth.session.encryption-key property, but nothing for OIDC from what I can tell. Looking into the Authentication Mechanism reauthentication and the Default Token Manager implementation I can accomplish this by syncing a few of the state tokens across a memcache or DB connection, namely the refresh and access tokens. This could be matched on the idToken value that is generated in the token state manager to keep things lined up properly.

The plan for implementation would be to add a DTO/table to an existing DB connection. I would add a high-priority filter or auth mechanism that checks cache if the state isn't set then check db for existing data. For an auth mechanism implementation, I would fall back to default/super if no state or cookie exists.

Am I overcomplicating this and there's a package that manages this, or is this the solution for the issue? Any feedback would be appreciated!

Upvotes: 1

Views: 573

Answers (1)

Gary Archer
Gary Archer

Reputation: 29218

It feels like you are doing too much plumbing, much of which should be avoidable if you make the right design choices.

It would help if you described what your application / business scenario was rather than starting with technology, but here are some general principles.

AUTH STATE

This is most commonly managed by the Authorization Server (AS). Multiple instances of the AS store shared state in the same database. The AS deals with the difficult plumbing so that you should not need to create your own token stores.

APIS AND CLIENTS

These just use JWTs by default and are very easy to manage. Web clients are a special case and may need to wrap tokens in secure cookies.

PUTTING IT ALL TOGETHER

Have a look at these recent resources from Curity, which I hope demonstrate a simple architecture.

  • Docker Compose File stores Auth state in the postgres database, but the only thing you need to do is deploy the Curity database
  • Code for Web App + API are very simple due to externalising security
  • Article explains the design patterns and layering

In this standard Web / API solution the browser uses OIDC tokens in AES256 encrypted HTTP Only SameSite=strict cookies, meaning the back end uses stateless storage of OAuth data and any type of back end clustering works without issues.

SUMMARY

All I wanted to achieve via the above answer is to encourage simplicity - which can scale to global systems if needed. Happy to answer follow up questions if it helps.

Upvotes: 1

Related Questions