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
You can register them as a single OAuth client that supports both grant types, or as two distinct clients. Using two distinct clients is recommended for production as it lets you apply least-privilege scopes to each and rotate them independently.
53
58
54
-
1. **Grant Types**: The OAuth client must support both:
55
-
- `authorization_code`- For user authentication and login flows
56
-
- `client_credentials`- For service-to-service authentication
59
+
**OAuth Client Requirements:**
57
60
58
-
2. **Token Format**: Configure the client to issue **JWT tokens** (not opaque tokens)
- Replace `<protocol>` with `http` or `https` and `<backstage-domain>` with your actual Backstage domain
67
+
4. **User Claims**: Configure the access token to include:
68
+
- `family_name`, `given_name`, `email`, `groups`
69
+
70
+
For the **service client**:
63
71
64
-
4. **User Claims**: Configure the access token to include the following claims:
65
-
- `family_name`- User's last name
66
-
- `given_name`- User's first name
67
-
- `email`- User's email address
68
-
- `groups`- Groups the user belongs to
72
+
1. **Grant Types**: `client_credentials`
73
+
2. **Token Format**: JWT tokens
69
74
70
75
**Helm Configuration:**
71
76
72
-
Once you have created the OAuth client, create/update a Backstage credentials secret and configure Backstage to use it:
77
+
Add both client secrets to the Backstage credentials Secret. If you are using a single shared client, set both `client-secret` and `service-client-secret` to the same value:
# Service client (client_credentials flow — background tasks)
99
+
serviceClientId: "your-service-client-id"
100
+
serviceClientSecretKey: "service-client-secret"
91
101
scope: ""
92
102
```
93
103
104
+
:::note
105
+
If `serviceClientId` is not set, it falls back to `clientId`. If `serviceClientSecretKey` is not set, it falls back to `client-secret`. This means existing single-client deployments require no changes.
| `backstage.auth.oidcScope` | Space-separated scopes requested during user login via the `authorization_code` flow | `"openid profile email"` |
99
-
| `backstage.auth.scope` | Space-separated scopes requested when the Backstage backend requests service tokens via `client_credentials`. Leave empty to use the IdP default, or set explicitly when required by your IdP (e.g. `"api://client-id/.default"` for Azure AD). | `""` |
| `backstage.auth.oidcScope` | Space-separated scopes requested during user login via the `authorization_code` flow (sign-in client) | `"openid profile email"` |
113
+
| `backstage.auth.scope` | Space-separated scopes requested when the service client fetches tokens via `client_credentials`. Leave empty to use the IdP default, or set explicitly when required by your IdP (e.g. `"api://client-id/.default"` for Azure AD). | `""` |
100
114
101
115
See [Identity Provider Configuration](./identity-configuration.mdx) for detailed setup instructions.
102
116
103
117
### Authorization
104
118
105
-
With authorization enabled by default, Backstage uses the `client_credentials` grant to authenticate with the OpenChoreo API as a service account. The API matches the `sub` claim in the issued JWT to identify the caller, so the new client must be granted the `backstage-catalog-reader` role via a bootstrap authorization mapping.
119
+
With authorization enabled by default, Backstage uses the `client_credentials` grant (via the service client) to authenticate with the OpenChoreo API as a service account. The API matches the `sub` claim in the issued JWT to identify the caller, so the service client must be granted the `backstage-catalog-reader` role via a bootstrap authorization mapping.
106
120
107
-
Add the following to your values override file, replacing `your-client-id` with the same client ID used in the authentication configuration above:
121
+
Add the following to your values override file, replacing `your-service-client-id` with the value of `backstage.auth.serviceClientId` (or `backstage.auth.clientId` if you are using a single shared client):
108
122
109
123
```yaml
110
124
openchoreoApi:
@@ -122,7 +136,7 @@ openchoreoApi:
122
136
kind: ClusterAuthzRole
123
137
entitlement:
124
138
claim: sub
125
-
value: "your-client-id"
139
+
value: "your-service-client-id"
126
140
effect: allow
127
141
```
128
142
@@ -216,28 +230,31 @@ backstage:
216
230
217
231
The chart sets the following environment variables on the Backstage container. Variables marked "from Secret" are read from the Secret referenced by `backstage.secretName`.
| `OPENCHOREO_SERVICE_CLIENT_ID` | Service client ID (client_credentials flow — background tasks) | `backstage.auth.serviceClientId` (falls back to `clientId`) |
244
+
| `OPENCHOREO_SERVICE_CLIENT_SECRET` | Service client secret | from Secret (key `backstage.auth.serviceClientSecretKey`, default: `client-secret`) |
- `jenkins-api-key`: Jenkins integration API key (use a placeholder if not using Jenkins)
286
303
304
+
Optional keys:
305
+
306
+
- `service-client-secret`: Service client secret (client_credentials flow). Required only when using a dedicated service client (`backstage.auth.serviceClientSecretKey: "service-client-secret"`). When not present, the service client falls back to `client-secret`.
307
+
287
308
When `backstage.database.type=postgresql`, the same Secret must also include:
0 commit comments