Better explain the design decisions for auth - #1179
Conversation
Signed-off-by: Juan Cruz Viotti <jv@jviotti.com>
🤖 Augment PR SummarySummary: This PR refines the auth docs to better explain the stateless, cookie-based OIDC session design. Changes:
🤖 Was this summary useful? React with 👍 or 👎 |
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
| None of it is stored. Every credential is checked as it arrives, against the | ||
| environment or against the issuer's published key set, and a session is a sealed | ||
| value the instance keeps no record of, so any replica verifies any of them on | ||
| its own without a lookup. That is what lets an instance scale horizontally, and |
There was a problem hiding this comment.
docs/configuration.md:342 — The claim that replicas verify credentials “without a lookup” seems too strong for jwt/oidc, since key material/provider metadata may still be fetched on cache miss/refresh. Consider clarifying this as “no server-side session/state lookup” to avoid implying zero network lookups.
Severity: low
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| same response as any other unauthenticated request. | ||
| same response as any other unauthenticated request. Only the issuer can revoke | ||
| one, and never before it expires, since nothing here asks the issuer whether a | ||
| subject is still welcome: the token lifetimes it mints are what bound exposure. |
There was a problem hiding this comment.
docs/configuration.md:482 — “Only the issuer can revoke one, and never before it expires” may be inaccurate in practice (e.g., issuer key rotation/removal can invalidate still-unexpired JWTs). It might be worth qualifying this as “this instance does not perform introspection/blacklisting, so expiry bounds exposure”.
Severity: low
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| out. Signing out takes the session from the browser, so a copy taken beforehand | ||
| stays usable until it expires. Ending every session at once means changing the | ||
| policy's session secret and restarting, which is the only immediate lever there | ||
| is. There is deliberately no OpenID Connect Back-Channel Logout, since acting on |
There was a problem hiding this comment.
docs/configuration.md:582 — “Changing the policy’s session secret” could be read as adding a new secret, but the implementation supports multiple sessionSecrets where adding a new one does not immediately invalidate existing sessions. If the intent is “end every session at once”, it may help to explicitly say the old secrets must be removed (and the instance restarted) so previously minted cookies stop verifying.
Severity: medium
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Benchmark Index (community)
Details
| Benchmark suite | Current: 5de02e1 | Previous: 4ff0741 | Ratio |
|---|---|---|---|
Add one schema (0 existing) |
298 ms |
314 ms |
0.95 |
Add one schema (100 existing) |
27 ms |
24 ms |
1.13 |
Add one schema (1000 existing) |
88 ms |
73 ms |
1.21 |
Add one schema (10000 existing) |
987 ms |
639 ms |
1.54 |
Update one schema (1 existing) |
18 ms |
17 ms |
1.06 |
Update one schema (101 existing) |
30 ms |
24 ms |
1.25 |
Update one schema (1001 existing) |
99 ms |
77 ms |
1.29 |
Update one schema (10001 existing) |
819 ms |
640 ms |
1.28 |
Cached rebuild (1 existing) |
5 ms |
5 ms |
1 |
Cached rebuild (101 existing) |
6 ms |
6 ms |
1 |
Cached rebuild (1001 existing) |
21 ms |
20 ms |
1.05 |
Cached rebuild (10001 existing) |
176 ms |
173 ms |
1.02 |
Index 100 schemas |
597 ms |
387 ms |
1.54 |
Index 1000 schemas |
1293 ms |
1234 ms |
1.05 |
Index 10000 schemas |
14313 ms |
11301 ms |
1.27 |
Index 10000 schemas (custom meta-schema) |
16758 ms |
14394 ms |
1.16 |
Index 10000 schemas ($ref fan-out) |
16732 ms |
14188 ms |
1.18 |
This comment was automatically generated by workflow using github-action-benchmark.
There was a problem hiding this comment.
Benchmark Index (enterprise)
Details
| Benchmark suite | Current: 5de02e1 | Previous: 4ff0741 | Ratio |
|---|---|---|---|
Add one schema (0 existing) |
422 ms |
313 ms |
1.35 |
Add one schema (100 existing) |
106 ms |
157 ms |
0.68 |
Add one schema (1000 existing) |
164 ms |
635 ms |
0.26 |
Add one schema (10000 existing) |
890 ms |
734 ms |
1.21 |
Update one schema (1 existing) |
98 ms |
78 ms |
1.26 |
Update one schema (101 existing) |
105 ms |
80 ms |
1.31 |
Update one schema (1001 existing) |
165 ms |
134 ms |
1.23 |
Update one schema (10001 existing) |
828 ms |
736 ms |
1.13 |
Cached rebuild (1 existing) |
9 ms |
5 ms |
1.80 |
Cached rebuild (101 existing) |
11 ms |
6 ms |
1.83 |
Cached rebuild (1001 existing) |
32 ms |
18 ms |
1.78 |
Cached rebuild (10001 existing) |
267 ms |
144 ms |
1.85 |
Index 100 schemas |
666 ms |
597 ms |
1.12 |
Index 1000 schemas |
1617 ms |
1104 ms |
1.46 |
Index 10000 schemas |
14163 ms |
12830 ms |
1.10 |
Index 10000 schemas (custom meta-schema) |
17189 ms |
13782 ms |
1.25 |
Index 10000 schemas ($ref fan-out) |
17196 ms |
16617 ms |
1.03 |
This comment was automatically generated by workflow using github-action-benchmark.
1 participant
Signed-off-by: Juan Cruz Viotti jv@jviotti.com