Merged
Conversation
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughThe changes add comprehensive Client Initiated Backchannel Authentication (CIBA) grant documentation across Asgardeo and Identity Server platforms. A shared guide template is created and integrated into both documentation sites with corresponding navigation updates in their mkdocs configurations. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment Tip CodeRabbit can generate a title for your PR based on the changes.Add |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (1)
en/includes/guides/authentication/configure-ciba-grant.md (1)
21-22: Consider clarifying notification channel options.The documentation states "Currently supported channels include
external" - this phrasing suggests there may be other channels available. Consider either:
- Listing all available notification channels if more exist
- Removing "Currently" and "include" if
externalis the only supported channel (e.g., "The supported notification channel isexternal.")This helps users understand the full scope of configuration options.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@en/includes/guides/authentication/configure-ciba-grant.md` around lines 21 - 22, Update the "Notification Channels" sentence under the CIBA configuration section to remove ambiguity: if `external` is the only supported channel, change the text to state "The supported notification channel is `external`." otherwise list all supported channels explicitly (e.g., "`external`, `<other_channel>`") so the line referencing `external` is definitive; locate the "Notification Channels" paragraph that mentions `external` and edit it accordingly.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@en/includes/guides/authentication/configure-ciba-grant.md`:
- Around line 21-22: Update the "Notification Channels" sentence under the CIBA
configuration section to remove ambiguity: if `external` is the only supported
channel, change the text to state "The supported notification channel is
`external`." otherwise list all supported channels explicitly (e.g.,
"`external`, `<other_channel>`") so the line referencing `external` is
definitive; locate the "Notification Channels" paragraph that mentions
`external` and edit it accordingly.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: b87cf0fd-d8bc-46cd-b71c-12b0a469b309
⛔ Files ignored due to path filters (2)
en/asgardeo/docs/assets/img/references/grants/ciba-grant.pngis excluded by!**/*.pngen/identity-server/next/docs/assets/img/references/grants/ciba-grant.pngis excluded by!**/*.png
📒 Files selected for processing (6)
en/asgardeo/docs/guides/authentication/configure-ciba-grant.mden/asgardeo/mkdocs.ymlen/identity-server/next/docs/guides/authentication/configure-ciba-grant.mden/identity-server/next/mkdocs.ymlen/includes/guides/authentication/configure-ciba-grant.mden/includes/references/grant-types.md
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (3)
ciba-integration-test-architecture.md (2)
10-11: Avoid shorthand labels in the protocol diagram.
WSO2 ISandClient Appdo not match the naming used elsewhere in the docs. Please spell out the product name and useclient applicationfor consistency.As per coding guidelines, "Use official product and feature names exactly as defined; do not invent shorthand names, change capitalization, or alternate between long and short forms unless formally introduced".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ciba-integration-test-architecture.md` around lines 10 - 11, In the protocol diagram replace shorthand labels "WSO2 IS" and "Client App" with the exact official names used elsewhere: use "WSO2 Identity Server" instead of "WSO2 IS" and "client application" instead of "Client App" so the diagram matches the rest of the docs and follows the naming guideline; update the header line that currently reads "Consumption Device Identity Server Authentication Device (Client App) (WSO2 IS) (User's phone/browser)" to use the full names consistently.
1-7: Use sentence case for the title and section headings.The file starts with title case and the same pattern continues through the section headings. Please convert them to sentence case to match the docs style used in this repository.
As per coding guidelines, "Use sentence case for all headings and document titles, capitalizing only the first word and proper nouns".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ciba-integration-test-architecture.md` around lines 1 - 7, Change the document title and all section headings from title case to sentence case: update "# CIBA (Client Initiated Backchannel Authentication) - Architecture & Integration Test Plan", "## 1. CIBA Flow Overview", and "### 1.1 Protocol Flow" (and any other headings) so only the first word and proper nouns are capitalized (e.g., "CIBA (Client initiated backchannel authentication) - Architecture & integration test plan" and "1. CIBA flow overview", "1.1 Protocol flow"), keeping parentheses and acronyms intact.en/includes/guides/authentication/configure-ciba-grant.md (1)
26-66: Add an explicit outcome or next steps section.This reads like a task guide, but it ends with a reference sentence instead of confirming what the reader should expect after completing the flow and where to go next. A short
## Next stepssection would make the guide match the usual task-based structure.As per coding guidelines, "Task-based documentation must follow a logical, goal-oriented structure including: what the reader will achieve, when the task is applicable, prerequisites, sequential steps, outcome confirmation, troubleshooting (if applicable), and next steps" and "end with a Next steps section when appropriate".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@en/includes/guides/authentication/configure-ciba-grant.md` around lines 26 - 66, Add a new "## Next steps" section after the "Try it out" block that confirms the expected outcome (you should receive access and ID tokens via the /oauth2/token exchange once the user authenticates), suggests immediate follow-ups (validate tokens, call protected APIs with the access token, verify ID token claims), links to the CIBA grant reference and any token validation or troubleshooting pages, and optionally mentions common failure modes (expired auth_req_id, polling interval) and where to find logs; reference the existing examples/endpoints in this doc (/oauth2/ciba, /oauth2/ciba_authorize, /oauth2/token) to make the next steps actionable.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@ciba-integration-test-architecture.md`:
- Around line 184-189: The "Missing Constants" paragraph is now stale because
CIBA constants were implemented in OAuth2Constant.java; update this section to
either remove the note or change it to prior-context wording that references the
implemented constants by name (e.g., the CIBA grant type constant, the CIBA
endpoint URL constant, and the CIBA request/response field name constants) and
point readers to OAuth2Constant.java and the related implementation instead of
saying they still need to be added.
In `@en/includes/references/grant-types.md`:
- Around line 417-425: Replace the hard-coded Base64 Basic auth value in the
"Sample request (/ciba)" curl snippet (the Authorization: Basic header) with a
clear placeholder (e.g., Authorization: Basic <BASE64_CLIENT_CREDENTIALS>) and
do the same for the other occurrence referenced (lines around 455-462) so no
realistic credentials appear in the fenced code blocks; keep the language tag
and formatting unchanged and ensure the placeholder mirrors the format used in
other request-format examples.
- Around line 428-439: The docs currently list email, sms, and external as CIBA
notification channels but the config guide says only "external" is supported;
update this section to match the config guide by removing or marking email/sms
as unsupported and state that the only valid notification channel value is
"external" (adjust the explanatory sentence and the example JSON that includes
"auth_url" and "auth_req_id" accordingly), and add a brief note referencing the
configuration guide where readers can find supported channel details.
---
Nitpick comments:
In `@ciba-integration-test-architecture.md`:
- Around line 10-11: In the protocol diagram replace shorthand labels "WSO2 IS"
and "Client App" with the exact official names used elsewhere: use "WSO2
Identity Server" instead of "WSO2 IS" and "client application" instead of
"Client App" so the diagram matches the rest of the docs and follows the naming
guideline; update the header line that currently reads "Consumption Device
Identity Server Authentication Device (Client App)
(WSO2 IS) (User's phone/browser)" to use the full names
consistently.
- Around line 1-7: Change the document title and all section headings from title
case to sentence case: update "# CIBA (Client Initiated Backchannel
Authentication) - Architecture & Integration Test Plan", "## 1. CIBA Flow
Overview", and "### 1.1 Protocol Flow" (and any other headings) so only the
first word and proper nouns are capitalized (e.g., "CIBA (Client initiated
backchannel authentication) - Architecture & integration test plan" and "1. CIBA
flow overview", "1.1 Protocol flow"), keeping parentheses and acronyms intact.
In `@en/includes/guides/authentication/configure-ciba-grant.md`:
- Around line 26-66: Add a new "## Next steps" section after the "Try it out"
block that confirms the expected outcome (you should receive access and ID
tokens via the /oauth2/token exchange once the user authenticates), suggests
immediate follow-ups (validate tokens, call protected APIs with the access
token, verify ID token claims), links to the CIBA grant reference and any token
validation or troubleshooting pages, and optionally mentions common failure
modes (expired auth_req_id, polling interval) and where to find logs; reference
the existing examples/endpoints in this doc (/oauth2/ciba,
/oauth2/ciba_authorize, /oauth2/token) to make the next steps actionable.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 20c1f7ee-af61-4964-9049-9858b9de8b48
⛔ Files ignored due to path filters (2)
en/asgardeo/docs/assets/img/references/grants/ciba-grant.pngis excluded by!**/*.pngen/identity-server/next/docs/assets/img/references/grants/ciba-grant.pngis excluded by!**/*.png
📒 Files selected for processing (7)
ciba-integration-test-architecture.mden/asgardeo/docs/guides/authentication/configure-ciba-grant.mden/asgardeo/mkdocs.ymlen/identity-server/next/docs/guides/authentication/configure-ciba-grant.mden/identity-server/next/mkdocs.ymlen/includes/guides/authentication/configure-ciba-grant.mden/includes/references/grant-types.md
🚧 Files skipped from review as they are similar to previous changes (3)
- en/identity-server/next/mkdocs.yml
- en/asgardeo/mkdocs.yml
- en/asgardeo/docs/guides/authentication/configure-ciba-grant.md
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (1)
ciba-integration-test-architecture.md (1)
184-189:⚠️ Potential issue | 🟡 MinorUpdate or remove the stale "Missing Constants" section.
This section states that constants "need to be added," but the surrounding context (including section 3.5 at lines 347-357 and the AI summary) indicates these constants are already part of the implementation. This creates confusion about whether this document is a planning document or an implementation guide.
📝 Suggested revision
Option 1: Remove the section entirely if constants are implemented.
Option 2: Rewrite to reflect completed work:
-### 2.3 Missing Constants +### 2.3 CIBA Constants in OAuth2Constant.java -`OAuth2Constant.java` currently has no CIBA-related constants. The following need to be added: +The following CIBA-related constants have been added to `OAuth2Constant.java`: - CIBA grant type: `urn:openid:params:grant-type:ciba` - CIBA endpoint URL: `https://localhost:9853/oauth2/ciba` - CIBA response/request field names +(See section 3.5 for the complete constant definitions.)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ciba-integration-test-architecture.md` around lines 184 - 189, The "Missing Constants" subsection claiming CIBA constants need to be added is stale; update or remove it in the document so it reflects the current codebase: either delete the entire "2.3 Missing Constants" paragraph if OAuth2Constant.java already defines CIBA constants, or replace the text with a short confirmation that OAuth2Constant.java contains the CIBA grant type (urn:openid:params:grant-type:ciba), the CIBA endpoint URL (https://localhost:9853/oauth2/ciba) and the CIBA response/request field names, and link to OAuth2Constant.java as the authoritative source.
🧹 Nitpick comments (4)
ciba-integration-test-architecture.md (1)
371-371: Consider rephrasing to reduce word repetition.The sentence uses "only" twice in close proximity. While grammatically correct, rewording can improve readability.
✨ Alternative phrasing
-1. **External notification channel only** - Only `external` returns `auth_url`, making the flow automatable in tests. Email/SMS channels require external infrastructure not available in the test environment. +1. **External notification channel only** - The `external` channel is the only one that returns `auth_url`, making the flow automatable in tests. Email/SMS channels require external infrastructure not available in the test environment.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ciba-integration-test-architecture.md` at line 371, Reword the sentence to avoid repeating "only" while preserving meaning: update the line referencing the `external` channel and `auth_url` (e.g., "Only the `external` channel returns `auth_url`, which makes the flow automatable in tests because Email/SMS require external infrastructure not available in the test environment.") so it reads more smoothly and removes the duplicate "only".en/includes/guides/authentication/configure-ciba-grant.md (3)
15-15: Fix inconsistent template variable spacing.Line 15 uses
{{ product_name }}with spaces inside the braces, while line 9 uses{{product_name}}without spaces. Jinja syntax allows both, but consistency improves maintainability.✨ Standardize spacing
-1. On the {{ product_name }} Console, go to **Applications**. +1. On the {{product_name}} Console, go to **Applications**.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@en/includes/guides/authentication/configure-ciba-grant.md` at line 15, Inconsistent template variable spacing: replace all instances of the product-name template to a single style (choose either '{{product_name}}' or '{{ product_name }}') across the document; locate occurrences of '{{ product_name }}' and '{{product_name}}' in the markdown and normalize them (e.g., change '{{ product_name }}' to '{{product_name}}') so every template usage is consistent.
3-3: Consider splitting this long sentence for clarity.The sentence contains three clauses connected by commas and could be easier to read if split into two sentences.
✨ Improve readability
-[Client Initiated Backchannel Authentication (CIBA) grant]({{base_path}}/references/grant-types/#ciba-grant) is an authentication flow that decouples the consumption device from the authentication device. Instead of the user authenticating on the same device where the application resides, the application initiates the authentication request in the background, and the user is prompted to authenticate via a separate device. +[Client Initiated Backchannel Authentication (CIBA) grant]({{base_path}}/references/grant-types/#ciba-grant) is an authentication flow that decouples the consumption device from the authentication device. Instead of the user authenticating on the same device where the application resides, the application initiates the authentication request in the background. The user is then prompted to authenticate via a separate device.As per coding guidelines: "Use plain language and short sentences."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@en/includes/guides/authentication/configure-ciba-grant.md` at line 3, Split the long opening sentence about the "Client Initiated Backchannel Authentication (CIBA) grant" into two shorter sentences for clarity: keep the first sentence explaining that CIBA is an authentication flow that decouples the consumption device from the authentication device, and make a second sentence describing how the application initiates the authentication request in the background and the user authenticates via a separate device; update the paragraph text accordingly to follow the "plain language and short sentences" guideline.
21-21: Replace imprecise wording with concrete default value.The phrase "usually 120 seconds" is vague. Documentation should state the actual default value. If the default varies by product version, specify the conditions.
📝 Use precise language
- - **Expiry Time:** The validity period of the authentication request (`auth_req_id`) in seconds. The default is usually 120 seconds. + - **Expiry Time:** The validity period of the authentication request (`auth_req_id`) in seconds. The default is 120 seconds.As per coding guidelines: "Use precise nouns and strong verbs; avoid vague verbs such as handle, manage, deal with, perform, and utilize" and "When documenting configuration, describe what the setting controls, state the default value, state constraints (type, valid range, allowed values), provide a minimal example, and explain when the user should change it."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@en/includes/guides/authentication/configure-ciba-grant.md` at line 21, Replace the vague phrase "usually 120 seconds" in the "Expiry Time" description with a precise default value and constraints: state that the auth_req_id expiry is 120 seconds by default (type: integer, unit: seconds), note any product/version exceptions if applicable (e.g., "120 seconds by default; may differ in [ProductX vY]" only if that variance is confirmed), add the valid range or limits if known, and include a one-line minimal example and a brief note on when an operator should change the default (e.g., to increase timeout for slow networks).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@ciba-integration-test-architecture.md`:
- Around line 184-189: The "Missing Constants" subsection claiming CIBA
constants need to be added is stale; update or remove it in the document so it
reflects the current codebase: either delete the entire "2.3 Missing Constants"
paragraph if OAuth2Constant.java already defines CIBA constants, or replace the
text with a short confirmation that OAuth2Constant.java contains the CIBA grant
type (urn:openid:params:grant-type:ciba), the CIBA endpoint URL
(https://localhost:9853/oauth2/ciba) and the CIBA response/request field names,
and link to OAuth2Constant.java as the authoritative source.
---
Nitpick comments:
In `@ciba-integration-test-architecture.md`:
- Line 371: Reword the sentence to avoid repeating "only" while preserving
meaning: update the line referencing the `external` channel and `auth_url`
(e.g., "Only the `external` channel returns `auth_url`, which makes the flow
automatable in tests because Email/SMS require external infrastructure not
available in the test environment.") so it reads more smoothly and removes the
duplicate "only".
In `@en/includes/guides/authentication/configure-ciba-grant.md`:
- Line 15: Inconsistent template variable spacing: replace all instances of the
product-name template to a single style (choose either '{{product_name}}' or '{{
product_name }}') across the document; locate occurrences of '{{ product_name
}}' and '{{product_name}}' in the markdown and normalize them (e.g., change '{{
product_name }}' to '{{product_name}}') so every template usage is consistent.
- Line 3: Split the long opening sentence about the "Client Initiated
Backchannel Authentication (CIBA) grant" into two shorter sentences for clarity:
keep the first sentence explaining that CIBA is an authentication flow that
decouples the consumption device from the authentication device, and make a
second sentence describing how the application initiates the authentication
request in the background and the user authenticates via a separate device;
update the paragraph text accordingly to follow the "plain language and short
sentences" guideline.
- Line 21: Replace the vague phrase "usually 120 seconds" in the "Expiry Time"
description with a precise default value and constraints: state that the
auth_req_id expiry is 120 seconds by default (type: integer, unit: seconds),
note any product/version exceptions if applicable (e.g., "120 seconds by
default; may differ in [ProductX vY]" only if that variance is confirmed), add
the valid range or limits if known, and include a one-line minimal example and a
brief note on when an operator should change the default (e.g., to increase
timeout for slow networks).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: ed8d9a95-3d4c-4804-ba34-de0f30712a21
⛔ Files ignored due to path filters (2)
en/asgardeo/docs/assets/img/references/grants/ciba-grant.pngis excluded by!**/*.pngen/identity-server/next/docs/assets/img/references/grants/ciba-grant.pngis excluded by!**/*.png
📒 Files selected for processing (7)
ciba-integration-test-architecture.mden/asgardeo/docs/guides/authentication/configure-ciba-grant.mden/asgardeo/mkdocs.ymlen/identity-server/next/docs/guides/authentication/configure-ciba-grant.mden/identity-server/next/mkdocs.ymlen/includes/guides/authentication/configure-ciba-grant.mden/includes/references/grant-types.md
🚧 Files skipped from review as they are similar to previous changes (5)
- en/asgardeo/docs/guides/authentication/configure-ciba-grant.md
- en/asgardeo/mkdocs.yml
- en/identity-server/next/docs/guides/authentication/configure-ciba-grant.md
- en/identity-server/next/mkdocs.yml
- en/includes/references/grant-types.md
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (3)
en/includes/references/grant-types.md (2)
421-421:⚠️ Potential issue | 🟡 MinorReplace the realistic Base64 credential with a clear placeholder.
The sample curl request contains what appears to be a realistic Base64-encoded Basic auth credential. Replace it with a clear placeholder like
<BASE64_CLIENT_CREDENTIALS>to avoid triggering secret scanning and to comply with the guideline that code blocks should not include realistic keys.As per coding guidelines, "keep code blocks focused and do not include secrets, tokens, passwords, or realistic keys".
📝 Suggested change
curl -v -k -X POST {{base_url_example}}/oauth2/ciba \ - --header "Authorization: Basic YmJ3SkVheVJfT013UGtBZ205Vk9NekxuWUxnYTpTZDU2RGY3UkhLQm9JTWpWdzJLMnRhUzg5MjBh" \ + --header "Authorization: Basic <BASE64_CLIENT_CREDENTIALS>" \ --header "Content-Type:application/x-www-form-urlencoded" \🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@en/includes/references/grant-types.md` at line 421, The Authorization header in the curl example currently contains a realistic Base64-encoded credential; locate the curl request line that starts with --header "Authorization: Basic ...", and replace the existing Base64 string with a clear placeholder such as <BASE64_CLIENT_CREDENTIALS> so the example no longer contains realistic secrets.
459-459:⚠️ Potential issue | 🟡 MinorReplace the realistic Base64 credential with a clear placeholder.
The sample curl request contains what appears to be a realistic Base64-encoded Basic auth credential. Replace it with a clear placeholder like
<BASE64_CLIENT_CREDENTIALS>to avoid triggering secret scanning and to comply with the guideline that code blocks should not include realistic keys.As per coding guidelines, "keep code blocks focused and do not include secrets, tokens, passwords, or realistic keys".
📝 Suggested change
curl -v -k -X POST {{base_url_example}}/oauth2/token \ - --header "Authorization: Basic YmJ3SkVheVJfT013UGtBZ205Vk9NekxuWUxnYTpTZDU2RGY3UkhLQm9JTWpWdzJLMnRhUzg5MjBh" \ + --header "Authorization: Basic <BASE64_CLIENT_CREDENTIALS>" \ --header "Content-Type:application/x-www-form-urlencoded" \🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@en/includes/references/grant-types.md` at line 459, The curl example contains a realistic Base64 Basic auth string in the Authorization header; replace the long encoded value after 'Authorization: Basic' with a clear placeholder such as <BASE64_CLIENT_CREDENTIALS> (or a similarly named placeholder) in the curl snippet so the example no longer includes realistic credentials and complies with the no-secrets guideline.ciba-integration-test-architecture.md (1)
193-199:⚠️ Potential issue | 🟡 MinorUpdate this section to reflect that constants are now implemented.
This section states that constants "need to be added," but section 3.5 (lines 359-371) already defines these constants, and the PR context indicates they're implemented in OAuth2Constant.java. Either remove this section or rewrite it as background context that references the implemented constants.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ciba-integration-test-architecture.md` around lines 193 - 199, Update section 2.3 to reflect that the CIBA constants have already been implemented in OAuth2Constant.java: replace the "need to be added" wording with a short note stating the CIBA grant type, CIBA endpoint URL and CIBA request/response field name constants are defined in OAuth2Constant.java (mention the grant type constant, the endpoint URL constant, and the field-name constants by name or description) and either remove the obsolete TODO or convert it into a background/reference sentence pointing readers to OAuth2Constant.java (and the specific CIBA constants) for exact values.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@ciba-integration-test-architecture.md`:
- Around line 193-199: Update section 2.3 to reflect that the CIBA constants
have already been implemented in OAuth2Constant.java: replace the "need to be
added" wording with a short note stating the CIBA grant type, CIBA endpoint URL
and CIBA request/response field name constants are defined in
OAuth2Constant.java (mention the grant type constant, the endpoint URL constant,
and the field-name constants by name or description) and either remove the
obsolete TODO or convert it into a background/reference sentence pointing
readers to OAuth2Constant.java (and the specific CIBA constants) for exact
values.
In `@en/includes/references/grant-types.md`:
- Line 421: The Authorization header in the curl example currently contains a
realistic Base64-encoded credential; locate the curl request line that starts
with --header "Authorization: Basic ...", and replace the existing Base64 string
with a clear placeholder such as <BASE64_CLIENT_CREDENTIALS> so the example no
longer contains realistic secrets.
- Line 459: The curl example contains a realistic Base64 Basic auth string in
the Authorization header; replace the long encoded value after 'Authorization:
Basic' with a clear placeholder such as <BASE64_CLIENT_CREDENTIALS> (or a
similarly named placeholder) in the curl snippet so the example no longer
includes realistic credentials and complies with the no-secrets guideline.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 72e046b0-0f1f-4b3a-9415-7d1f4e4ddef2
⛔ Files ignored due to path filters (2)
en/asgardeo/docs/assets/img/references/grants/ciba-grant.pngis excluded by!**/*.pngen/identity-server/next/docs/assets/img/references/grants/ciba-grant.pngis excluded by!**/*.png
📒 Files selected for processing (7)
ciba-integration-test-architecture.mden/asgardeo/docs/guides/authentication/configure-ciba-grant.mden/asgardeo/mkdocs.ymlen/identity-server/next/docs/guides/authentication/configure-ciba-grant.mden/identity-server/next/mkdocs.ymlen/includes/guides/authentication/configure-ciba-grant.mden/includes/references/grant-types.md
🚧 Files skipped from review as they are similar to previous changes (3)
- en/asgardeo/docs/guides/authentication/configure-ciba-grant.md
- en/identity-server/next/mkdocs.yml
- en/asgardeo/mkdocs.yml
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (1)
en/includes/references/grant-types.md (1)
417-425:⚠️ Potential issue | 🟠 MajorReplace the encoded Basic auth samples with placeholders.
These sample requests still publish Base64-encoded client credentials. Please switch them to the same placeholder format used in the request-format blocks.
Suggested fix
- --header "Authorization: Basic YmJ3SkVheVJfT013UGtBZ205Vk9NekxuWUxnYTpTZDU2RGY3UkhLQm9JTWpWdzJLMnRhUzg5MjBh" \ + --header "Authorization: Basic <Base64Encoded(CLIENT_ID:CLIENT_SECRET)>" \ ... - --header "Authorization: Basic YmJ3SkVheVJfT013UGtBZ205Vk9NekxuWUxnYTpTZDU2RGY3UkhLQm9JTWpWdzJLMnRhUzg5MjBh" \ + --header "Authorization: Basic <Base64Encoded(CLIENT_ID:CLIENT_SECRET)>" \As per coding guidelines, "Use fenced code blocks with a language tag when known; keep code blocks focused and do not include secrets, tokens, passwords, or realistic keys".
Also applies to: 455-462
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@en/includes/references/grant-types.md` around lines 417 - 425, The curl sample contains a hard-coded Base64 client credential string in the Authorization header (the line starting with Authorization: Basic YmJ3...); replace that encoded value with the standard placeholder used elsewhere (e.g., Authorization: Basic {{client_credentials_base64}} or Authorization: Basic {{client_id:client_secret (base64)}}) for the /oauth2/ciba sample and the similar block at 455-462 so no real credentials are present and the request format matches other examples.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@en/includes/guides/authentication/configure-ciba-grant.md`:
- Line 47: Replace the placeholder {{base_url_format}} with the concrete example
token {{base_url_sample}} in the runnable examples (e.g., the curl POST to
/oauth2/ciba and other sample requests that construct auth_url) so the docs
render a concrete base URL; search for occurrences of {{base_url_format}} in the
file (including the curl examples and any auth_url samples) and update them to
{{base_url_sample}}.
- Around line 21-22: Update the "Expiry Time" bullet under the CIBA
configuration to replace vague wording with exact details: state the precise
default (e.g., "Default: 120 seconds"), the type (integer, seconds), valid range
or constraints (e.g., minimum/maximum or configurable limits), an example usage
showing a minimal config snippet setting auth_req_id expiry, and a short note on
when to change it (e.g., short-lived vs long-poll scenarios). Refer to the
"Expiry Time" label and the `auth_req_id` concept when adding these fields so
readers can find the setting and understand its effect.
In `@en/includes/references/grant-types.md`:
- Around line 430-436: Update the JSON example so the "expires_in" field matches
the configuration guide's default/example value by changing "expires_in": 100 to
"expires_in": 120 in the code block (look for the JSON example containing
"auth_req_id" and "auth_url" to locate the snippet).
---
Duplicate comments:
In `@en/includes/references/grant-types.md`:
- Around line 417-425: The curl sample contains a hard-coded Base64 client
credential string in the Authorization header (the line starting with
Authorization: Basic YmJ3...); replace that encoded value with the standard
placeholder used elsewhere (e.g., Authorization: Basic
{{client_credentials_base64}} or Authorization: Basic {{client_id:client_secret
(base64)}}) for the /oauth2/ciba sample and the similar block at 455-462 so no
real credentials are present and the request format matches other examples.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: fe22d0e8-7953-48c4-9502-5a306a7c65e6
⛔ Files ignored due to path filters (2)
en/asgardeo/docs/assets/img/references/grants/ciba-grant.pngis excluded by!**/*.pngen/identity-server/next/docs/assets/img/references/grants/ciba-grant.pngis excluded by!**/*.png
📒 Files selected for processing (6)
en/asgardeo/docs/guides/authentication/configure-ciba-grant.mden/asgardeo/mkdocs.ymlen/identity-server/next/docs/guides/authentication/configure-ciba-grant.mden/identity-server/next/mkdocs.ymlen/includes/guides/authentication/configure-ciba-grant.mden/includes/references/grant-types.md
🚧 Files skipped from review as they are similar to previous changes (3)
- en/identity-server/next/docs/guides/authentication/configure-ciba-grant.md
- en/asgardeo/mkdocs.yml
- en/identity-server/next/mkdocs.yml
sahandilshan
force-pushed
the
ciba
branch
2 times, most recently
from
720f4c3 to
d3c1c5b
Compare
himeshsiriwardana
approved these changes
Mar 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
Add Documentation related CIBA
Related Issue(s)
Summary by CodeRabbit