Skip to content

[DX-2014] docs: add Keycloak worked example for issuing OAuth tokens via TIB - #2774

Open
sharadregoti wants to merge 10 commits into
mainfrom
docs/DX-2014-oauth2-keycloak-tib-example
Open

[DX-2014] docs: add Keycloak worked example for issuing OAuth tokens via TIB#2774
sharadregoti wants to merge 10 commits into
mainfrom
docs/DX-2014-oauth2-keycloak-tib-example

Merge main into docs/DX-2014-oauth2-keycloak-tib-example

6e087bc
Select commit
Loading
Failed to load commit list.
probelabs / Visor: security failed Aug 27, 2026 in 32s

🚨 Check Failed

security check failed because fail_if condition was met.

Details

📊 Summary

  • Total Issues: 3
  • Error Issues: 2
  • Warning Issues: 1

🔍 Failure Condition Results

Failed Conditions

  • global_fail_if: output.issues && output.issues.some(i => i.severity === 'critical' || i.severity === 'error')
    • Severity: ❌ error

Issues by Category

Security (2)

  • api-management/access-control/sessions-and-keys/issuing-tokens-via-tib.mdx:190 - The documentation example for Keycloak integration consistently uses http:// for sensitive OAuth/OIDC endpoints, including redirect URIs and callback URLs. This is insecure as it allows for man-in-the-middle attacks to intercept authorization codes or access tokens. All communication involving tokens and codes must be over HTTPS.
  • ⚠️ api-management/access-control/sessions-and-keys/issuing-tokens-via-tib.mdx:235 - The example's verification step describes the result of an OAuth 2.0 Implicit Grant flow (ResponseType: token), where the access token is returned in the URL fragment. This flow is no longer a security best practice due to risks of token leakage. The Authorization Code Grant (ResponseType: authorization_code) is more secure and should be the recommended default.

Logic (1)

  • system:0 - Global failure condition met: output.issues && output.issues.some(i => i.severity === 'critical' || i.severity === 'error')

Powered by Visor from Probelabs

💡 TIP: You can chat with Visor using /visor ask <your question>

Annotations

Check failure on line 238 in api-management/access-control/sessions-and-keys/issuing-tokens-via-tib.mdx

See this annotation in the file changed.

@probelabs probelabs / Visor: security

security Issue

The documentation example for Keycloak integration consistently uses `http://` for sensitive OAuth/OIDC endpoints, including redirect URIs and callback URLs. This is insecure as it allows for man-in-the-middle attacks to intercept authorization codes or access tokens. All communication involving tokens and codes must be over HTTPS.
Raw output
Replace all instances of `http://` with `https://` in the Keycloak example. For instance, change `http://{tib-host}` to `https://{tib-host}`. Add a note clarifying that while `http://` might be used for local testing, production deployments must use HTTPS.

Check warning on line 239 in api-management/access-control/sessions-and-keys/issuing-tokens-via-tib.mdx

See this annotation in the file changed.

@probelabs probelabs / Visor: security

security Issue

The example's verification step describes the result of an OAuth 2.0 Implicit Grant flow (`ResponseType: token`), where the access token is returned in the URL fragment. This flow is no longer a security best practice due to risks of token leakage. The Authorization Code Grant (`ResponseType: authorization_code`) is more secure and should be the recommended default.
Raw output
Modify the example to primarily demonstrate the Authorization Code Grant. The `IdentityHandlerConfig.OAuth.ResponseType` is mentioned in the reference table but not set in the example. The example should explicitly recommend and use `authorization_code`, and the verification steps should be updated to describe the code-for-token exchange process. If the Implicit Grant must be shown, it should be as a secondary option with clear security warnings.