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
feat: add JSON object support for ctx field in bearer token and signed data token generation
Extend the Java SDK's bearer token and signed data token generation to accept
a JSON object (Map<String, Object>) for the ctx field, in addition to the
existing String type. This enables structured context for conditional data
access policies where ctx object keys map to Skyflow CEL policy variables
(e.g., request.context.role, request.context.department).
Changes:
- Credentials: widen context field from String to Object, add overloaded
setContext(Map<String, Object>)
- BearerToken/SignedDataTokens: widen ctx to Object, add overloaded
setCtx(Map<String, Object>), conditionally include ctx in JWT claims
- Utils: dispatch to correct setCtx overload based on context type
- Validations: validate both String and Map context types, validate map keys
match [a-zA-Z0-9_]+ for CEL compatibility
- ErrorMessage/ErrorLogs: add InvalidContextType and InvalidContextMapKey
- Tests: add Map-based context tests for Credentials, BearerToken, and
SignedDataTokens (51 tests, all passing)
- Samples: add JSON object context examples
- README: document both string and object ctx patterns with CEL policy
variable mapping
Technical note: JJWT's .claim(String, Object) handles both types — String
serializes as a JSON string, Map serializes as a JSON object in the JWT
payload. No custom serialization needed.
Resolves: SK-2679, DOCU-1438
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@@ -2771,73 +2771,59 @@ public class BearerTokenGenerationExample {
2771
2771
2772
2772
## Generate bearer tokens with context
2773
2773
2774
-
**Context-aware authorization** embeds context values into a bearer token during its generation and so you can reference those values in your policies. This enables more flexible access controls, such as helping you track end-user identity when making API calls using service accounts, and facilitates using signed data tokens during detokenization. .
2774
+
**Context-aware authorization** embeds context values into a bearer token during its generation so you can reference those values in your policies. This enables more flexible access controls, such as helping you track end-user identity when making API calls using service accounts, and facilitates using signed data tokens during detokenization.
2775
2775
2776
2776
A service account with the `context_id` identifier generates bearer tokens containing context information, represented as a JWT claim in a Skyflow-generated bearer token. Tokens generated from such service accounts include a `context_identifier` claim, are valid for 60 minutes, and can be used to make API calls to the Data and Management APIs, depending on the service account's permissions.
**JSON object context** — use when your policy needs multiple context values for conditional data access. Each key in the `Map` maps to a Skyflow CEL policy variable under `request.context.*`:
2785
2790
2786
-
/**
2787
-
* Example program to generate a Bearer Token using Skyflow's BearerToken utility.
2788
-
* The token is generated using two approaches:
2789
-
* 1. By providing the credentials.json file path.
2790
-
* 2. By providing the contents of credentials.json as a string.
// Approach 1: Generate Bearer Token by specifying the path to the credentials.json file
2798
-
try {
2799
-
// Replace <YOUR_CREDENTIALS_FILE_PATH> with the full path to your credentials.json file
2800
-
String filePath ="<YOUR_CREDENTIALS_FILE_PATH>";
2797
+
BearerToken token =BearerToken.builder()
2798
+
.setCredentials(newFile(filePath))
2799
+
.setCtx(ctx)
2800
+
.build();
2801
+
```
2801
2802
2802
-
// Create a BearerToken object using the file path
2803
-
BearerToken token =BearerToken.builder()
2804
-
.setCredentials(newFile(filePath)) // Set credentials using a File object
2805
-
.setCtx("abc") // Set context string (example: "abc")
2806
-
.build(); // Build the BearerToken object
2803
+
With the map above, your Skyflow policies can reference `request.context.role`, `request.context.department`, and `request.context.user_id` to make conditional access decisions.
2807
2804
2808
-
// Retrieve the Bearer Token as a string
2809
-
bearerToken = token.getBearerToken();
2805
+
You can also set context on `Credentials` for automatic token generation:
2810
2806
2811
-
// Print the generated Bearer Token to the console
2812
-
System.out.println(bearerToken);
2813
-
} catch (SkyflowException e) {
2814
-
// Handle exceptions specific to Skyflow operations
2815
-
e.printStackTrace();
2816
-
}
2807
+
```java
2808
+
// String context
2809
+
Credentials credentials =newCredentials();
2810
+
credentials.setPath("path/to/credentials.json");
2811
+
credentials.setContext("user_12345");
2817
2812
2818
-
// Approach 2: Generate Bearer Token by specifying the contents of credentials.json as a string
2819
-
try {
2820
-
// Replace <YOUR_CREDENTIALS_FILE_CONTENTS_AS_STRING> with the actual contents of your credentials.json file
See Skyflow's [context-aware authorization](https://docs.skyflow.com) and [conditional data access](https://docs.skyflow.com) docs for policy variable syntax like `request.context.*`.
2841
2827
2842
2828
## Generate scoped bearer tokens
2843
2829
@@ -2903,58 +2889,31 @@ with the private key of the service account credentials, which adds an additiona
2903
2889
be detokenized by passing the signed data token and a bearer token generated from service account credentials. The
2904
2890
service account must have appropriate permissions and context to detokenize the signed data tokens.
The `setCtx()` method on `SignedDataTokensBuilder` also accepts either a **String** or a **`Map<String, Object>`**, using the same format as bearer tokens:
0 commit comments