Fix OIDC docs to include the entire space ID.

The JWTs issued by Spacelift actually contain the entire space ID, not
just the name. This means that the previously documented conditions for
AWS and Azure do not match the actual `sub`.

For example, following the old example to restrict the role to a
particular space by name:

```
"StringLike": {
  "demo.app.spacelift.io:sub": "space:production:*"
}
```

This does not match the actual JWT subject, which looks like this:

```
space:production-01HND497T9JKR76MR3KA2CDJHP:stack:my-stack:run_type:PROPOSED:scope:read
```

I'm not sure if this ID format changed at some point. (Maybe
historically space IDs did not have a random suffix?) From what I can
see, all spaces have a random ID except the special root space (ID
`root`).

The docs page for GCP seems to correctly show the full space ID already.

Author: ab

docs/integrations/cloud-providers/oidc/README.md

@@ -66,7 +66,7 @@ The token contains the following standard claims:
 
 - `iss`: The issuer of the token. This is the URL of your Spacelift account, for example `https://demo.app.spacelift.io`, and is unique for each Spacelift account.
 - `sub`: The subject of the token, which includes some information about the Spacelift run that generated this token.
-    - The subject claim is constructed as follows: `space:<space_id>:(stack|module):<stack_id|module_id>:run_type:<run_type>:scope:<read|write>`. For example, `space:legacy:stack:infra:run_type:TRACKED:scope:write`. Individual values are also available as separate [custom claims](#custom-claims).
+    - The subject claim is constructed as follows: `space:<space_id>:(stack|module):<stack_id|module_id>:run_type:<run_type>:scope:<read|write>`. For example, `space:legacy-01KJMM56VS4W3AL9YZWVCXBX8D:stack:infra:run_type:TRACKED:scope:write`. Individual values are also available as separate [custom claims](#custom-claims).
 - `aud`: The audience of the token. This is the hostname of your Spacelift account, for example `demo.app.spacelift.io`, and is unique for each Spacelift account.
 - `exp`: The expiration time of the token, in seconds since the Unix epoch. The token is valid for one hour.
 - `iat`: The time at which the token was issued, in seconds since the Unix epoch.

docs/integrations/cloud-providers/oidc/aws-oidc.md

@@ -59,11 +59,11 @@ If you go to your new role's details page, in the _Trust relationships_ section
 
 ![Trust relationship](<../../../assets/screenshots/oidc/aws-iam-trust-relationship.png>)
 
-This trust relationship is very relaxed and will allow any stack or module in the `demo` Spacelift account to assume this role. If you want to be more restrictive, you will want to add more conditions. For example, we can restrict the role to be only assumable by stacks in the `production` space by adding the following condition:
+This trust relationship is very relaxed and will allow any stack or module in the `demo` Spacelift account to assume this role. If you want to be more restrictive, you will want to add more conditions. For example, we can restrict the role to be only assumable by stacks in the `production` space (with space ID `production-01HND497T9JKR76MR3KA2CDJHP`) by adding the following condition:
 
 ```json
 "StringLike": {
-  "demo.app.spacelift.io:sub": "space:production:*"
+  "demo.app.spacelift.io:sub": "space:production-01HND497T9JKR76MR3KA2CDJHP:*"
 }
 ```
 
@@ -80,6 +80,11 @@ You can also restrict the role so only a specific stack can assume it, using the
 
 You can mix and match these to get the exact constraints you need. You can learn more about the intricacies of AWS IAM conditions in the [official docs](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html){: rel="nofollow"}. Remember that AWS does not seem to support custom claims, so you will need to use the standard ones to do the matching (primarily `sub`, as shown above).
 
+The full `sub` is constructed as follows:
+
+* Format: `space:<space_id>:(stack|module):<stack_id|module_id>:run_type:<run_type>:scope:<read|write>`
+* For example: `space:legacy-01KJMM56VS4W3AL9YZWVCXBX8D:stack:infra:run_type:TRACKED:scope:write`
+
 ## Configure the Terraform provider
 
 Once the Spacelift-AWS OIDC integration is set up, the Terraform provider can be configured without the need for any static credentials. The `aws_role_arn` variable should be set to the ARN of the role that you want to assume:

docs/integrations/cloud-providers/oidc/azure-oidc.md

@@ -43,21 +43,21 @@ Take a look at the following screenshot for an example allowing a proposed run t
 
 Workload federation in Azure requires the subject claim of the OIDC token to exactly match the federated credential, and doesn't allow wildcards. Because of this you will need to repeat the same process and add a number of different federated credentials in order to support all the different types of runs for your Stack or module.
 
-For example, for a stack called `azure-oidc-test` in the `legacy` space you need to add credentials for the following subjects:
+For example, for a stack called `azure-oidc-test` in the `legacy` space (with space ID `legacy-01KJMM56VS4W3AL9YZWVCXBX8D`) you need to add credentials for the following subjects:
 
 ```text
-space:legacy:stack:azure-oidc-test:run_type:TRACKED:scope:read
-space:legacy:stack:azure-oidc-test:run_type:TRACKED:scope:write
-space:legacy:stack:azure-oidc-test:run_type:PROPOSED:scope:read
-space:legacy:stack:azure-oidc-test:run_type:TASK:scope:write
-space:legacy:stack:azure-oidc-test:run_type:DESTROY:scope:write
+space:legacy-01KJMM56VS4W3AL9YZWVCXBX8D:stack:azure-oidc-test:run_type:TRACKED:scope:read
+space:legacy-01KJMM56VS4W3AL9YZWVCXBX8D:stack:azure-oidc-test:run_type:TRACKED:scope:write
+space:legacy-01KJMM56VS4W3AL9YZWVCXBX8D:stack:azure-oidc-test:run_type:PROPOSED:scope:read
+space:legacy-01KJMM56VS4W3AL9YZWVCXBX8D:stack:azure-oidc-test:run_type:TASK:scope:write
+space:legacy-01KJMM56VS4W3AL9YZWVCXBX8D:stack:azure-oidc-test:run_type:DESTROY:scope:write
 ```
 
-And for a module called `my-module` in the `development` space you need to add the following:
+And for a module called `my-module` in the `development` space (with space ID `development-01JS2ABCDEFGHIJK123456789`) you need to add the following:
 
 ```text
-space:development:stack:my-module:run_type:TESTING:scope:read
-space:development:stack:my-module:run_type:TESTING:scope:write
+space:development-01JS2ABCDEFGHIJK123456789:stack:my-module:run_type:TESTING:scope:read
+space:development-01JS2ABCDEFGHIJK123456789:stack:my-module:run_type:TESTING:scope:write
 ```
 
 After adding all the credentials for a stack, it should look something like this: