You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 2f4de99
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: app/spicedb/tutorials/federated-authorization/page.mdx
+21-2Lines changed: 21 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,14 @@ This tutorial illustrates how you can use SpiceDB to centralize permissions by m
9
9
The central idea is: don't point your resources at "the GitHub user" or "the Keycloak user."
10
10
Point them at an internal user you own, and bind each external account to it.
11
11
12
-

12
+

13
+
14
+
<Callouttype="info">
15
+
The full runnable demo for this tutorial lives in the [`authzed/examples`
16
+
repository](https://github.com/authzed/examples/tree/main/federated-authorization). It wires up
17
+
Keycloak, GitHub OAuth, SpiceDB, and PostgreSQL with Docker Compose, so you can run
18
+
`docker-compose up --build` and follow along against a live stack.
19
+
</Callout>
13
20
14
21
## Prerequisites
15
22
@@ -18,7 +25,7 @@ Point them at an internal user you own, and bind each external account to it.
18
25
- The [`zed` CLI](/spicedb/getting-started/installing-zed), pointed at your instance:
19
26
20
27
```sh
21
-
zed context set tutorial localhost:50051 "your-preshared-key" --insecure
28
+
zed context set tutorial localhost:50051 "demo-token-do-not-use-in-prod" --insecure
22
29
```
23
30
24
31
- An app that already authenticates users and can read each token's stable id: the `sub` claim for OIDC providers like Keycloak, the numeric account id for GitHub.
@@ -244,6 +251,16 @@ for resp in client.LookupResources(LookupResourcesRequest(
244
251
This uses SpiceDB's `LookupResources` API. Instead of asking "can this user view this document?", it answers "which documents can this user view?".
245
252
That returns everything reachable through any path (owner, editor, or viewer) without those rules living in your app.
246
253
254
+
## A note on persistence
255
+
256
+
The demo backs SpiceDB with PostgreSQL (`--datastore-engine=postgres`), with a one-shot `datastore migrate head` that runs before SpiceDB starts.
257
+
258
+
The bindings are the federation, so they have to outlive a restart.
259
+
If SpiceDB forgot `keycloak_account:9f3c #bound_to user:7b1e`, the next login would find nothing bound and mint a second `user:<uuid>` — the same failure the Step 2 warning guards against — and the first user's document grants would be stranded on the old id.
260
+
Persisting to Postgres is what keeps a returning user mapped to the same internal user, and their access, across restarts.
261
+
262
+
The app keeps its own user profiles and document metadata in a local SQLite database, but SpiceDB stays the source of truth for identity bindings and authorization.
263
+
247
264
## A note on consistency
248
265
249
266
The demo reads default to `minimize_latency`, which is fast but can be a few seconds stale.
@@ -256,3 +273,5 @@ See [Consistency](/spicedb/concepts/consistency) for the details.
256
273
257
274
This pattern is provider-agnostic: add a third IdP by adding one more `*_account` type, and nothing downstream changes.
258
275
To run this in production instead of a local container, provision a managed instance on [AuthZed Cloud](https://authzed.com/cloud/signup).
276
+
277
+
The [`authzed/examples` repository](https://github.com/authzed/examples/tree/main/federated-authorization) has the complete demo — schema, app, and the Docker Compose stack. You could also add a third IdP or point it at your own documents.
0 commit comments