MGilat commented on issue #30995:
URL: https://github.com/apache/superset/issues/30995#issuecomment-2624663035
### **Storing Object in `identity` vs. `additional_claims` – Which is
Better?**
Both approaches work, but the best choice depends on how you use the data.
Here's a breakdown of **pros and cons** for each approach.
---
## **1️⃣ Storing an Object in `identity`**
```python
access_token = create_access_token(identity={"id": 123, "username":
"johndoe", "role": "admin"})
```
### ✅ **Pros**:
✔ **Simple & automatic retrieval** – `get_jwt_identity()` directly gives you
the user object.
✔ **Easy for authentication** – If `identity` uniquely represents a user,
it’s easier to work with.
### ❌ **Cons**:
❌ `"sub"` is meant for a unique identifier, not a full object (not strictly
JWT-compliant).
❌ If you later need to change `"sub"` behavior (e.g., switch to a UUID
instead), it could cause compatibility issues.
### **Retrieval**
```python
user = get_jwt_identity() # Retrieves full object stored in "sub"
```
---
## **2️⃣ Storing Object Data in `additional_claims`**
```python
access_token = create_access_token(identity=123,
additional_claims={"username": "johndoe", "role": "admin"})
```
### ✅ **Pros**:
✔ **Keeps `sub` clean** – `identity` remains a single unique identifier
(best practice).
✔ **More flexibility** – You can store additional user-related data without
overloading `"sub"`.
✔ **More readable JWT structure** – Custom claims are explicitly separate
from `"sub"`.
### ❌ **Cons**:
❌ Requires an extra step to access the object (`get_jwt()` instead of
`get_jwt_identity()`).
❌ If you store too much data, the token size increases (which could be an
issue for performance).
### **Retrieval**
```python
claims = get_jwt()
user_id = claims["sub"] # Retrieves the identity
username = claims["username"]
role = claims["role"]
```
---
## **💡 Best Practice Recommendation**
- ✅ **Use `identity` for a single unique identifier** (e.g., `user_id`,
`email`, or `UUID`).
- ✅ **Use `additional_claims` for extra user attributes** (e.g., `username`,
`role`, `permissions`).
### **Best Approach (Combining Both)**
```python
access_token = create_access_token(
identity=123, # Store only user ID in sub
additional_claims={"username": "johndoe", "role": "admin"}
)
```
### **Retrieving Data**
```python
claims = get_jwt()
user_id = claims["sub"] # Best practice: keep it as an ID
username = claims.get("username")
role = claims.get("role")
```
---
### **When Should You Store the Full Object in `identity`?**
- If your app **always needs the entire user object** and you don’t care
about strict JWT compliance.
- If you want to minimize API/database calls and always retrieve full user
info from the token.
### **When Should You Use `additional_claims`?**
- If you follow best practices by keeping `"sub"` as a unique identifier.
- If you need **flexibility** to modify or expand JWT data later.
- If you're integrating with other services that expect `"sub"` to be a
**single value**.
---
## **🚀 Final Verdict**
✅ **Best Practice** → **Store a single unique ID in `identity` and use
`additional_claims` for extra attributes.**
🔹 This approach is clean, scalable, and follows JWT best practices.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
