Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update and clarify JWT docs #6963

Merged
merged 5 commits into from
Oct 12, 2023
Merged

Update and clarify JWT docs #6963

merged 5 commits into from
Oct 12, 2023

Conversation

ayoho
Copy link
Member

@ayoho ayoho commented Oct 11, 2023

Add some sections on JWK usage in the JWT builder and consumer doc.

For OpenLiberty/open-liberty#26453

@ayoho ayoho self-assigned this Oct 11, 2023

JWT builders will dynamically generate JWKs to use when the `jwkEnabled` attribute for the `jwtBuilder` element is set to `true`. A new key is generated when the JWT builder creates its first token, or when the JWK endpoint for the builder is invoked, whichever happens first. After creation, the key is rotated automatically every 12 hours.

Dynamically generated JWKs are useful for server administrators that do not want to be concerned with setting up a keystore and signing key for the JWT builder. Server admins need only set the `jwkEnabled` attribute to `true`, and Liberty will handle creation and maintenance of the key. Note that when `jwkEnabled` is set to `true`, the `keyStoreRef` and `keyAlias` attributes will be ignored.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Dynamically generated JWKs are useful for server administrators that do not want to be concerned with setting up a keystore and signing key for the JWT builder. Server admins need only set the `jwkEnabled` attribute to `true`, and Liberty will handle creation and maintenance of the key. Note that when `jwkEnabled` is set to `true`, the `keyStoreRef` and `keyAlias` attributes will be ignored.
Dynamically generated JWKs are useful for server administrators that do not want to be concerned with setting up a keystore and signing key for the JWT builder. Server administrators only need to set the `jwkEnabled` attribute to `true`, and Liberty will handle creation and maintenance of the key. Note that when `jwkEnabled` is set to `true`, the `keyStoreRef` and `keyAlias` attributes will be ignored.


JWT consumers can retrieve JSON Web Key Set (JWKS) documents to reconstruct public keys to use for verifying token signatures. JWKS documents are particularly useful for JWT consumers that receive tokens from issuers that frequently rotate their signing keys, and for server administrators who do not want to manually maintain a keystore.

The `jwkEnabled` attribute in the `jwtConsumer` element must be set to `true`, and the `jwkEndpointUrl` attribute must be set to a URI that provides the JWKS document containing the public keys to use to verify the signatures of tokens received by this JWT consumer.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The `jwkEnabled` attribute in the `jwtConsumer` element must be set to `true`, and the `jwkEndpointUrl` attribute must be set to a URI that provides the JWKS document containing the public keys to use to verify the signatures of tokens received by this JWT consumer.
The `jwkEnabled` attribute in the `jwtConsumer` element must be set to `true`, and the `jwkEndpointUrl` attribute must be set to a URI that provides the JWKS document containing the public keys to use to verify the signatures of the tokens received by this JWT consumer.

@ayoho ayoho requested a review from dmuelle October 11, 2023 17:39
@dmuelle
Copy link
Member

dmuelle commented Oct 11, 2023

opened #6964 to track on docs side

Copy link
Member

@dmuelle dmuelle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ho @ayoho - thanks for opening this. Some general comments before I review/edit

The Examples sections on the feature pages are intended to be for concise configuration examples that demonstrate common tasks. The info in this PR seems more like conceptual information to support JWT Builder. Is it possible to revise this information to be focused on config examples that demonstrate the main ideas? It might also make the sections more concise if we show rather than tell the config details, and just provide context in the example descriptions.

Also, the OL website does not really recognize h4 or h5 headings. But if the info was broken up into examples, we could just use h3 for each example.

I'm happy to help revise the info you have here. If the information is better presented as conceptual topic, we can create a new topic and link it form this page. Let me know what you think. Thanks!

@ayoho
Copy link
Member Author

ayoho commented Oct 11, 2023

Hi, @dmuelle. I'd agree that the content is primarily conceptual. Perhaps revamping the https://openliberty.io/docs/latest/single-sign-on.html#_json_web_token_jwt section and maybe even having a standalone page under the Security section for JSON Web Tokens would be a better place to have this information. I can create a new modules/ROOT/pages/json-web-token.adoc page for this content, but if we go that route I might need some more help with how to get it correctly hooked into the site. Looks like I'd update modules/ROOT/nav.adoc to add a link to the new page where I want under the Security section. Anything else?

@dmuelle
Copy link
Member

dmuelle commented Oct 11, 2023

that's all you need to do- BUT - when you update the nav, make that change in the draft-nav branch and create a separate PR to draft. We have dedicated branches just for updating the draft and staging nav files to avoid merge conflicts since the nav is different on draft vs staging/vNext.

@dmuelle
Copy link
Member

dmuelle commented Oct 11, 2023

@ayoho
Copy link
Member Author

ayoho commented Oct 12, 2023

@dmuelle I moved all my new content into a separate json-web-token.adoc page. I'll open a separate PR for the nav changes.

Copy link
Member

@dmuelle dmuelle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@dmuelle dmuelle merged commit 41eb35d into draft Oct 12, 2023
@dmuelle
Copy link
Member

dmuelle commented Oct 12, 2023

I'm merging this to draft and will review further and make edits for IBM style etc in a new PR

@ayoho ayoho deleted the jwtUpdates branch October 13, 2023 16:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants