Expand password grant notes with offline_access, security risks, and client design advice

Author: workcontrolgit

blogs/series-2-dotnet-api/2.4-dotnet-swagger-jwt.md

@@ -240,6 +240,11 @@ curl -X POST https://localhost:44310/connect/token \
 ```
 
 > **⚠️ Password grant not enabled by default.** The seed data file (`identityserverdata.json`) does not include `password` in the `TalentManagement` client's allowed grant types, so this curl command will return `unauthorized_client` out of the box. To enable it, open the IdentityServer Admin UI (`https://localhost:44303`), navigate to **Clients → TalentManagement → Basics → Allowed Grant Types**, and add `password`. This change is not persisted to the seed file — it must be re-added if the database is recreated.
+>
+> **Before enabling password grant, consider:**
+> * **Add `offline_access` to AllowedScopes** if you also need refresh tokens — the password flow requires it explicitly.
+> * **Password grant (Resource Owner Password Credentials) is generally discouraged for new applications.** It requires the client to handle user credentials directly, which eliminates the security isolation that OAuth 2.0 is designed to provide.
+> * **Avoid mixing `authorization_code` and `password` on the same client.** The `TalentManagement` client is a browser-based SPA using `authorization_code` + PKCE. Adding `password` to the same client mixes trust levels. The better design is a separate machine/trusted client dedicated to programmatic token acquisition.
 
 The response contains `"access_token": "eyJ..."`.
 

blogs/series-4-playwright-testing/4.4-playwright-jwt-token-testing.md

@@ -510,7 +510,13 @@ However, the AngularNetTutorial IdentityServer is configured for **PKCE only** 
 
 The result is that `getApiToken()` returns `unauthorized_client`. The Profile Page approach (`getTokenFromProfile()`) is the correct way to get a real token in this setup — it goes through the actual PKCE flow.
 
-**If you need password grant enabled** (for testing tools or Swagger UI), the seed data file (`identityserverdata.json`) does not include it for the `TalentManagement` client. You can enable it at runtime via the IdentityServer Admin UI (`https://localhost:44303`): navigate to **Clients → TalentManagement → Basics → Allowed Grant Types** and add `password`. Note that this change is not persisted back to the seed file — if the database is recreated, the grant type will be lost and must be re-added.
+**If you need password grant enabled**, the seed data file (`identityserverdata.json`) does not include it for the `TalentManagement` client. You can enable it at runtime via the IdentityServer Admin UI (`https://localhost:44303`): navigate to **Clients → TalentManagement → Basics → Allowed Grant Types** and add `password`. Note that this change is not persisted back to the seed file — if the database is recreated, the grant type will be lost and must be re-added.
+
+Before doing so, consider these design implications:
+
+* **Add `offline_access` to AllowedScopes** if you also need refresh tokens — the password flow requires it explicitly.
+* **Password grant (Resource Owner Password Credentials) is generally discouraged for new applications.** It requires the client to handle user credentials directly, bypassing the security isolation that OAuth 2.0 is designed to provide.
+* **Avoid mixing `authorization_code` and `password` on the same client.** The `TalentManagement` client is a browser SPA using `authorization_code` + PKCE. Adding `password` to it mixes trust levels. The better design is a separate machine/trusted client dedicated to programmatic token acquisition (e.g. for test automation or CI pipelines).
 
 ---