The information you provide here will be included in the Open Liberty GA release blog post (example), which will be published on openliberty.io/blog/, and potentially elsewhere, to promote this newly released feature/function of Open Liberty. For this post to be included in the GA issue please make sure that this is completed by the end of Friday following the GM (Wednesday). The beta and release blogs are created using automation and rely on you following the template's structure. DO NOT REMOVE/ALTER THE <GHA> TAGS THROUGHOUT THIS TEMPLATE.
Please provide the following information:
If this was previously published in a beta blog post, then provide a link to it on the next line between the <GHA-BLOG-BETA-LINK> tags. If nothing has changed since the beta, you're done and can ommit the remaining steps. If you need to make updates/alterations to the beta content, then do all the steps.
Which Liberty feature(s) does your update relate to?
Human-readable name (eg WebSockets feature): OpenID Connect Client 1.0, Social Media Login 1.0
Short feature name (eg websockets-1.0): openidConnectClient-1.0, socialLogin-1.0
Who is the target persona? Who do you expect to use the update? eg application developer, operations.
Server admins.
Provide a summary of the update, including the following points:
A sentence or two that introduces the update to someone new to the general technology/concept.
What was the problem before and how does your update make their life better? (Why should they care?)
Briefly explain how to make your update work. Include screenshots, diagrams, and/or code snippets, and provide a server.xml snippet.
Where can they find out more about this specific update (eg Open Liberty docs, Javadoc) and/or the wider technology?
OpenID Connect clients in Liberty now support the private_key_jwt client authentication method with OpenID Connect token endpoints.
OpenID Connect clients are required to provide authentication data to the OpenID Connect provider when they invoke the provider’s token endpoint. Clients can authenticate using several different methods, but most of those methods require a client secret. The private_key_jwt authentication method enables clients to use asymmetric keys to create signed JSON Web Tokens (JWTs) to authenticate instead of client secrets. OpenID Connect clients using this authentication method are no longer required to have a client secret.
Server administrators can enable this functionality using the private_key_jwt option for the tokenEndpointAuthMethod attribute, as well as the tokenEndpointAuthSigningAlgorithm and keyAliasName attributes in either the openidConnectClient or oidcLogin elements in their server.xml file.
For example, when you use the OpenID Connect Client feature, include configuration similar to the following example:
The tokenEndpointAuthSigningAlgorithm attribute specifies the signing algorithm to sign the JWT that is used for client authentication. The keyAliasName attribute points to the key to use to sign the JWT, and must also be the alias for the public key that corresponds to the private key. The private key must be in the keystore that is specified by the SSL configuration that is referenced by sslRef in the OIDC client configuration. The public key must be in one of the following: the truststore that is specified by the trustStoreRef attribute, the truststore that is specified by the SSL configuration that is referenced by sslRef, or the keystore that is specified by the SSL configuration that is referenced by sslRef.
Add the label for the GA you're targeting: target:YY00X.
Make sure this blog post is linked back to the Epic for this feature/function.
Your paragraph will be included in the GA release blog post. It might be edited for style and consistency.
You will be asked to review a draft before publication.
Once you've approved the code review, close this issue.
If you would also like to write a standalone blog post about your update (highly recommended), raise an issue on the Open Liberty blogs repo. State in the issue that the blog post relates to a specific release so that we can ensure it is published on an appropriate date (it won't be the same day as the GA blog post).
ayoho
commented
1 year ago
The information you provide here will be included in the Open Liberty GA release blog post (example), which will be published on openliberty.io/blog/, and potentially elsewhere, to promote this newly released feature/function of Open Liberty. For this post to be included in the GA issue please make sure that this is completed by the end of Friday following the GM (Wednesday). The beta and release blogs are created using automation and rely on you following the template's structure. DO NOT REMOVE/ALTER THE
<GHA>TAGS THROUGHOUT THIS TEMPLATE.Please provide the following information:
If this was previously published in a beta blog post, then provide a link to it on the next line between the
<GHA-BLOG-BETA-LINK>tags. If nothing has changed since the beta, you're done and can ommit the remaining steps. If you need to make updates/alterations to the beta content, then do all the steps.Which Liberty feature(s) does your update relate to?
Human-readable name (eg WebSockets feature): OpenID Connect Client 1.0, Social Media Login 1.0
Short feature name (eg websockets-1.0): openidConnectClient-1.0, socialLogin-1.0
Who is the target persona? Who do you expect to use the update? eg application developer, operations. Server admins.
Provide a summary of the update, including the following points:
A sentence or two that introduces the update to someone new to the general technology/concept.
What was the problem before and how does your update make their life better? (Why should they care?)
Briefly explain how to make your update work. Include screenshots, diagrams, and/or code snippets, and provide a
server.xmlsnippet.Where can they find out more about this specific update (eg Open Liberty docs, Javadoc) and/or the wider technology?
OpenID Connect clients in Liberty now support the
private_key_jwtclient authentication method with OpenID Connect token endpoints.OpenID Connect clients are required to provide authentication data to the OpenID Connect provider when they invoke the provider’s token endpoint. Clients can authenticate using several different methods, but most of those methods require a client secret. The
private_key_jwtauthentication method enables clients to use asymmetric keys to create signed JSON Web Tokens (JWTs) to authenticate instead of client secrets. OpenID Connect clients using this authentication method are no longer required to have a client secret.Server administrators can enable this functionality using the
private_key_jwtoption for thetokenEndpointAuthMethodattribute, as well as thetokenEndpointAuthSigningAlgorithmandkeyAliasNameattributes in either theopenidConnectClientoroidcLoginelements in their server.xml file.For example, when you use the OpenID Connect Client feature, include configuration similar to the following example:
If you are using the Social Media Login feature, include configuration similar to the following example:
The
tokenEndpointAuthSigningAlgorithmattribute specifies the signing algorithm to sign the JWT that is used for client authentication. ThekeyAliasNameattribute points to the key to use to sign the JWT, and must also be the alias for the public key that corresponds to the private key. The private key must be in the keystore that is specified by the SSL configuration that is referenced bysslRefin the OIDC client configuration. The public key must be in one of the following: the truststore that is specified by thetrustStoreRefattribute, the truststore that is specified by the SSL configuration that is referenced bysslRef, or the keystore that is specified by the SSL configuration that is referenced by sslRef.For more information about the configuration options, refer to the docs for the openidConnectClient element and the oidcLogin element.
For more information about private_key_jwt client authentication, refer to the OpenID Connect core specification and RFC 7523.
What happens next?
target:YY00X.