Add Docs for Securing REST APIs with JWT Access Tokens#2104
Open
sajinieKavindya wants to merge 1 commit intowso2:mainfrom
Open
Add Docs for Securing REST APIs with JWT Access Tokens#2104sajinieKavindya wants to merge 1 commit intowso2:mainfrom
sajinieKavindya wants to merge 1 commit intowso2:mainfrom
Conversation
sajinieKavindya
requested review from
GDLMadushanka,
anupama-pathirage,
chanikag and
rosensilva
as code owners
Contributor
WalkthroughThis PR updates WSO2 Integrator: MI REST API security documentation by replacing a single generic securing guide with two focused guides: one for JWT (Self Contained) Access Tokens and another for Basic Authentication. Documentation structure and navigation are updated to reflect this split. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~22 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 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 You can customize the tone of the review comments and chat replies.Configure the |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (6)
en/docs/learn/examples/rest-api-examples/securing-rest-apis-with-jwt-access-tokens.md (3)
7-9: Use hyphenated form "JWT-based" for compound adjectives.When "JWT based" modifies a noun like "tokens," it should be hyphenated as "JWT-based."
📝 Suggested fix
-## Prerequisites for JWT based tokens +## Prerequisites for JWT-based tokens -The following prerequisites have to be satisfied for JWT based tokens to work. +The following prerequisites have to be satisfied for JWT-based tokens to work.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@en/docs/learn/examples/rest-api-examples/securing-rest-apis-with-jwt-access-tokens.md` around lines 7 - 9, Update the compound adjective "JWT based" to the hyphenated form "JWT-based" in the header and any occurrences in this section (e.g., change the heading "Prerequisites for JWT based tokens" and the sentence "JWT based tokens" to "Prerequisites for JWT-based tokens" and "JWT-based tokens") so the compound modifier is correctly hyphenated.
1-1: Use hyphenated form "Self-Contained" in title.For grammatical correctness, compound adjectives should be hyphenated when they precede a noun.
📝 Suggested fix
-# Secure APIs using JWT (Self Contained) Access Tokens +# Secure APIs using JWT (Self-Contained) Access Tokens🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@en/docs/learn/examples/rest-api-examples/securing-rest-apis-with-jwt-access-tokens.md` at line 1, Update the markdown title header "# Secure APIs using JWT (Self Contained) Access Tokens" to use the hyphenated compound adjective "Self-Contained" so it reads "# Secure APIs using JWT (Self-Contained) Access Tokens"; locate and edit the exact header string in the document to apply this minor text change.
297-297: Remove extra space in heading.The heading has multiple spaces after the hash marks, which triggers a markdown lint warning.
📝 Suggested fix
-### Cache Settings +### Cache Settings🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@en/docs/learn/examples/rest-api-examples/securing-rest-apis-with-jwt-access-tokens.md` at line 297, The markdown heading "### Cache Settings" contains two spaces after the hash marks; update the heading to use a single space like "### Cache Settings" to resolve the lint warning and ensure consistent heading formatting in the file.en/docs/develop/creating-artifacts/creating-an-api.md (1)
344-344: Use hyphenated form "Self-Contained" for compound adjective.The static analysis tool correctly identifies that "Self Contained" should be hyphenated when used as a compound adjective before a noun. This should be "Self-Contained" for grammatical correctness.
📝 Suggested fix
-- [Securing a REST API with JWT (Self Contained) Access Tokens]({{base_path}}/learn/examples/rest-api-examples/securing-rest-apis-with-jwt-access-tokens) +- [Securing a REST API with JWT (Self-Contained) Access Tokens]({{base_path}}/learn/examples/rest-api-examples/securing-rest-apis-with-jwt-access-tokens)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@en/docs/develop/creating-artifacts/creating-an-api.md` at line 344, Update the link text "[Securing a REST API with JWT (Self Contained) Access Tokens]" to use the hyphenated compound adjective by changing "Self Contained" to "Self-Contained" so the text becomes "[Securing a REST API with JWT (Self-Contained) Access Tokens]" in the Markdown line containing that link.en/docs/learn/examples/rest-api-examples/securing-rest-apis-with-basic-authentication.md (1)
9-10: Add blank line before section header.There should be a blank line between the info block (line 9) and the section header (line 10) for proper markdown formatting and rendering.
📝 Suggested fix
!!! Info The WSO2 Integrator: MI includes a Basic Auth handler that can be enabled for this purpose. If your requirements are more complex, you can also implement a custom basic auth handler or use other security mechanisms like OAuth2. Find out more about [applying security to REST APIs]({{base_path}}/develop/advanced-development/applying-security-to-an-api). + ## Synapse configuration🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@en/docs/learn/examples/rest-api-examples/securing-rest-apis-with-basic-authentication.md` around lines 9 - 10, There is no blank line between the paragraph ending "Find out more about [applying security to REST APIs]({{base_path}}/develop/advanced-development/applying-security-to-an-api)." and the section header "## Synapse configuration"; insert a single blank line between that paragraph and the "## Synapse configuration" header so the markdown renders the header correctly.en/mkdocs.yml (1)
369-371: Verify navigation title consistency with page content.The navigation entry uses "OAuth2" terminology while the linked page and other references use "JWT (Self-Contained) Access Tokens". While JWT access tokens are part of OAuth2, consider aligning the navigation title with the actual page title for consistency.
The page title is "Secure APIs using JWT (Self Contained) Access Tokens" but the nav shows "How to Secure a REST API with OAuth2".
📝 Consider aligning navigation title
- How to Secure a REST API: - How to Secure a REST API with Basic Authentication: learn/examples/rest-api-examples/securing-rest-apis-with-basic-authentication.md - - How to Secure a REST API with OAuth2: learn/examples/rest-api-examples/securing-rest-apis-with-jwt-access-tokens.md + - How to Secure a REST API with JWT Access Tokens: learn/examples/rest-api-examples/securing-rest-apis-with-jwt-access-tokens.md🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@en/mkdocs.yml` around lines 369 - 371, Update the navigation entry that currently reads "How to Secure a REST API with OAuth2" to match the linked page's title "Secure APIs using JWT (Self Contained) Access Tokens" (or a concise variant such as "How to Secure a REST API with JWT (Self-Contained) Access Tokens") so the nav label aligns with the page content; locate the navigation block containing the string "How to Secure a REST API with OAuth2" and replace it with the chosen JWT-focused title while keeping the existing link target unchanged.
🤖 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/docs/learn/examples/rest-api-examples/securing-rest-apis-with-jwt-access-tokens.md`:
- Line 392: The image tag <img
src="{{base_path}}/assets/img/learn/api-security/oauth2/oauth2-authorization-handler/add-oauth-authorization-handler.png">
is missing alt text; add an alt attribute to that img element with a concise
descriptive string (e.g., "Add OAuth Authorization Handler dialog in API
Security UI" or similar) so screen readers can describe the image.
- Around line 151-152: Update the section heading "### 6. Sender Constrain &
Proof-of-Possession" to use the correct noun form "Constraint" (i.e., "### 6.
Sender Constraint & Proof-of-Possession"); locate the heading text in the
markdown for this section and replace "Constrain" with "Constraint" so the title
reads correctly while leaving the body content unchanged.
---
Nitpick comments:
In `@en/docs/develop/creating-artifacts/creating-an-api.md`:
- Line 344: Update the link text "[Securing a REST API with JWT (Self Contained)
Access Tokens]" to use the hyphenated compound adjective by changing "Self
Contained" to "Self-Contained" so the text becomes "[Securing a REST API with
JWT (Self-Contained) Access Tokens]" in the Markdown line containing that link.
In
`@en/docs/learn/examples/rest-api-examples/securing-rest-apis-with-basic-authentication.md`:
- Around line 9-10: There is no blank line between the paragraph ending "Find
out more about [applying security to REST
APIs]({{base_path}}/develop/advanced-development/applying-security-to-an-api)."
and the section header "## Synapse configuration"; insert a single blank line
between that paragraph and the "## Synapse configuration" header so the markdown
renders the header correctly.
In
`@en/docs/learn/examples/rest-api-examples/securing-rest-apis-with-jwt-access-tokens.md`:
- Around line 7-9: Update the compound adjective "JWT based" to the hyphenated
form "JWT-based" in the header and any occurrences in this section (e.g., change
the heading "Prerequisites for JWT based tokens" and the sentence "JWT based
tokens" to "Prerequisites for JWT-based tokens" and "JWT-based tokens") so the
compound modifier is correctly hyphenated.
- Line 1: Update the markdown title header "# Secure APIs using JWT (Self
Contained) Access Tokens" to use the hyphenated compound adjective
"Self-Contained" so it reads "# Secure APIs using JWT (Self-Contained) Access
Tokens"; locate and edit the exact header string in the document to apply this
minor text change.
- Line 297: The markdown heading "### Cache Settings" contains two spaces after
the hash marks; update the heading to use a single space like "### Cache
Settings" to resolve the lint warning and ensure consistent heading formatting
in the file.
In `@en/mkdocs.yml`:
- Around line 369-371: Update the navigation entry that currently reads "How to
Secure a REST API with OAuth2" to match the linked page's title "Secure APIs
using JWT (Self Contained) Access Tokens" (or a concise variant such as "How to
Secure a REST API with JWT (Self-Contained) Access Tokens") so the nav label
aligns with the page content; locate the navigation block containing the string
"How to Secure a REST API with OAuth2" and replace it with the chosen
JWT-focused title while keeping the existing link target unchanged.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: dc8b7ff6-642d-4ac2-8f64-cfd51320e286
⛔ Files ignored due to path filters (1)
en/docs/assets/img/learn/api-security/oauth2/oauth2-authorization-handler/add-oauth-authorization-handler.pngis excluded by!**/*.png
📒 Files selected for processing (6)
en/docs/develop/advanced-development/applying-security-to-an-api.mden/docs/develop/creating-artifacts/creating-an-api.mden/docs/learn/examples/rest-api-examples/securing-rest-apis-with-basic-authentication.mden/docs/learn/examples/rest-api-examples/securing-rest-apis-with-jwt-access-tokens.mden/docs/learn/learn-overview.mden/mkdocs.yml
Comment on lines
+151
to
+152
| ### 6. Sender Constrain & Proof-of-Possession | ||
| The final layer of the pipeline is the Confirmation (`cnf`) claim check. If **cnf validation** is enabled (for maximum security, cnf validation is enabled by default), the handler extracts the thumbprint of the client certificate used during the TLS handshake and compares it with the x5t#S256 value inside the token. This Proof-of-Possession check ensures that even if a JWT is intercepted, it cannot be used by any party other than the original client to whom it was issued. |
Contributor
There was a problem hiding this comment.
Fix spelling: "Constrain" should be "Constraint".
"Constrain" is a verb; the correct noun form is "Constraint" for this section heading about sender-constrained tokens.
📝 Suggested fix
-### 6. Sender Constrain & Proof-of-Possession
+### 6. Sender Constraint & Proof-of-Possession📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| ### 6. Sender Constrain & Proof-of-Possession | |
| The final layer of the pipeline is the Confirmation (`cnf`) claim check. If **cnf validation** is enabled (for maximum security, cnf validation is enabled by default), the handler extracts the thumbprint of the client certificate used during the TLS handshake and compares it with the x5t#S256 value inside the token. This Proof-of-Possession check ensures that even if a JWT is intercepted, it cannot be used by any party other than the original client to whom it was issued. | |
| ### 6. Sender Constraint & Proof-of-Possession | |
| The final layer of the pipeline is the Confirmation (`cnf`) claim check. If **cnf validation** is enabled (for maximum security, cnf validation is enabled by default), the handler extracts the thumbprint of the client certificate used during the TLS handshake and compares it with the x5t#S256 value inside the token. This Proof-of-Possession check ensures that even if a JWT is intercepted, it cannot be used by any party other than the original client to whom it was issued. |
🧰 Tools
🪛 LanguageTool
[grammar] ~151-~151: Ensure spelling is correct
Context: ...s the specific resource. ### 6. Sender Constrain & Proof-of-Possession The final layer o...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@en/docs/learn/examples/rest-api-examples/securing-rest-apis-with-jwt-access-tokens.md`
around lines 151 - 152, Update the section heading "### 6. Sender Constrain &
Proof-of-Possession" to use the correct noun form "Constraint" (i.e., "### 6.
Sender Constraint & Proof-of-Possession"); locate the heading text in the
markdown for this section and replace "Constrain" with "Constraint" so the title
reads correctly while leaving the body content unchanged.
| 5. Click on the **Add Handler** button and type `org.wso2.micro.integrator.security.handler.oauth.OAuthAuthenticationHandler` as the class name. | ||
| 6. Click on **Add Property** button to add the necessary properties as below. | ||
|
|
||
| <img src="{{base_path}}/assets/img/learn/api-security/oauth2/oauth2-authorization-handler/add-oauth-authorization-handler.png"> |
Contributor
There was a problem hiding this comment.
Add alt text to image for accessibility.
Images should include alternate text (alt text) for accessibility compliance. This helps screen readers describe the image to users with visual impairments.
📝 Suggested fix
- <img src="{{base_path}}/assets/img/learn/api-security/oauth2/oauth2-authorization-handler/add-oauth-authorization-handler.png">
+ <img src="{{base_path}}/assets/img/learn/api-security/oauth2/oauth2-authorization-handler/add-oauth-authorization-handler.png" alt="Add OAuth Authorization Handler properties in the API configuration">📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| <img src="{{base_path}}/assets/img/learn/api-security/oauth2/oauth2-authorization-handler/add-oauth-authorization-handler.png"> | |
| <img src="{{base_path}}/assets/img/learn/api-security/oauth2/oauth2-authorization-handler/add-oauth-authorization-handler.png" alt="Add OAuth Authorization Handler properties in the API configuration"> |
🧰 Tools
🪛 markdownlint-cli2 (0.21.0)
[warning] 392-392: Images should have alternate text (alt text)
(MD045, no-alt-text)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@en/docs/learn/examples/rest-api-examples/securing-rest-apis-with-jwt-access-tokens.md`
at line 392, The image tag <img
src="{{base_path}}/assets/img/learn/api-security/oauth2/oauth2-authorization-handler/add-oauth-authorization-handler.png">
is missing alt text; add an alt attribute to that img element with a concise
descriptive string (e.g., "Add OAuth Authorization Handler dialog in API
Security UI" or similar) so screen readers can describe the image.
chanikag
reviewed
Mar 20, 2026
| - How to Handle Non-matching Resources: learn/examples/rest-api-examples/handling-non-matching-resources.md | ||
| - How to Handle HTTP Status Codes: learn/examples/rest-api-examples/setting-https-status-codes.md | ||
| - How to Transform Content Types: learn/examples/rest-api-examples/transforming-content-type.md | ||
| - How to Secure a REST API: learn/examples/rest-api-examples/securing-rest-apis.md |
Contributor
There was a problem hiding this comment.
Let's add a redirection or else let's not change the .md file name
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the English documentation to split “Secure a REST API” guidance into separate Basic Authentication and JWT (RFC 9068 self-contained access token) guides, and rewires navigation/entry points accordingly.
Changes:
- Reorganized REST API security docs into two separate pages (Basic Auth vs JWT access tokens).
- Added a comprehensive JWT access token security guide (validation pipeline + configuration reference).
- Updated navigation and overview pages to link to the new docs.
Reviewed changes
Copilot reviewed 6 out of 7 changed files in this pull request and generated 7 comments.
Show a summary per file
| File | Description |
|---|---|
| en/mkdocs.yml | Updates site nav to nest REST API security docs under a new “How to Secure a REST API” section. |
| en/docs/learn/learn-overview.md | Updates Learn overview links to point to the new Basic Auth and JWT security pages. |
| en/docs/learn/examples/rest-api-examples/securing-rest-apis-with-jwt-access-tokens.md | Adds new JWT (RFC 9068) access token security documentation, including configuration tables and examples. |
| en/docs/learn/examples/rest-api-examples/securing-rest-apis-with-basic-authentication.md | Adjusts the Basic Auth security page intro text (but retains older title/formatting in places). |
| en/docs/develop/creating-artifacts/creating-an-api.md | Updates “Examples” links to point to the new security docs. |
| en/docs/develop/advanced-development/applying-security-to-an-api.md | Updates security handler overview to reference the two built-in handlers and the new docs. |
Comments suppressed due to low confidence (2)
en/docs/learn/examples/rest-api-examples/securing-rest-apis-with-basic-authentication.md:2
- This page title is still the generic "How to Secure a REST API", but the page is now specifically the Basic Authentication variant (and is linked as such from navigation). Consider updating the H1 to reflect Basic Authentication so readers (and search results) can distinguish it from the JWT/OAuth2 page.
en/docs/learn/examples/rest-api-examples/securing-rest-apis-with-basic-authentication.md:9 - The MkDocs admonition content for this "!!! Info" block is not indented, so it won’t render as an admonition body. Indent the text under "!!! Info" (typically 4 spaces) to ensure it renders correctly.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| - How to Secure a REST API: learn/examples/rest-api-examples/securing-rest-apis.md | ||
| - How to Secure a REST API: | ||
| - How to Secure a REST API with Basic Authentication: learn/examples/rest-api-examples/securing-rest-apis-with-basic-authentication.md | ||
| - How to Secure a REST API with OAuth2: learn/examples/rest-api-examples/securing-rest-apis-with-jwt-access-tokens.md |
There was a problem hiding this comment.
In the REST API examples nav, the label says "How to Secure a REST API with OAuth2" but the linked page is specifically about securing APIs with self-contained JWT access tokens. This mismatch can confuse readers; consider renaming the nav entry to mention JWT access tokens (or otherwise align the label with the page’s scope).
Suggested change
| - How to Secure a REST API with OAuth2: learn/examples/rest-api-examples/securing-rest-apis-with-jwt-access-tokens.md | |
| - How to Secure a REST API with JWT Access Tokens: learn/examples/rest-api-examples/securing-rest-apis-with-jwt-access-tokens.md |
|
|
||
| - The expected token format is as follows: | ||
|
|
||
| `base64(header).base64(payload).base64(signature)` |
There was a problem hiding this comment.
The JWT compact serialization uses base64url encoding (RFC 7515/7519), not standard base64. Consider updating the format example to base64url (and optionally note "no padding") to avoid misleading readers who try to manually inspect/generate tokens.
Suggested change
| `base64(header).base64(payload).base64(signature)` | |
| `base64url(header).base64url(payload).base64url(signature)` (base64url-encoded, no padding) |
| <strong>Default Behavior:</strong> By default, the server only accepts algorithms from the <strong>RSA family</strong> (e.g., RS256, RS384, RS512, PS256, PS384, PS512). This ensures that only strong, asymmetric signatures are trusted. | ||
| </li> | ||
| <li> | ||
| <strong>Strict Validation:</strong> If you need to be more specific or restrict the API to a single signature type, you can [configure the <code>allowedAlgorithm</code> parameter](#handler-configuration-reference) at the handler level. This will force the handler to validate that the token's <code>alg</code> header matches your specified value exactly. |
There was a problem hiding this comment.
This note refers to an allowedAlgorithm handler parameter, but the configuration table later documents allowedAlgorithms (plural). Please align the parameter name(s) so readers can configure algorithm restrictions correctly.
Suggested change
| <strong>Strict Validation:</strong> If you need to be more specific or restrict the API to a single signature type, you can [configure the <code>allowedAlgorithm</code> parameter](#handler-configuration-reference) at the handler level. This will force the handler to validate that the token's <code>alg</code> header matches your specified value exactly. | |
| <strong>Strict Validation:</strong> If you need to be more specific or restrict the API to a single signature type, you can [configure the <code>allowedAlgorithms</code> parameter](#handler-configuration-reference) at the handler level. This will force the handler to validate that the token's <code>alg</code> header matches your specified value exactly. |
| ### 5. Scope validation | ||
| The WSO2 Integrator: MI validates the scopes coming in the `scope` claim of the JWT. The handler ensures the scope claim contains the necessary permissions (defined in the Open API spec) required to access the specific resource. | ||
|
|
||
| ### 6. Sender Constrain & Proof-of-Possession |
There was a problem hiding this comment.
Section title has a typo: "Sender Constrain" should be "Sender Constraint" (or "Sender-Constrained") to match the terminology used elsewhere in the document/specs.
Suggested change
| ### 6. Sender Constrain & Proof-of-Possession | |
| ### 6. Sender Constraint & Proof-of-Possession |
Comment on lines
+185
to
+193
| * Checks if the given token has been revoked or invalidated. | ||
| * | ||
| * @param token The raw string token or a parsed JWT object. | ||
| * @param context Additional metadata (e.g., claims) that might aid in the check. | ||
| * @return true if the token is revoked/invalid; false if it is still active. | ||
| * @throws RevocationCheckException if the check fails due to system errors. | ||
| */ | ||
| boolean isRevoked(String token, Map<String, Object> context) throws RevocationCheckException; | ||
| } |
There was a problem hiding this comment.
In this interface snippet, the Javadoc says the token parameter can be a parsed JWT object, but the method signature only accepts a String. Please adjust the Javadoc (or the signature) so they are consistent.
| | `audience` | The expected audience value that must be present in the `aud` claim of the JWT. This ensures the token is intended for this API. <br/><br/>`<property name="audience" value="https://api.orders.com"/>` | Optional | None | | ||
| | `maxIssuedAtAgeSeconds` | Defines the maximum lifespan allowed for a token since it was issued (`iat`), regardless of the expiration time. <br/><br/>`<property name="maxIssuedAtAgeSeconds" value="18000"/>` | Optional | None | | ||
| | `removeOAuthHeadersFromOutMessage` | A flag to indicate whether to remove the OAuth-related headers (e.g., Authorization header) from the message before sending it to the backend. This can help prevent sensitive information from being exposed to backend services. <br/><br/>`<property name="removeOAuthHeadersFromOutMessage" value="true"/>` | Optional | true | | ||
| | `tokenRevocationHandler` | The fully qualified class name of a custom token revocation handler that implements the `TokenRevocationHandler` interface. This allows you to plug in custom logic to check if a token has been revoked (e.g., by checking a database or cache). <br/><br/>`<property name="tokenRevocationHandler" value="org.sample.customRecovationHandler"/>` | Optional | None | |
There was a problem hiding this comment.
The example class name org.sample.customRecovationHandler appears to have a spelling mistake ("Recovation" vs "Revocation"). Fixing this avoids copy/paste errors for readers implementing the extension.
Suggested change
| | `tokenRevocationHandler` | The fully qualified class name of a custom token revocation handler that implements the `TokenRevocationHandler` interface. This allows you to plug in custom logic to check if a token has been revoked (e.g., by checking a database or cache). <br/><br/>`<property name="tokenRevocationHandler" value="org.sample.customRecovationHandler"/>` | Optional | None | | |
| | `tokenRevocationHandler` | The fully qualified class name of a custom token revocation handler that implements the `TokenRevocationHandler` interface. This allows you to plug in custom logic to check if a token has been revoked (e.g., by checking a database or cache). <br/><br/>`<property name="tokenRevocationHandler" value="org.sample.customRevocationHandler"/>` | Optional | None | |
| <html> | ||
| <div class="admonition note"> | ||
| <p class="admonition-title">Note</p> | ||
| <p>The security key is case -insensitive. Whether you write oauth2, OAuth2, or OAUTH2, the handler will correctly identify it. </p> |
There was a problem hiding this comment.
In the OpenAPI guidance, the note says the security scheme key is case-insensitive, but the sample comment says it "must match" the name "oauth2" while using OAuth2. This is internally inconsistent; please update either the note or the sample/comment so they agree.
Suggested change
| <p>The security key is case -insensitive. Whether you write oauth2, OAuth2, or OAUTH2, the handler will correctly identify it. </p> | |
| <p>The security key is case-sensitive. You must use the key name <code>oauth2</code> exactly as shown here so that the handler can correctly identify it.</p> |
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
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.
$subject
Summary by CodeRabbit
Documentation