|
5 | 5 | SpacetimeAuth is a service for managing authentication for your SpacetimeDB |
6 | 6 | applications. This allows you to authenticate users without needing |
7 | 7 | an external authentication service or even a hosting server. |
8 | | -SpacetimeAuth is an OpenID Connect (OIDC) provider, which means it can be used with |
| 8 | +SpacetimeAuth is an [OpenID Connect (OIDC)](https://openid.net/developers/how-connect-works/) provider, which means it can be used with |
9 | 9 | any OIDC-compatible client library. |
10 | 10 |
|
11 | 11 | At the end of the authentication flow, your application receives an ID token |
12 | | -containing identity claims (such as email, username, and roles). This token can |
13 | | -then be used with any SpacetimeDB SDK to authenticate and authorize users. |
| 12 | +containing identity claims (such as email, username, and roles). Your |
| 13 | +application can then use this token with any SpacetimeDB SDK to authenticate and |
| 14 | +authorize users with the SpacetimeDB server. |
14 | 15 |
|
15 | 16 | ## Features |
16 | 17 |
|
@@ -72,15 +73,21 @@ more roles assigned to them. |
72 | 73 |
|
73 | 74 | > ⚠️ Clients must not be confused with Users. |
74 | 75 |
|
75 | | -Clients (from OpenID Connect) are the applications that will be using |
76 | | -SpacetimeAuth for authentication. Each client is associated with a single |
77 | | -project and has its own client ID and client secret. |
| 76 | +Clients, also known as Relying Parties in OpenID Connect terminology, are the |
| 77 | +applications that are relying on SpacetimeAuth for authentication. Each client |
| 78 | +is associated with a single project and has its own client ID and client |
| 79 | +secret. |
| 80 | + |
| 81 | +Clients are applications that request an OpenID Connect ID token from |
| 82 | +SpacetimeAuth, which can then be used to authenticate with the SpacetimeDB |
| 83 | +server. |
78 | 84 |
|
79 | 85 | ### Roles |
80 | 86 |
|
81 | 87 | Roles are used to manage access control within your application. Each role is |
82 | 88 | represented by a string (e.g. "admin", "user") that can be assigned to one or |
83 | 89 | more users. |
| 90 | + |
84 | 91 | Roles are included as claims in the ID token that is issued to the user upon |
85 | 92 | authentication. |
86 | 93 |
|
|
0 commit comments