From ba106c0efdb5fc6cb5af578e32d3524ff5c962cb Mon Sep 17 00:00:00 2001 From: Emmanuel Bernard Date: Fri, 2 Jun 2023 11:11:34 +0200 Subject: [PATCH 1/6] OIDC Doc - Improve OIDC documentation with specific newbie context Also lighten some sentences en passant and split notes into Asciidoc based notes for more readability. --- ...oidc-code-flow-authentication-concept.adoc | 86 +++++++++++++------ 1 file changed, 60 insertions(+), 26 deletions(-) diff --git a/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc b/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc index 539da66f5bbe6..d1e95cf8c046d 100644 --- a/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc +++ b/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc @@ -8,7 +8,7 @@ https://github.com/quarkusio/quarkus/tree/main/docs/src/main/asciidoc include::_attributes.adoc[] :categories: security,web -To protect your web applications, you can use the authorization code flow mechanism provided by the Quarkus OpenID Connect (OIDC) extension. +To protect your web applications, you can use the industry standard authorization code flow mechanism provided by the Quarkus OpenID Connect (OIDC) extension. == Overview of the OIDC authorization code flow mechanism @@ -33,7 +33,7 @@ The authorization code flow is completed and the Quarkus web-app uses the tokens The following tokens are issued: * ID token: The Quarkus web-app uses the user information in the ID token to enable the authenticated user to log in securely and to provide role-based access to the web-app. -* Access token: The Quarkus web-app might use the access token to access the UserInfo API to get additional information about the authenticated user or propagate it to another endpoint. +* Access token: The Quarkus web-app might use the access token to access the UserInfo API to get additional information about the authenticated user or to propagate it to another endpoint. * Refresh token: (Optional) If the ID and access tokens expire, the Quarkus web-app can use the refresh token to get new ID and access tokens. See also the xref:security-oidc-configuration-properties-reference.adoc[OIDC configuration properties] reference guide. @@ -51,6 +51,7 @@ For information about how to support multiple tenants, see xref:security-openid- The OIDC code authentication mechanism acquires three tokens during the authorization code flow: https://openid.net/specs/openid-connect-core-1_0.html#IDToken[IDToken], Access Token, and Refresh Token. ID Token is always a JWT token and is used to represent a user authentication with the JWT claims. +You can for example get which OIDC enpoint issued it, the user name and other information called _claims_. One can access ID Token claims by injecting `JsonWebToken` with an `IdToken` qualifier: [source, java] @@ -107,16 +108,17 @@ public class ProtectedResource { } ---- -Note that `AccessTokenCredential` will have to be used if the Access Token issued to the Quarkus `web-app` application is opaque (binary) and can not be parsed to `JsonWebToken`. +Note that `AccessTokenCredential` is used if the Access Token issued to the Quarkus `web-app` application is opaque (binary) and can not be parsed to a `JsonWebToken` or if the inner content is necessary for the application. Injection of the `JsonWebToken` and `AccessTokenCredential` is supported in both `@RequestScoped` and `@ApplicationScoped` contexts. -RefreshToken is only used to refresh the current ID and access tokens as part of its <> process. +RefreshToken is used (by Quarkusn OIDC) to refresh the current ID and access tokens as part of its <> process. [[user-info]] === User info -If the ID token does not provide enough information about the currently-authenticated user, then you can set a `quarkus.oidc.authentication.user-info-required=true` property for a https://openid.net/specs/openid-connect-core-1_0.html#UserInfo[UserInfo] JSON object from the OIDC userinfo endpoint to be requested. +If the ID token does not provide enough information about the currently-authenticated user, you can get more information from the user info endpoint. +Set the `quarkus.oidc.authentication.user-info-required=true` property for a https://openid.net/specs/openid-connect-core-1_0.html#UserInfo[UserInfo] JSON object from the OIDC userinfo endpoint to be requested. A request will be sent to the OpenID Provider UserInfo endpoint using the access token returned with the authorization code grant response and an `io.quarkus.oidc.UserInfo` (a simple `jakarta.json.JsonObject` wrapper) object will be created. `io.quarkus.oidc.UserInfo` can be either injected or accessed as a SecurityIdentity `userinfo` attribute. @@ -132,9 +134,11 @@ The default tenant's `OidcConfigurationMetadata` is injected if the endpoint is The way the roles are mapped to the SecurityIdentity roles from the verified tokens is identical to how it is done for the xref:security-oidc-bearer-token-authentication-concept.adoc[Bearer tokens] with the only difference being that https://openid.net/specs/openid-connect-core-1_0.html#IDToken[ID Token] is used as a source of the roles by default. -Note if you use Keycloak then you should set a `microprofile_jwt` client scope for ID token to contain a `groups` claim, please see the https://www.keycloak.org/docs/latest/server_admin/#protocol[Keycloak Server Administration Guide] for more information. +If you use Keycloak then you should set a `microprofile_jwt` client scope for ID token to contain a `groups` claim, please see the https://www.keycloak.org/docs/latest/server_admin/#protocol[Keycloak Server Administration Guide] for more information. -If only the access token contains the roles and this access token is not meant to be propagated to the downstream endpoints then set `quarkus.oidc.roles.source=accesstoken`. +But depending on your OIDC provider, roles might be stored in the access token or the user info. + +If the access token contains the roles and this access token is not meant to be propagated to the downstream endpoints then set `quarkus.oidc.roles.source=accesstoken`. If UserInfo is the source of the roles then set `quarkus.oidc.roles.source=userinfo`, and if needed, `quarkus.oidc.roles.role-claim-path`. @@ -143,14 +147,20 @@ Additionally, a custom `SecurityIdentityAugmentor` can also be used to add the r [[token-verification-introspection]] === Token verification and introspection -Please see xref:security-oidc-bearer-token-authentication-concept.adoc#token-verification-introspection[Token Verification And Introspection] for details about how the tokens are verified and introspected. +OIDC inherits the bearer authentication token verification and introspection logic described in detail at xref:security-oidc-bearer-token-authentication-concept.adoc#token-verification-introspection[Token Verification And Introspection]. -Note that in case of `web-app` applications only `IdToken` is verified by default since the access token is not used by default to access the current Quarkus `web-app` endpoint and instead meant to be propagated to the services expecting this access token, for example, to the OpenID Connect Provider's UserInfo endpoint, and so on. However, if you expect the access token to contain the roles required to access the current Quarkus endpoint (`quarkus.oidc.roles.source=accesstoken`) then it will also be verified. +[NOTE] +-- +In case of `web-app` applications, only the `IdToken` is verified by default since the access token is not used to access the current Quarkus `web-app` endpoint and rather meant to be propagated to the services expecting this access token. +If you expect the access token to contain the roles required to access the current Quarkus endpoint (`quarkus.oidc.roles.source=accesstoken`) then it will also be verified. +-- [[token-introspection-userinfo-cache]] === Token introspection and UserInfo cache -Code flow access tokens are not introspected unless they are expected to be the source of roles but will be used to get `UserInfo`. So there will be one or two remote calls with the code flow access token, if the token introspection and/or `UserInfo` are required. +Code flow access tokens are not introspected unless they are expected to be the source of roles. +It will however be used to get `UserInfo`. +There will be one or two remote calls with the code flow access token, if the token introspection and/or `UserInfo` are required. Please see xref:security-oidc-bearer-token-authentication-concept.adoc#token-introspection-userinfo-cache[Token Introspection and UserInfo cache] for more information about using a default token cache or registering a custom cache implementation. @@ -163,33 +173,38 @@ It applies to ID tokens but also to access tokens in a JWT format if the `web-ap === Redirection When the user is redirected to the OpenID Connect Provider to authenticate, the redirect URL includes a `redirect_uri` query parameter which indicates to the provider where the user has to be redirected to once the authentication has been completed. +In our case, this is the Quarkus application. -Quarkus will set this parameter to the current request URL by default. For example, if the user is trying to access a Quarkus service endpoint at `http://localhost:8080/service/1` then the `redirect_uri` parameter will be set to `http://localhost:8080/service/1`. Similarly, if the request URL is `http://localhost:8080/service/2` then the `redirect_uri` parameter will be set to `http://localhost:8080/service/2`, etc. +Quarkus will set this parameter to the current application request URL by default. For example, if the user is trying to access a Quarkus service endpoint at `http://localhost:8080/service/1` then the `redirect_uri` parameter will be set to `http://localhost:8080/service/1`. Similarly, if the request URL is `http://localhost:8080/service/2` then the `redirect_uri` parameter will be set to `http://localhost:8080/service/2`, etc. -OpenID Connect Providers may be configured to require the `redirect_uri` parameter to have the same value (e.g. `http://localhost:8080/service/callback`) for all the redirect URLs. +Some OpenID Connect Providers require the `redirect_uri` to have the same value for a given application (e.g. `http://localhost:8080/service/callback`) for all the redirect URLs. In such cases, a `quarkus.oidc.authentication.redirect-path` property has to be set, for example, `quarkus.oidc.authentication.redirect-path=/service/callback`, and Quarkus will set the `redirect_uri` parameter to an absolute URL such as `http://localhost:8080/service/callback` which will be the same regardless of the current request URL. -If `quarkus.oidc.authentication.redirect-path` is set but the original request URL has to be restored after the user has been redirected back to a callback URL such as `http://localhost:8080/service/callback` then a `quarkus.oidc.authentication.restore-path-after-redirect` property has to be set to `true` which will restore the request URL such as `http://localhost:8080/service/1`, and so on. +If `quarkus.oidc.authentication.redirect-path` is set but +If you need the original request URL to be restored after the user has been redirected back to a unique callback URL such as `http://localhost:8080/service/callback`, set `quarkus.oidc.authentication.restore-path-after-redirect` property to `true`. +This will restore the request URL such as `http://localhost:8080/service/1`. [[oidc-cookies]] === Cookies The OIDC adapter uses cookies to keep the session, code flow, and post-logout state. +This state is a key element controlling the life time of authentication data. -`quarkus.oidc.authentication.cookie-path` property is used to ensure the cookies are visible especially when you access the protected resources with overlapping or different roots, for example: +`quarkus.oidc.authentication.cookie-path` property is used to ensure the same cookie is visible when you access the protected resources with overlapping or different roots, for example: * `/index.html` and `/web-app/service` * `/web-app/service1` and `/web-app/service2` * `/web-app1/service` and `/web-app2/service` -`quarkus.oidc.authentication.cookie-path` is set to `/` by default but can be narrowed to the more specific root path such as `/web-app`. +`quarkus.oidc.authentication.cookie-path` is set to `/` by default but can be narrowed to a more specific root path such as `/web-app`. -You can also set a `quarkus.oidc.authentication.cookie-path-header` property if the cookie path needs to be set dynamically. +Sometimes the cookie path needs to be set dynamically. +Set the `quarkus.oidc.authentication.cookie-path-header` property. For example, setting `quarkus.oidc.authentication.cookie-path-header=X-Forwarded-Prefix` means that the value of HTTP `X-Forwarded-Prefix` header will be used to set a cookie path. If `quarkus.oidc.authentication.cookie-path-header` is set but no configured HTTP header is available in the current request then the `quarkus.oidc.authentication.cookie-path` will be checked. -If your application is deployed across multiple domains, make sure to set a `quarkus.oidc.authentication.cookie-domain` property for the session cookie be visible to all protected Quarkus services, for example, if you have 2 services deployed at: +If your application is deployed across multiple domains, set a `quarkus.oidc.authentication.cookie-domain` property for the session cookie be visible to all protected Quarkus services, for example, if you have 2 services deployed at: * https://whatever.wherever.company.net/ * https://another.address.company.net/ @@ -217,7 +232,7 @@ If the `quarkus.oidc.logout.post-logout-path` is set then a `q_post_logout` cook Note that a cookie name will vary when using xref:security-openid-connect-multitenancy.adoc[OpenID Connect Multi-Tenancy]. For example, it will be named `q_post_logout_tenant_1` for a tenant with a `tenant_1` ID, and so on. -Here is an example of how to configure an RP initiated logout flow: +Here is an example of how to configure a Quarkus app initiated logout flow: [source,properties] ---- @@ -242,7 +257,9 @@ quarkus.http.auth.permission.public.policy=permit You may also need to set `quarkus.oidc.authentication.cookie-path` to a path value common to all the application resources which is `/` in this example. For more information, see the <> section. -Note that some OpenID Connect providers do not support https://openid.net/specs/openid-connect-session-1_0.html#RPLogout[RP-Initiated Logout] specification (possibly because it is still technically a draft) and do not return an OpenID Connect well-known `end_session_endpoint` metadata property. However, it should not be a problem since these providers' specific logout mechanisms may only differ in how the logout URL query parameters are named. +[NOTE] +-- +Some OpenID Connect providers do not support https://openid.net/specs/openid-connect-session-1_0.html#RPLogout[RP-Initiated Logout] specification (possibly because it is still technically a draft) and do not return an OpenID Connect well-known `end_session_endpoint` metadata property. However, it is not be a problem since these providers' specific logout mechanisms only differ in how the logout URL query parameters are named. According to the https://openid.net/specs/openid-connect-session-1_0.html#RPLogout[RP-Initiated Logout] specification, the `quarkus.oidc.logout.post-logout-path` property is represented as a `post_logout_redirect_uri` query parameter which will not be recognized by the providers which do not support this specification. @@ -267,9 +284,11 @@ quarkus.oidc.logout.post-logout-uri-param=returnTo # For example, if 'client_id' is provided then a valid logout URI should be set as Auth0 Application property, without it - as Auth0 Tenant property. quarkus.oidc.logout.extra-params.client_id=${quarkus.oidc.client-id} ---- +-- [[back-channel-logout]] -==== Back-channel logout +The OIDC provider can force the logout of all applications using the authentification data: this is called back-channel logout. +In this case the OIDC will call a specific URL from each application to trigger that logout. link:https://openid.net/specs/openid-connect-backchannel-1_0.html[Back-Channel Logout] is used by OpenID Connect providers to log out the current user from all the applications this user is currently logged in, bypassing the user agent. @@ -292,7 +311,9 @@ Note that you will also need to configure a token age property for the logout to [[front-channel-logout]] ==== Front-channel logout -link:https://openid.net/specs/openid-connect-frontchannel-1_0.html[Front-Channel Logout] can be used to logout the current user directly from the user agent. +link:https://openid.net/specs/openid-connect-frontchannel-1_0.html[Front-Channel Logout] can be used to logout the current user directly from the user agent (e.g. its browser). +It is like <> but the logout steps are executed by the user agent like the browser and not in the background by the OIDP provider. +This option is rarely used. You can configure Quarkus to support `Front-Channel Logout` as follows: @@ -309,9 +330,12 @@ quarkus.oidc.logout.frontchannel.path=/front-channel-logout This path will be compared against the current request's path and the user will be logged out if these paths match. [[local-logout]] -==== Local logout +<> will log the person out from the OIDC provider, if it is used as single sign on, it might not be what you desire. +If for example your OIDC provider is Google, you will be logged out from Google and its services. +Instead the user might just want to log out of that specific application. +Another use case if if the OIDC provider does not have a logout endpoint. -If you work with a social provider such as Google and are concerned that the users can be logged out from all their Google applications with the <> which redirects the users to the provider's logout endpoint then you can support a local logout with the help of the <> which only clears the local session cookie, for example: +You can support a local logout with the help of the <> which only clears the local session cookie, for example: [source,java] ---- @@ -338,19 +362,29 @@ public class ServiceResource { [[session-management]] === Session management +[TIP] +-- If you have a xref:security-oidc-bearer-token-authentication-concept.adoc#single-page-applications[Single Page Application for Service Applications] where your OpenID Connect Provider script such as `keycloak.js` is managing an authorization code flow then that script will also control the SPA authentication session lifespan. +-- If you work with a Quarkus OIDC `web-app` application then it is Quarkus OIDC Code Authentication mechanism which is managing the user session lifespan. +To use the refresh token, you should carefully configure the various lifespan of the ID token, the refresh token, the cookie, etc so they work in tandem. +The so called session age should be longer than the ID token lifespan and close to or equal to the refresh token lifespan. + The session age is calculated by adding the lifespan value of the current IDToken and the values of the `quarkus.oidc.authentication.session-age-extension` and `quarkus.oidc.token.lifespan-grace` properties. Of the last two properties only `quarkus.oidc.authentication.session-age-extension` should be used to significantly extend the session lifespan if required since `quarkus.oidc.token.lifespan-grace` is only meant for taking some small clock skews into consideration. When the currently authenticated user returns to the protected Quarkus endpoint and the ID token associated with the session cookie has expired then, by default, the user will be auto-redirected to the OIDC Authorization endpoint to re-authenticate. Most likely the OIDC provider will challenge the user again though not necessarily if the session between the user and this OIDC provider is still active which may happen if it is configured to last longer than the ID token. -If the `quarkus.oidc.token.refresh-expired` then the expired ID token (as well as the access token) will be refreshed using the refresh token returned with the authorization code grant response. This refresh token may also be recycled (refreshed) itself as part of this process. As a result the new session cookie will be created and the session will be extended. +If the `quarkus.oidc.token.refresh-expired` is set to `true`, then the expired ID token (as well as the access token) will be refreshed using the refresh token returned with the initial authorization code grant response. This refresh token may also be recycled (refreshed) itself as part of this process. As a result the new session cookie will be created and the session will be extended. -Note, `quarkus.oidc.authentication.session-age-extension` can be important when dealing with expired ID tokens, when the user is not very active. In such cases, if the ID token expires, then the session cookie may not be returned to the Quarkus endpoint during the next user request and Quarkus will assume it is the first authentication request. Therefore, using `quarkus.oidc.authentication.session-age-extension` is important if you need to have even the expired ID tokens refreshed. +[NOTE] +-- +`quarkus.oidc.authentication.session-age-extension` can be important when dealing with expired ID tokens, when the user is not very active. If the ID token expires, then the session cookie may not be returned to the Quarkus endpoint during the next user request as the cookie lifespan would ahve elapsed. Quarkus will assume it is the first authentication request. Set `quarkus.oidc.authentication.session-age-extension` to be _reasonably_ long for your barely active users and in accordance with your security policies. +-- -You can also complement refreshing the expired ID tokens by proactively refreshing the valid ID tokens which are about to be expired within the `quarkus.oidc.token.refresh-token-time-skew` value. If, during the current user request, it is calculated that the current ID token will expire within this `quarkus.oidc.token.refresh-token-time-skew` then it will be refreshed and the new session cookie will be created. This property should be set to a value which is less than the ID token lifespan; the closer it is to this lifespan value the more often the ID token will be refreshed. +You can go one step further and proactively refresh ID tokens or access tokens that are about to expire. +Set `quarkus.oidc.token.refresh-token-time-skew` to the value you want to anticipate the refresh. If, during the current user request, it is calculated that the current ID token will expire within this `quarkus.oidc.token.refresh-token-time-skew` then it will be refreshed and the new session cookie will be created. This property should be set to a value which is less than the ID token lifespan; the closer it is to this lifespan value the more often the ID token will be refreshed. You can have this process further optimized by having a simple JavaScript function periodically emulating the user activity by pinging your Quarkus endpoint thus minimizing the window during which the user may have to be re-authenticated. From 8343d9d7ee44c4e4adf26604d2e9aa703cf3dbad Mon Sep 17 00:00:00 2001 From: Emmanuel Bernard Date: Fri, 2 Jun 2023 11:15:34 +0200 Subject: [PATCH 2/6] OIDC doc - Reorganize doc structure for easier flow and context Group logout and expiration, group token validity subjects, create integration consideration section Change TOC level for better navigation. --- ...oidc-code-flow-authentication-concept.adoc | 256 ++++++++++-------- 1 file changed, 145 insertions(+), 111 deletions(-) diff --git a/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc b/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc index d1e95cf8c046d..53cdfc5205a6c 100644 --- a/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc +++ b/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc @@ -7,6 +7,7 @@ https://github.com/quarkusio/quarkus/tree/main/docs/src/main/asciidoc = OpenID Connect authorization code flow mechanism for protecting web applications include::_attributes.adoc[] :categories: security,web +:toclevels: 4 To protect your web applications, you can use the industry standard authorization code flow mechanism provided by the Quarkus OpenID Connect (OIDC) extension. @@ -45,8 +46,12 @@ For information about how to support multiple tenants, see xref:security-openid- == Using the authorization code flow mechanism +=== Accessing authorization data + +Let's first discuss how to access information around authorization. + [[access_id_and_access_tokens]] -=== Accessing ID and access tokens +==== Accessing ID and access tokens //SJ: new concept topic to describe the different token types and usage proposed in next iteration The OIDC code authentication mechanism acquires three tokens during the authorization code flow: https://openid.net/specs/openid-connect-core-1_0.html#IDToken[IDToken], Access Token, and Refresh Token. @@ -115,7 +120,7 @@ Injection of the `JsonWebToken` and `AccessTokenCredential` is supported in both RefreshToken is used (by Quarkusn OIDC) to refresh the current ID and access tokens as part of its <> process. [[user-info]] -=== User info +==== User info If the ID token does not provide enough information about the currently-authenticated user, you can get more information from the user info endpoint. Set the `quarkus.oidc.authentication.user-info-required=true` property for a https://openid.net/specs/openid-connect-core-1_0.html#UserInfo[UserInfo] JSON object from the OIDC userinfo endpoint to be requested. @@ -123,18 +128,21 @@ Set the `quarkus.oidc.authentication.user-info-required=true` property for a htt A request will be sent to the OpenID Provider UserInfo endpoint using the access token returned with the authorization code grant response and an `io.quarkus.oidc.UserInfo` (a simple `jakarta.json.JsonObject` wrapper) object will be created. `io.quarkus.oidc.UserInfo` can be either injected or accessed as a SecurityIdentity `userinfo` attribute. [[config-metadata]] -=== Configuration metadata +==== Accessing the OIDC configuration information The current tenant's discovered link:https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata[OpenID Connect Configuration Metadata] is represented by `io.quarkus.oidc.OidcConfigurationMetadata` and can be either injected or accessed as a `SecurityIdentity` `configuration-metadata` attribute. The default tenant's `OidcConfigurationMetadata` is injected if the endpoint is public. [[token-claims-roles]] -=== Token claims and SecurityIdentity roles +==== Mapping Token claims and SecurityIdentity roles The way the roles are mapped to the SecurityIdentity roles from the verified tokens is identical to how it is done for the xref:security-oidc-bearer-token-authentication-concept.adoc[Bearer tokens] with the only difference being that https://openid.net/specs/openid-connect-core-1_0.html#IDToken[ID Token] is used as a source of the roles by default. +[NOTE] +-- If you use Keycloak then you should set a `microprofile_jwt` client scope for ID token to contain a `groups` claim, please see the https://www.keycloak.org/docs/latest/server_admin/#protocol[Keycloak Server Administration Guide] for more information. +-- But depending on your OIDC provider, roles might be stored in the access token or the user info. @@ -144,8 +152,13 @@ If UserInfo is the source of the roles then set `quarkus.oidc.roles.source=useri Additionally, a custom `SecurityIdentityAugmentor` can also be used to add the roles. For more information, see xref:security-customization.adoc#security-identity-customization[SecurityIdentity customization]. +=== Ensuring validity of tokens and authentication data + +A core part of the authentication process is ensuring the chain of trust and validity of the information. +This is done by ensuring tokens are trustable. + [[token-verification-introspection]] -=== Token verification and introspection +==== Token verification and introspection OIDC inherits the bearer authentication token verification and introspection logic described in detail at xref:security-oidc-bearer-token-authentication-concept.adoc#token-verification-introspection[Token Verification And Introspection]. @@ -156,7 +169,7 @@ If you expect the access token to contain the roles required to access the curre -- [[token-introspection-userinfo-cache]] -=== Token introspection and UserInfo cache +==== Token introspection and UserInfo cache Code flow access tokens are not introspected unless they are expected to be the source of roles. It will however be used to get `UserInfo`. @@ -165,12 +178,12 @@ There will be one or two remote calls with the code flow access token, if the to Please see xref:security-oidc-bearer-token-authentication-concept.adoc#token-introspection-userinfo-cache[Token Introspection and UserInfo cache] for more information about using a default token cache or registering a custom cache implementation. [[jwt-claim-verification]] -=== JSON web token claim verification +==== JSON web token claim verification Please see xref:security-oidc-bearer-token-authentication-concept.adoc#jwt-claim-verification[JSON Web Token Claim verification] section about the claim verification, including the `iss` (issuer) claim. It applies to ID tokens but also to access tokens in a JWT format if the `web-app` application has requested the access token verification. -=== Redirection +=== Redirecting to and from the OIDC provider When the user is redirected to the OpenID Connect Provider to authenticate, the redirect URL includes a `redirect_uri` query parameter which indicates to the provider where the user has to be redirected to once the authentication has been completed. In our case, this is the Quarkus application. @@ -184,8 +197,14 @@ If `quarkus.oidc.authentication.redirect-path` is set but If you need the original request URL to be restored after the user has been redirected back to a unique callback URL such as `http://localhost:8080/service/callback`, set `quarkus.oidc.authentication.restore-path-after-redirect` property to `true`. This will restore the request URL such as `http://localhost:8080/service/1`. +=== Handling and controlling the life time of authentication + +Another important aspect of authentication is to be sure that data it is based on is fresh while not requiring the user to authenticate at every single request. +There are also situation when a logout is explicitly requested. +This section discusses the various key notions necessarity to find the right balance for your Quarkus application. + [[oidc-cookies]] -=== Cookies +==== Cookies The OIDC adapter uses cookies to keep the session, code flow, and post-logout state. This state is a key element controlling the life time of authentication data. @@ -210,16 +229,103 @@ If your application is deployed across multiple domains, set a `quarkus.oidc.aut * https://another.address.company.net/ then the `quarkus.oidc.authentication.cookie-domain` property must be set to `company.net`. + +[[token-state-manager]] +===== Customizing the cookie with TokenStateManager + +OIDC `CodeAuthenticationMechanism` is using the default `io.quarkus.oidc.TokenStateManager` interface implementation to keep the ID, access and refresh tokens returned in the authorization code or refresh grant responses in a session cookie. It makes Quarkus OIDC endpoints completely stateless. + +Note that some endpoints do not require the access token. An access token is only required if the endpoint needs to retrieve `UserInfo` or access the downstream service with this access token or use the roles associated with the access token (the roles in the ID token are checked by default). In such cases you can set either `quarkus.oidc.token-state-manager.strategy=id-refresh-token` (keep ID and refresh tokens only) or `quarkus.oidc.token-state-manager.strategy=id-token` (keep ID token only). + +If the ID, access and refresh tokens are JWT tokens then combining all of them (if the strategy is the default `keep-all-tokens`) or only ID and refresh tokens (if the strategy is `id-refresh-token`) may produce a session cookie value larger than 4KB and the browsers may not be able to keep this cookie. +In such cases, you can use `quarkus.oidc.token-state-manager.split-tokens=true` to have a unique session token per each of these tokens. + +Note that `TokenStateManager` will encrypt the tokens before storing them in the session cookie. +For example, here is how you configure it to split the tokens and encrypt them: + +[source, properties] +---- +quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus +quarkus.oidc.client-id=quarkus-app +quarkus.oidc.credentials.secret=secret +quarkus.oidc.application-type=web-app +quarkus.oidc.token-state-manager.split-tokens=true +quarkus.oidc.token-state-manager.encryption-secret=eUk1p7UB3nFiXZGUXi0uph1Y9p34YhBU +---- + +The token encryption secret must be at least 32 characters long. If this key is not configured then either `quarkus.oidc.credentials.secret` or `quarkus.oidc.credentials.jwt.secret` will be hashed to create an encryption key. + +`quarkus.oidc.token-state-manager.encryption-secret` should be configured if Quarkus authenticates to OpenId Connect Provider using either mTLS or `private_key_jwt` (where a private RSA or EC key is used to sign a JWT token) authentication methods, otherwise a random key will be generated which will be problematic if the Quarkus application is running in the cloud with multiple pods managing the requests. + +If you need you can disable encrypting the tokens in the session cookie with `quarkus.oidc.token-state-manager.encryption-required=false`. + +Register your own `io.quarkus.oidc.TokenStateManager' implementation as an `@ApplicationScoped` CDI bean if you need to customize the way the tokens are associated with the session cookie. For example, you may want to keep the tokens in a database and have only a database pointer stored in a session cookie. Note though that it may present some challenges in making the tokens available across multiple microservices nodes. + +Here is a simple example: + +[source, java] +---- +package io.quarkus.oidc.test; + +import jakarta.annotation.Priority; +import jakarta.enterprise.context.ApplicationScoped; +import jakarta.enterprise.inject.Alternative; +import jakarta.inject.Inject; + +import io.quarkus.oidc.AuthorizationCodeTokens; +import io.quarkus.oidc.OidcTenantConfig; +import io.quarkus.oidc.TokenStateManager; +import io.quarkus.oidc.runtime.DefaultTokenStateManager; +import io.smallrye.mutiny.Uni; +import io.vertx.ext.web.RoutingContext; + +@ApplicationScoped +@Alternative +@Priority(1) +public class CustomTokenStateManager implements TokenStateManager { + + @Inject + DefaultTokenStateManager tokenStateManager; + + @Override + public Uni createTokenState(RoutingContext routingContext, OidcTenantConfig oidcConfig, + AuthorizationCodeTokens sessionContent, TokenStateManager.CreateTokenStateRequestContext requestContext) { + return tokenStateManager.createTokenState(routingContext, oidcConfig, sessionContent, requestContext) + .map(t -> (t + "|custom")); + } + + @Override + public Uni getTokens(RoutingContext routingContext, OidcTenantConfig oidcConfig, + String tokenState, TokenStateManager.GetTokensRequestContext requestContext) { + if (!tokenState.endsWith("|custom")) { + throw new IllegalStateException(); + } + String defaultState = tokenState.substring(0, tokenState.length() - 7); + return tokenStateManager.getTokens(routingContext, oidcConfig, defaultState, requestContext); + } + + @Override + public Uni deleteTokens(RoutingContext routingContext, OidcTenantConfig oidcConfig, String tokenState, + TokenStateManager.DeleteTokensRequestContext requestContext) { + if (!tokenState.endsWith("|custom")) { + throw new IllegalStateException(); + } + String defaultState = tokenState.substring(0, tokenState.length() - 7); + return tokenStateManager.deleteTokens(routingContext, oidcConfig, defaultState, requestContext); + } +} +---- //SJ: In next iteration, propose to recompose Logout information into a new concept topic -=== Logout +==== Logout and expiration -By default, the logout is based on the expiration time of the ID Token issued by the OpenID Connect Provider. When the ID Token expires, the current user session at the Quarkus endpoint is invalidated and the user is redirected to the OpenID Connect Provider again to authenticate. If the session at the OpenID Connect Provider is still active, users are automatically re-authenticated without having to provide their credentials again. +There are two main ways for the authentication information to expire: the tokens are expired and no longer renewed or an explicit logout operation is triggered. + +Let's start with explicit logout operations. -The current user session may be automatically extended by enabling a `quarkus.oidc.token.refresh-expired` property. If it is set to `true` then when the current ID Token expires a Refresh Token Grant will be used to refresh ID Token as well as Access and Refresh Tokens. [[user-initiated-logout]] -==== User-initiated logout +===== User-initiated logout Users can request a logout by sending a request to the Quarkus endpoint logout path set with a `quarkus.oidc.logout.path` property. For example, if the endpoint address is `https://application.com/webapp` and the `quarkus.oidc.logout.path` is set to "/logout" then the logout request has to be sent to `https://application.com/webapp/logout`. @@ -287,6 +393,8 @@ quarkus.oidc.logout.extra-params.client_id=${quarkus.oidc.client-id} -- [[back-channel-logout]] +===== Back-channel logout + The OIDC provider can force the logout of all applications using the authentification data: this is called back-channel logout. In this case the OIDC will call a specific URL from each application to trigger that logout. @@ -309,7 +417,7 @@ Absolute `Back-Channel Logout` URL is calculated by adding `quarkus.oidc.back-ch Note that you will also need to configure a token age property for the logout token verification to succeed if your OpenID Connect Provider does not set an expiry claim in the current logout token, for example, `quarkus.oidc.token.age=10S` sets a number of seconds that must not elapse since the logout token's `iat` (issued at) time to 10. [[front-channel-logout]] -==== Front-channel logout +===== Front-channel logout link:https://openid.net/specs/openid-connect-frontchannel-1_0.html[Front-Channel Logout] can be used to logout the current user directly from the user agent (e.g. its browser). It is like <> but the logout steps are executed by the user agent like the browser and not in the background by the OIDP provider. @@ -330,6 +438,8 @@ quarkus.oidc.logout.frontchannel.path=/front-channel-logout This path will be compared against the current request's path and the user will be logged out if these paths match. [[local-logout]] +===== Local logout + <> will log the person out from the OIDC provider, if it is used as single sign on, it might not be what you desire. If for example your OIDC provider is Google, you will be logged out from Google and its services. Instead the user might just want to log out of that specific application. @@ -359,8 +469,17 @@ public class ServiceResource { } ---- +[[oidc-session]] +====== Using OidcSession for local logout + +`io.quarkus.oidc.OidcSession` is a wrapper around the current `IdToken`. It can help to perform a <>, retrieve the current session's tenant identifier and check when the session will expire. More useful methods will be added to it over time. [[session-management]] -=== Session management + +==== Expiration via Session management + +By default, the logout is based on the expiration time of the ID Token issued by the OpenID Connect Provider. When the ID Token expires, the current user session at the Quarkus endpoint is invalidated and the user is redirected to the OpenID Connect Provider again to authenticate. If the session at the OpenID Connect Provider is still active, users are automatically re-authenticated without having to provide their credentials again. + +The current user session may be automatically extended by enabling a `quarkus.oidc.token.refresh-expired` property. If it is set to `true` then when the current ID Token expires a Refresh Token Grant will be used to refresh ID Token as well as Access and Refresh Tokens. [TIP] -- @@ -390,98 +509,8 @@ You can have this process further optimized by having a simple JavaScript functi Note this user session can not be extended forever - the returning user with the expired ID token will have to re-authenticate at the OIDC provider endpoint once the refresh token has expired. -[[oidc-session]] -==== OidcSession - -`io.quarkus.oidc.OidcSession` is a wrapper around the current `IdToken`. It can help to perform a <>, retrieve the current session's tenant identifier and check when the session will expire. More useful methods will be added to it over time. - -[[token-state-manager]] -==== TokenStateManager - -OIDC `CodeAuthenticationMechanism` is using the default `io.quarkus.oidc.TokenStateManager` interface implementation to keep the ID, access and refresh tokens returned in the authorization code or refresh grant responses in a session cookie. It makes Quarkus OIDC endpoints completely stateless. - -Note that some endpoints do not require the access token. An access token is only required if the endpoint needs to retrieve `UserInfo` or access the downstream service with this access token or use the roles associated with the access token (the roles in the ID token are checked by default). In such cases you can set either `quarkus.oidc.token-state-manager.strategy=id-refresh-token` (keep ID and refresh tokens only) or `quarkus.oidc.token-state-manager.strategy=id-token` (keep ID token only). - -If the ID, access and refresh tokens are JWT tokens then combining all of them (if the strategy is the default `keep-all-tokens`) or only ID and refresh tokens (if the strategy is `id-refresh-token`) may produce a session cookie value larger than 4KB and the browsers may not be able to keep this cookie. -In such cases, you can use `quarkus.oidc.token-state-manager.split-tokens=true` to have a unique session token per each of these tokens. - -Note that `TokenStateManager` will encrypt the tokens before storing them in the session cookie. -For example, here is how you configure it to split the tokens and encrypt them: - -[source, properties] ----- -quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus -quarkus.oidc.client-id=quarkus-app -quarkus.oidc.credentials.secret=secret -quarkus.oidc.application-type=web-app -quarkus.oidc.token-state-manager.split-tokens=true -quarkus.oidc.token-state-manager.encryption-secret=eUk1p7UB3nFiXZGUXi0uph1Y9p34YhBU ----- - -The token encryption secret must be at least 32 characters long. If this key is not configured then either `quarkus.oidc.credentials.secret` or `quarkus.oidc.credentials.jwt.secret` will be hashed to create an encryption key. - -`quarkus.oidc.token-state-manager.encryption-secret` should be configured if Quarkus authenticates to OpenId Connect Provider using either mTLS or `private_key_jwt` (where a private RSA or EC key is used to sign a JWT token) authentication methods, otherwise a random key will be generated which will be problematic if the Quarkus application is running in the cloud with multiple pods managing the requests. - -If you need you can disable encrypting the tokens in the session cookie with `quarkus.oidc.token-state-manager.encryption-required=false`. - -Register your own `io.quarkus.oidc.TokenStateManager' implementation as an `@ApplicationScoped` CDI bean if you need to customize the way the tokens are associated with the session cookie. For example, you may want to keep the tokens in a database and have only a database pointer stored in a session cookie. Note though that it may present some challenges in making the tokens available across multiple microservices nodes. - -Here is a simple example: - -[source, java] ----- -package io.quarkus.oidc.test; - -import jakarta.annotation.Priority; -import jakarta.enterprise.context.ApplicationScoped; -import jakarta.enterprise.inject.Alternative; -import jakarta.inject.Inject; - -import io.quarkus.oidc.AuthorizationCodeTokens; -import io.quarkus.oidc.OidcTenantConfig; -import io.quarkus.oidc.TokenStateManager; -import io.quarkus.oidc.runtime.DefaultTokenStateManager; -import io.smallrye.mutiny.Uni; -import io.vertx.ext.web.RoutingContext; -@ApplicationScoped -@Alternative -@Priority(1) -public class CustomTokenStateManager implements TokenStateManager { - - @Inject - DefaultTokenStateManager tokenStateManager; - - @Override - public Uni createTokenState(RoutingContext routingContext, OidcTenantConfig oidcConfig, - AuthorizationCodeTokens sessionContent, TokenStateManager.CreateTokenStateRequestContext requestContext) { - return tokenStateManager.createTokenState(routingContext, oidcConfig, sessionContent, requestContext) - .map(t -> (t + "|custom")); - } - - @Override - public Uni getTokens(RoutingContext routingContext, OidcTenantConfig oidcConfig, - String tokenState, TokenStateManager.GetTokensRequestContext requestContext) { - if (!tokenState.endsWith("|custom")) { - throw new IllegalStateException(); - } - String defaultState = tokenState.substring(0, tokenState.length() - 7); - return tokenStateManager.getTokens(routingContext, oidcConfig, defaultState, requestContext); - } - - @Override - public Uni deleteTokens(RoutingContext routingContext, OidcTenantConfig oidcConfig, String tokenState, - TokenStateManager.DeleteTokensRequestContext requestContext) { - if (!tokenState.endsWith("|custom")) { - throw new IllegalStateException(); - } - String defaultState = tokenState.substring(0, tokenState.length() - 7); - return tokenStateManager.deleteTokens(routingContext, oidcConfig, defaultState, requestContext); - } -} ----- - -=== Proof key for code exchange (PKCE) +=== Further security with Proof key for code exchange (PKCE) link:https://datatracker.ietf.org/doc/html/rfc7636[Proof Key for Code Exchange] (PKCE) minimizes the risk of the authorization code interception. @@ -524,7 +553,12 @@ public class SecurityEventListener { } ---- -=== Single-page applications +=== Integration considerations + +Your OIDC backed application integrates in an environment such as calling from a single page application, using well known OIDC providers etc. +This section discusses these considerations. + +==== Single-page applications Check if implementing SPAs the way it is suggested in the xref:security-oidc-bearer-token-authentication-concept.adoc#single-page-applications[Single-page Applications for Service Applications] section can meet your requirements. @@ -547,12 +581,12 @@ Future callQuarkusService() async { } ---- -=== Cross-origin resource sharing +==== Cross-origin resource sharing If you plan to consume this application from a Single-page application running on a different domain, you will need to configure CORS (Cross-Origin Resource Sharing). For more information, see the xref:http-reference.adoc#cors-filter[HTTP CORS documentation]. [[oauth2]] -=== Integration with GitHub and other OAuth2 providers +==== Integration with GitHub and other OAuth2 providers Some well known providers such as GitHub or LinkedIn are not OpenID Connect but OAuth2 providers which support the `authorization code flow`, for example, link:https://docs.github.com/en/developers/apps/building-oauth-apps/authorizing-oauth-apps[GitHub OAuth2] and link:https://docs.microsoft.com/en-us/linkedin/shared/authentication/authorization-code-flow[LinkedIn OAuth2]. @@ -711,9 +745,9 @@ Possibly a simpler alternative is to inject both `@IdToken JsonWebToken` and `Us The last important point is to make sure the callback path you enter in the GitHub OAuth application configuration matches the endpoint path where you'd like the user be redirected to after a successful GitHub authentication and application authorization, in this case it has to be set to `http:localhost:8080/github/userinfo`. -=== Cloud services +==== Calling Cloud provider services -==== Google Cloud +===== Google Cloud You can have Quarkus OIDC `web-app` applications access **Google Cloud services** such as **BigQuery** on behalf of the currently authenticated users who have enabled OpenID Connect (Authorization Code Flow) permissions to such services in their Google Developer Consoles. From 94baf6a5e60647c22458c8a92c5c6d26dfa85ab4 Mon Sep 17 00:00:00 2001 From: Emmanuel Bernard Date: Fri, 2 Jun 2023 12:34:45 +0200 Subject: [PATCH 3/6] OIDC doc - Improve OAuth2 section Based on exchanges with Sergey. --- ...oidc-code-flow-authentication-concept.adoc | 35 +++++++++++++------ 1 file changed, 24 insertions(+), 11 deletions(-) diff --git a/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc b/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc index 53cdfc5205a6c..0382a7d96a96c 100644 --- a/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc +++ b/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc @@ -589,31 +589,44 @@ If you plan to consume this application from a Single-page application running o ==== Integration with GitHub and other OAuth2 providers Some well known providers such as GitHub or LinkedIn are not OpenID Connect but OAuth2 providers which support the `authorization code flow`, for example, link:https://docs.github.com/en/developers/apps/building-oauth-apps/authorizing-oauth-apps[GitHub OAuth2] and link:https://docs.microsoft.com/en-us/linkedin/shared/authentication/authorization-code-flow[LinkedIn OAuth2]. +Remember, OIDC is built on top of OAuth2. -The main difference between OpenID Connect and OAuth2 providers is that OpenID Connect providers, by building on top of OAuth2, return an `ID Token` representing a user authentication, in addition to the standard authorization code flow `access` and `refresh` tokens returned by `OAuth2` providers. +The main difference between OpenID Connect and OAuth2 providers is that OpenID Connect providers return an `ID Token` representing a user authentication, in addition to the standard authorization code flow `access` and `refresh` tokens returned by `OAuth2` providers. OAuth2 providers such as GitHub do not return `IdToken`, the fact of the user authentication is implicit and is indirectly represented by the `access` token which represents an authenticated user authorizing the current Quarkus `web-app` application to access some data on behalf of the authenticated user. -For example, when working with GitHub, the Quarkus endpoint can acquire an `access` token which will allow it to request a GitHub profile of the current user. -In fact this is exactly how a standard OpenID Connect `UserInfo` acquisition also works - by authenticating into your OpenID Connect provider you also give a permission to Quarkus application to acquire your <> on your behalf - and it also shows what is meant by OpenID Connect being built on top of OAuth2. +While in the OIDC case, we validate the ID Token as proof of the authentication validity, in the raw OAuth2 case, we need to validate the access token. +This is done by subsequently calling an endpoint that requires the access token and that typically returns user information. +This very much the same as the OIDC <> approach which is fetched by the OIDC flow on your behalf. -To support the integration with such OAuth2 servers, `quarkus-oidc` needs to be configured to allow the authorization code flow responses without `IdToken`: `quarkus.oidc.authentication.id-token-required=false`. +For example, when working with GitHub, the Quarkus endpoint can acquire an `access` token which will allow it to request a GitHub profile of the current user. -It is required because `quarkus-oidc` expects that not only `access` and `refresh` tokens but also `IdToken` will be returned once the authorization code flow completes. +To support the integration with such OAuth2 servers, `quarkus-oidc` needs to be configured a bit differently to allow the authorization code flow responses without `IdToken`: `quarkus.oidc.authentication.id-token-required=false`. -Note, even though you will configure the extension to support the authorization code flows without `IdToken`, an internal `IdToken` will be generated to support the way `quarkus-oidc` operates where an `IdToken` is used to support the authentication session and to avoid redirecting the user to the provider such as GitHub on every request. In this case the session lifespan is set to 5 minutes which can be extended further as described in the <> section. +[NOTE] +-- +Even though you will configure the extension to support the authorization code flows without `IdToken`, an internal `IdToken` will be generated to standardize the way `quarkus-oidc` operates: an `IdToken` is used to support the authentication session and to avoid redirecting the user to the provider such as GitHub on every request. In this case the session lifespan is set to 5 minutes which can be extended further as described in the <> section. -The next step is to ensure that the returned access token can be useful to the current Quarkus endpoint. -If the OAuth2 provider supports the introspection endpoint then you may be able to use this access token as a source of roles with `quarkus.oidc.roles.source=accesstoken`. If no introspection endpoint is available then at the very least it should be possible to request <> from this provider with `quarkus.oidc.authentication.user-info-required` - this is the case with GitHub. +This simplifies how you handle an application supporting multiple OIDC providers. +-- -Configuring the endpoint to request <> is the only way `quarkus-oidc` can be integrated with the providers such as GitHub. +The next step is to ensure that the returned access token can be useful and is valid to the current Quarkus endpoint. +The first way is to call the OAuth2 provider introspection endpoint by configuring `quarkus.oidc.introspection-path` if the provider offers such an endpoint. +In this case you can use the access token as a source of role using `quarkus.oidc.roles.source=accesstoken`. +If no introspection endpoint is present, your next best step is to request <> from the provider as it will at least validate the access token. Use `quarkus.oidc.authentication.user-info-required=true`. +You also need to set the `quarkus.oidc.user-info-path` property to a URL endpoint fetching the user info (or at least to an endpoint protected by the access token). +For GitHub, since it does not have an introspection endpoint, we use the last method. -Note that requiring <> involves making a remote call on every request - therefore you may want to consider caching `UserInfo` data, see xref:security-oidc-bearer-token-authentication-concept.adoc#token-introspection-userinfo-cache[Token Introspection and UserInfo cache] for more details. +[NOTE] +-- +Requiring <> involves making a remote call on every request - therefore you may want to consider caching `UserInfo` data, see xref:security-oidc-bearer-token-authentication-concept.adoc#token-introspection-userinfo-cache[Token Introspection and UserInfo cache] for more details. Alternatively, you may want to request that `UserInfo` is embedded into the internal generated `IdToken` with the `quarkus.oidc.cache-user-info-in-idtoken=true` property - the advantage of this approach is that by default no cached `UserInfo` state will be kept with the endpoint - instead it will be stored in a session cookie. You may also want to consider encrypting `IdToken` in this case if `UserInfo` contains sensitive data. For more information, see <>. +-- -Also, OAuth2 servers may not support a well-known configuration endpoint in which case the discovery has to be disabled and the authorization, token, and introspection and/or userinfo endpoint paths have to be configured manually. +OAuth2 servers may not support a well-known configuration endpoint in which case the discovery has to be disabled and the authorization, token, and introspection and/or userinfo endpoint paths have to be configured manually. +This can look a bit daunting but Quarkus simplifies your life for well known OIDC or OAuth2 providers like Apple, Facebook, GitHub, Google, Microsoft, Spotify and Twitter. Use the `quarkus.oidc.provider` property. Here is how you can integrate `quarkus-oidc` with GitHub after you have link:https://docs.github.com/en/developers/apps/building-oauth-apps/creating-an-oauth-app[created a GitHub OAuth application]. Configure your Quarkus endpoint like this: [source,properties] From 02d538d8bfffb863556e35cd7dbdad5ffbcd8bae Mon Sep 17 00:00:00 2001 From: Emmanuel Bernard Date: Fri, 2 Jun 2023 12:47:30 +0200 Subject: [PATCH 4/6] OIDC doc - Subsequent reorganization for easier read and context Create dedicated configuration uber section regrouping alike subjects (non code) Move OAuth2 into Using the flow Move PKCD into token validation section Reorganize integration section and make it a top level Move Tests to top level and fold error section --- ...oidc-code-flow-authentication-concept.adoc | 802 +++++++++--------- 1 file changed, 406 insertions(+), 396 deletions(-) diff --git a/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc b/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc index 0382a7d96a96c..1dcfda4ab9bbd 100644 --- a/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc +++ b/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc @@ -46,6 +46,271 @@ For information about how to support multiple tenants, see xref:security-openid- == Using the authorization code flow mechanism +=== Configuring access to the OIDC Provider endpoint + +OIDC `web-app` application needs to know the endpoint URLs of OpenID Connect provider's authorization, token, `JsonWebKey` (JWK) set and possibly `UserInfo`, introspection and end session (RP-initiated logout). + +By convention, they are discovered by adding a `/.well-known/openid-configuration` path to the configured `quarkus.oidc.auth-server-url`. + +Alternatively, if the discovery endpoint is not available, or if you would like to save on the discovery endpoint round-trip, you can disable the discovery and configure them with relative path values, for example: + +[source, properties] +---- +quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus +quarkus.oidc.discovery-enabled=false +# Authorization endpoint: http://localhost:8180/realms/quarkus/protocol/openid-connect/auth +quarkus.oidc.authorization-path=/protocol/openid-connect/auth +# Token endpoint: http://localhost:8180/realms/quarkus/protocol/openid-connect/token +quarkus.oidc.token-path=/protocol/openid-connect/token +# JWK set endpoint: http://localhost:8180/realms/quarkus/protocol/openid-connect/certs +quarkus.oidc.jwks-path=/protocol/openid-connect/certs +# UserInfo endpoint: http://localhost:8180/realms/quarkus/protocol/openid-connect/userinfo +quarkus.oidc.user-info-path=/protocol/openid-connect/userinfo +# Token Introspection endpoint: http://localhost:8180/realms/quarkus/protocol/openid-connect/token/introspect +quarkus.oidc.introspection-path=/protocol/openid-connect/token/introspect +# End session endpoint: http://localhost:8180/realms/quarkus/protocol/openid-connect/logout +quarkus.oidc.end-session-path=/protocol/openid-connect/logout +---- + +Sometimes, your OpenId Connect provider supports a metadata discovery but does not return all the endpoint URLs required for the authorization code flow to complete or for the application to support the additional functions such as a user logout. In such cases, you can simply configure missing endpoints URL locally: + +[source, properties] +---- +# Metadata is auto-discovered but it does not return an end-session endpoint URL + +quarkus.oidc.auth-server-url=http://localhost:8180/oidcprovider/account + +# Configure the end-session URL locally, it can be an absolute or relative (to 'quarkus.oidc.auth-server-url') address +quarkus.oidc.end-session-path=logout +---- + +Exactly the same configuration can be used to override a discovered endpoint URL if that URL does not work for the local Quarkus endpoint and a more specific value is required. For example, one can imagine that in the above example, a provider which supports both global and application specific end-session endpoints returns a global end-session URL such as `http://localhost:8180/oidcprovider/account/global-logout` which will logout the user from all the applications this user is currently logged in, while the current application only wants to get this user logged out from this application, therefore, `quarkus.oidc.end-session-path=logout` is used to override the global end-session URL. + +[[oidc-provider-client-authentication]] +==== OIDC provider client authentication + +OIDC providers typically require using applications to be identified and authenticated when they interact with the OIDC endpoints. +Quarkus OIDC (specifically `quarkus.oidc.runtime.OidcProviderClient`) authenticates to the OpenID Connect Provider when the authorization code has to be exchanged for the ID, access and refresh tokens, when the ID and access tokens have to be refreshed or introspected. + +Typically, client id and client secrets are defined for a given application when it enlist to the OIDC provider. +All the https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication[OIDC Client Authentication] options are supported, for example: + +`client_secret_basic`: + +[source,properties] +---- +quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/ +quarkus.oidc.client-id=quarkus-app +quarkus.oidc.credentials.secret=mysecret +---- + +or + +[source,properties] +---- +quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/ +quarkus.oidc.client-id=quarkus-app +quarkus.oidc.credentials.client-secret.value=mysecret +---- + +or with the secret retrieved from a xref:credentials-provider.adoc[CredentialsProvider]: + +[source,properties] +---- +quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/ +quarkus.oidc.client-id=quarkus-app + +# This is a key which will be used to retrieve a secret from the map of credentials returned from CredentialsProvider +quarkus.oidc.credentials.client-secret.provider.key=mysecret-key +# Set it only if more than one CredentialsProvider can be registered +quarkus.oidc.credentials.client-secret.provider.name=oidc-credentials-provider +---- + +`client_secret_post`: + +[source,properties] +---- +quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/ +quarkus.oidc.client-id=quarkus-app +quarkus.oidc.credentials.client-secret.value=mysecret +quarkus.oidc.credentials.client-secret.method=post +---- + +`client_secret_jwt`, signature algorithm is HS256: + +[source,properties] +---- +quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/ +quarkus.oidc.client-id=quarkus-app +quarkus.oidc.credentials.jwt.secret=AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow +---- + +or with the secret retrieved from a xref:credentials-provider.adoc[CredentialsProvider]: + +[source,properties] +---- +quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/ +quarkus.oidc.client-id=quarkus-app + +# This is a key which will be used to retrieve a secret from the map of credentials returned from CredentialsProvider +quarkus.oidc.credentials.jwt.secret-provider.key=mysecret-key +# Set it only if more than one CredentialsProvider can be registered +quarkus.oidc.credentials.jwt.secret-provider.name=oidc-credentials-provider +---- + +`private_key_jwt` with the PEM key file, signature algorithm is RS256: + +[source,properties] +---- +quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/ +quarkus.oidc.client-id=quarkus-app +quarkus.oidc.credentials.jwt.key-file=privateKey.pem +---- + +`private_key_jwt` with the key store file, signature algorithm is RS256: + +[source,properties] +---- +quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/ +quarkus.oidc.client-id=quarkus-app +quarkus.oidc.credentials.jwt.key-store-file=keystore.jks +quarkus.oidc.credentials.jwt.key-store-password=mypassword +quarkus.oidc.credentials.jwt.key-password=mykeypassword + +# Private key alias inside the keystore +quarkus.oidc.credentials.jwt.key-id=mykeyAlias +---- + +Using `client_secret_jwt` or `private_key_jwt` authentication methods ensures that no client secret goes over the wire. + +===== Additional JWT authentication options + +If `client_secret_jwt`, `private_key_jwt` authentication methods are used or an Apple `post_jwt` method is used, then the JWT signature algorithm, key identifier, audience, subject and issuer can be customized, for example: + +[source,properties] +---- +# private_key_jwt client authentication + +quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/ +quarkus.oidc.client-id=quarkus-app +quarkus.oidc.credentials.jwt.key-file=privateKey.pem + +# This is a token key identifier 'kid' header - set it if your OpenID Connect provider requires it. +# Note if the key is represented in a JSON Web Key (JWK) format with a `kid` property then +# using 'quarkus.oidc.credentials.jwt.token-key-id' is not necessary. +quarkus.oidc.credentials.jwt.token-key-id=mykey + +# Use RS512 signature algorithm instead of the default RS256 +quarkus.oidc.credentials.jwt.signature-algorithm=RS512 + +# The token endpoint URL is the default audience value, use the base address URL instead: +quarkus.oidc.credentials.jwt.audience=${quarkus.oidc-client.auth-server-url} + +# custom subject instead of the client id : +quarkus.oidc.credentials.jwt.subject=custom-subject + +# custom issuer instead of the client id : +quarkus.oidc.credentials.jwt.issuer=custom-issuer +---- + +===== Apple POST JWT + +Apple OpenID Connect Provider uses a `client_secret_post` method where a secret is a JWT produced with a `private_key_jwt` authentication method but with Apple account specific issuer and subject claims. + +`quarkus-oidc` supports a non-standard `client_secret_post_jwt` authentication method which can be configured as follows: + +[source,properties] +---- +# Apple provider configuration sets a 'client_secret_post_jwt' authentication method +quarkus.oidc.provider=apple + +quarkus.oidc.client-id=${apple.client-id} +quarkus.oidc.credentials.jwt.key-file=ecPrivateKey.pem +quarkus.oidc.credentials.jwt.token-key-id=${apple.key-id} +# Apple provider configuration sets ES256 signature algorithm + +quarkus.oidc.credentials.jwt.subject=${apple.subject} +quarkus.oidc.credentials.jwt.issuer=${apple.issuer} +---- + +===== Mutual TLS (mTLS) + +Some OpenID Connect providers may require that a client is authenticated as part of the `Mutual TLS` authentication process. + +`quarkus-oidc` can be configured as follows to support `mTLS`: + +[source,properties] +---- +quarkus.oidc.tls.verification=certificate-validation + +# Keystore configuration +quarkus.oidc.tls.key-store-file=client-keystore.jks +quarkus.oidc.tls.key-store-password=${key-store-password} + +# Add more keystore properties if needed: +#quarkus.oidc.tls.key-store-alias=keyAlias +#quarkus.oidc.tls.key-store-alias-password=keyAliasPassword + +# Truststore configuration +quarkus.oidc.tls.trust-store-file=client-truststore.jks +quarkus.oidc.tls.trust-store-password=${trust-store-password} +# Add more truststore properties if needed: +#quarkus.oidc.tls.trust-store-alias=certAlias +---- + +==== Introspection endpoint authentication + +Some OpenID Connect Providers may require authenticating to its introspection endpoint using Basic authentication with the credentials different to `client_id` and `client_secret` which may have already been configured to support `client_secret_basic` or `client_secret_post` client authentication methods described in the <> section. + +If the tokens have to be introspected and the introspection endpoint specific authentication mechanism is required, then you can configure `quarkus-oidc` like this: + +[source,properties] +---- +quarkus.oidc.introspection-credentials.name=introspection-user-name +quarkus.oidc.introspection-credentials.secret=introspection-user-secret +---- + +==== Redirecting to and from the OIDC provider + +When the user is redirected to the OpenID Connect Provider to authenticate, the redirect URL includes a `redirect_uri` query parameter which indicates to the provider where the user has to be redirected to once the authentication has been completed. +In our case, this is the Quarkus application. + +Quarkus will set this parameter to the current application request URL by default. For example, if the user is trying to access a Quarkus service endpoint at `http://localhost:8080/service/1` then the `redirect_uri` parameter will be set to `http://localhost:8080/service/1`. Similarly, if the request URL is `http://localhost:8080/service/2` then the `redirect_uri` parameter will be set to `http://localhost:8080/service/2`, etc. + +Some OpenID Connect Providers require the `redirect_uri` to have the same value for a given application (e.g. `http://localhost:8080/service/callback`) for all the redirect URLs. +In such cases, a `quarkus.oidc.authentication.redirect-path` property has to be set, for example, `quarkus.oidc.authentication.redirect-path=/service/callback`, and Quarkus will set the `redirect_uri` parameter to an absolute URL such as `http://localhost:8080/service/callback` which will be the same regardless of the current request URL. + +If `quarkus.oidc.authentication.redirect-path` is set but +If you need the original request URL to be restored after the user has been redirected back to a unique callback URL such as `http://localhost:8080/service/callback`, set `quarkus.oidc.authentication.restore-path-after-redirect` property to `true`. +This will restore the request URL such as `http://localhost:8080/service/1`. + +==== Customizing authentication requests + +By default, only the `response_type` (set to `code`), `scope` (set to 'openid'), `client_id`, `redirect_uri` and `state` properties are passed as HTTP query parameters to the OpenID Connect provider's authorization endpoint when the user is redirected to it to authenticate. + +You can add more properties to it with `quarkus.oidc.authentication.extra-params`. For example, some OpenID Connect providers may choose to return the authorization code as part of the redirect URI's fragment which would break the authentication process - it can be fixed as follows: + +[source,properties] +---- +quarkus.oidc.authentication.extra-params.response_mode=query +---- + +==== Customizing the authentication error response + +If the user authentication has failed at the OpenID Connect Authorization endpoint, for example, due to an invalid scope or other invalid parameters included in the redirect to the provider, then the provider will redirect the user back to Quarkus not with the `code` but `error` and `error_description` parameters. + +In such cases HTTP `401` will be returned by default. However, you can instead request that a custom public error endpoint is called in order to return a user-friendly HTML error page. Use `quarkus.oidc.authentication.error-path`, for example: + +[source,properties] +---- +quarkus.oidc.authentication.error-path=/error +---- + +It has to start from a forward slash and be relative to the base URI of the current endpoint. +For example, if it is set as '/error' and the current request URI is `https://localhost:8080/callback?error=invalid_scope` then a final redirect will be made to `https://localhost:8080/error?error=invalid_scope`. + +It is important that this error endpoint is a public resource to avoid the user redirected to this page be authenticated again. + === Accessing authorization data Let's first discuss how to access information around authorization. @@ -183,19 +448,24 @@ Please see xref:security-oidc-bearer-token-authentication-concept.adoc#token-int Please see xref:security-oidc-bearer-token-authentication-concept.adoc#jwt-claim-verification[JSON Web Token Claim verification] section about the claim verification, including the `iss` (issuer) claim. It applies to ID tokens but also to access tokens in a JWT format if the `web-app` application has requested the access token verification. -=== Redirecting to and from the OIDC provider +==== Further security with Proof key for code exchange (PKCE) -When the user is redirected to the OpenID Connect Provider to authenticate, the redirect URL includes a `redirect_uri` query parameter which indicates to the provider where the user has to be redirected to once the authentication has been completed. -In our case, this is the Quarkus application. +link:https://datatracker.ietf.org/doc/html/rfc7636[Proof Key for Code Exchange] (PKCE) minimizes the risk of the authorization code interception. -Quarkus will set this parameter to the current application request URL by default. For example, if the user is trying to access a Quarkus service endpoint at `http://localhost:8080/service/1` then the `redirect_uri` parameter will be set to `http://localhost:8080/service/1`. Similarly, if the request URL is `http://localhost:8080/service/2` then the `redirect_uri` parameter will be set to `http://localhost:8080/service/2`, etc. +While `PKCE` is of primary importance to the public OpenID Connect clients (such as the SPA scripts running in a browser), it can also provide an extra level of protection to Quarkus OIDC `web-app` applications which are confidential OpenID Connect clients capable of securely storing the client secret and using it to exchange the code for the tokens. -Some OpenID Connect Providers require the `redirect_uri` to have the same value for a given application (e.g. `http://localhost:8080/service/callback`) for all the redirect URLs. -In such cases, a `quarkus.oidc.authentication.redirect-path` property has to be set, for example, `quarkus.oidc.authentication.redirect-path=/service/callback`, and Quarkus will set the `redirect_uri` parameter to an absolute URL such as `http://localhost:8080/service/callback` which will be the same regardless of the current request URL. +You can enable `PKCE` for your OIDC `web-app` endpoint with a `quarkus.oidc.authentication.pkce-required` property and a 32 characters long secret, for example: + +[source, properties] +---- +quarkus.oidc.authentication.pkce-required=true +quarkus.oidc.authentication.pkce-secret=eUk1p7UB3nFiXZGUXi0uph1Y9p34YhBU +---- + +If you already have a 32 characters long client secret then `quarkus.oidc.authentication.pkce-secret` does not have to be set unless you prefer to use a different secret key. + +The secret key is required for encrypting a randomly generated `PKCE` `code_verifier` while the user is being redirected with the `code_challenge` query parameter to OpenID Connect Provider to authenticate. The `code_verifier` will be decrypted when the user is redirected back to Quarkus and sent to the token endpoint alongside the `code`, client secret and other parameters to complete the code exchange. The provider will fail the code exchange if a `SHA256` digest of the `code_verifier` does not match the `code_challenge` provided during the authentication request. -If `quarkus.oidc.authentication.redirect-path` is set but -If you need the original request URL to be restored after the user has been redirected back to a unique callback URL such as `http://localhost:8080/service/callback`, set `quarkus.oidc.authentication.restore-path-after-redirect` property to `true`. -This will restore the request URL such as `http://localhost:8080/service/1`. === Handling and controlling the life time of authentication @@ -509,84 +779,8 @@ You can have this process further optimized by having a simple JavaScript functi Note this user session can not be extended forever - the returning user with the expired ID token will have to re-authenticate at the OIDC provider endpoint once the refresh token has expired. - -=== Further security with Proof key for code exchange (PKCE) - -link:https://datatracker.ietf.org/doc/html/rfc7636[Proof Key for Code Exchange] (PKCE) minimizes the risk of the authorization code interception. - -While `PKCE` is of primary importance to the public OpenID Connect clients (such as the SPA scripts running in a browser), it can also provide an extra level of protection to Quarkus OIDC `web-app` applications which are confidential OpenID Connect clients capable of securely storing the client secret and using it to exchange the code for the tokens. - -You can enable `PKCE` for your OIDC `web-app` endpoint with a `quarkus.oidc.authentication.pkce-required` property and a 32 characters long secret, for example: - -[source, properties] ----- -quarkus.oidc.authentication.pkce-required=true -quarkus.oidc.authentication.pkce-secret=eUk1p7UB3nFiXZGUXi0uph1Y9p34YhBU ----- - -If you already have a 32 characters long client secret then `quarkus.oidc.authentication.pkce-secret` does not have to be set unless you prefer to use a different secret key. - -The secret key is required for encrypting a randomly generated `PKCE` `code_verifier` while the user is being redirected with the `code_challenge` query parameter to OpenID Connect Provider to authenticate. The `code_verifier` will be decrypted when the user is redirected back to Quarkus and sent to the token endpoint alongside the `code`, client secret and other parameters to complete the code exchange. The provider will fail the code exchange if a `SHA256` digest of the `code_verifier` does not match the `code_challenge` provided during the authentication request. - -=== Listening to important authentication events - -One can register `@ApplicationScoped` bean which will observe important OIDC authentication events. The listener will be updated when a user has logged in for the first time or re-authenticated, as well as when the session has been refreshed. More events may be reported in the future. For example: - -[source, java] ----- -import jakarta.enterprise.context.ApplicationScoped; -import jakarta.enterprise.event.Observes; - -import io.quarkus.oidc.IdTokenCredential; -import io.quarkus.oidc.SecurityEvent; -import io.quarkus.security.identity.AuthenticationRequestContext; -import io.vertx.ext.web.RoutingContext; - -@ApplicationScoped -public class SecurityEventListener { - - public void event(@Observes SecurityEvent event) { - String tenantId = event.getSecurityIdentity().getAttribute("tenant-id"); - RoutingContext vertxContext = event.getSecurityIdentity().getAttribute(RoutingContext.class.getName()); - vertxContext.put("listener-message", String.format("event:%s,tenantId:%s", event.getEventType().name(), tenantId)); - } -} ----- - -=== Integration considerations - -Your OIDC backed application integrates in an environment such as calling from a single page application, using well known OIDC providers etc. -This section discusses these considerations. - -==== Single-page applications - -Check if implementing SPAs the way it is suggested in the xref:security-oidc-bearer-token-authentication-concept.adoc#single-page-applications[Single-page Applications for Service Applications] section can meet your requirements. - -If you prefer to use SPA and JavaScript API such as `Fetch` or `XMLHttpRequest`(XHR) with Quarkus web applications, be aware that OpenID Connect Providers may not support CORS for Authorization endpoints where the users are authenticated after a redirect from Quarkus. This will lead to authentication failures if the Quarkus application and the OpenID Connect Provider are hosted on the different HTTP domains/ports. - -In such cases, set the `quarkus.oidc.authentication.java-script-auto-redirect` property to `false` which will instruct Quarkus to return a `499` status code and `WWW-Authenticate` header with the `OIDC` value. The browser script also needs to be updated to set `X-Requested-With` header with the `JavaScript` value and reload the last requested page in case of `499`, for example: - -[source,javascript] ----- -Future callQuarkusService() async { - Map headers = Map.fromEntries([MapEntry("X-Requested-With", "JavaScript")]); - - await http - .get("https://localhost:443/serviceCall") - .then((response) { - if (response.statusCode == 499) { - window.location.assign("https://localhost.com:443/serviceCall"); - } - }); - } ----- - -==== Cross-origin resource sharing - -If you plan to consume this application from a Single-page application running on a different domain, you will need to configure CORS (Cross-Origin Resource Sharing). For more information, see the xref:http-reference.adoc#cors-filter[HTTP CORS documentation]. - [[oauth2]] -==== Integration with GitHub and other OAuth2 providers +=== Integration with GitHub and non-OIDC OAuth2 providers Some well known providers such as GitHub or LinkedIn are not OpenID Connect but OAuth2 providers which support the `authorization code flow`, for example, link:https://docs.github.com/en/developers/apps/building-oauth-apps/authorizing-oauth-apps[GitHub OAuth2] and link:https://docs.microsoft.com/en-us/linkedin/shared/authentication/authorization-code-flow[LinkedIn OAuth2]. Remember, OIDC is built on top of OAuth2. @@ -719,307 +913,176 @@ public class CustomSecurityIdentityAugmentor implements SecurityIdentityAugmento } ---- -Now, the following code will work when the user is signing in into your application with both Google or GitHub: - -[source,java] ----- -import jakarta.inject.Inject; -import jakarta.ws.rs.GET; -import jakarta.ws.rs.Path; -import jakarta.ws.rs.Produces; - -import io.quarkus.security.Authenticated; -import io.quarkus.security.identity.SecurityIdentity; - -@Path("/service") -@Authenticated -public class TokenResource { - - @Inject - SecurityIdentity identity; - - @GET - @Path("/google") - @Produces("application/json") - public String getUserName() { - return identity.getPrincipal().getName(); - } - - @GET - @Path("/github") - @Produces("application/json") - public String getUserName() { - return identity.getPrincipal().getUserName(); - } -} ----- - -Possibly a simpler alternative is to inject both `@IdToken JsonWebToken` and `UserInfo` and use `JsonWebToken` when dealing with the providers returning `IdToken` and `UserInfo` - with the providers which do not return `IdToken`. - -The last important point is to make sure the callback path you enter in the GitHub OAuth application configuration matches the endpoint path where you'd like the user be redirected to after a successful GitHub authentication and application authorization, in this case it has to be set to `http:localhost:8080/github/userinfo`. - -==== Calling Cloud provider services - -===== Google Cloud - -You can have Quarkus OIDC `web-app` applications access **Google Cloud services** such as **BigQuery** on behalf of the currently authenticated users who have enabled OpenID Connect (Authorization Code Flow) permissions to such services in their Google Developer Consoles. - -It is super easy to do with https://github.com/quarkiverse[Quarkiverse] https://github.com/quarkiverse/quarkiverse-google-cloud-services[Google Cloud Services], only add -the https://github.com/quarkiverse/quarkiverse-google-cloud-services/releases/latest[latest tag] service dependency, for example: - -[source,xml,role="primary asciidoc-tabs-target-sync-cli asciidoc-tabs-target-sync-maven"] -.pom.xml ----- - - io.quarkiverse.googlecloudservices - quarkus-google-cloud-bigquery - ${quarkiverse.googlecloudservices.version} - ----- - -[source,gradle,role="secondary asciidoc-tabs-target-sync-gradle"] -.build.gradle ----- -implementation("io.quarkiverse.googlecloudservices:quarkus-google-cloud-bigquery:${quarkiverse.googlecloudservices.version}") ----- - -and configure Google OIDC properties: - -[source, properties] ----- -quarkus.oidc.provider=google -quarkus.oidc.client-id={GOOGLE_CLIENT_ID} -quarkus.oidc.credentials.secret={GOOGLE_CLIENT_SECRET} -quarkus.oidc.token.issuer=https://accounts.google.com ----- - -=== Provider endpoint configuration - -OIDC `web-app` application needs to know OpenID Connect provider's authorization, token, `JsonWebKey` (JWK) set and possibly `UserInfo`, introspection and end session (RP-initiated logout) endpoint addresses. - -By default, they are discovered by adding a `/.well-known/openid-configuration` path to the configured `quarkus.oidc.auth-server-url`. - -Alternatively, if the discovery endpoint is not available, or if you would like to save on the discovery endpoint round-trip, you can disable the discovery and configure them with relative path values, for example: - -[source, properties] ----- -quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus -quarkus.oidc.discovery-enabled=false -# Authorization endpoint: http://localhost:8180/realms/quarkus/protocol/openid-connect/auth -quarkus.oidc.authorization-path=/protocol/openid-connect/auth -# Token endpoint: http://localhost:8180/realms/quarkus/protocol/openid-connect/token -quarkus.oidc.token-path=/protocol/openid-connect/token -# JWK set endpoint: http://localhost:8180/realms/quarkus/protocol/openid-connect/certs -quarkus.oidc.jwks-path=/protocol/openid-connect/certs -# UserInfo endpoint: http://localhost:8180/realms/quarkus/protocol/openid-connect/userinfo -quarkus.oidc.user-info-path=/protocol/openid-connect/userinfo -# Token Introspection endpoint: http://localhost:8180/realms/quarkus/protocol/openid-connect/token/introspect -quarkus.oidc.introspection-path=/protocol/openid-connect/token/introspect -# End session endpoint: http://localhost:8180/realms/quarkus/protocol/openid-connect/logout -quarkus.oidc.end-session-path=/protocol/openid-connect/logout ----- - -Sometimes, your OpenId Connect provider supports a metadata discovery but does not return all the endpoint URLs required for the authorization code flow to complete or for the application to support the additional functions such as a user logout. In such cases, you can simply configure a missing endpoint URL locally: - -[source, properties] ----- -# Metadata is auto-discovered but it does not return an end-session endpoint URL - -quarkus.oidc.auth-server-url=http://localhost:8180/oidcprovider/account - -# Configure the end-session URL locally, it can be an absolute or relative (to 'quarkus.oidc.auth-server-url') address -quarkus.oidc.end-session-path=logout ----- - -Exactly the same configuration can be used to override a discovered endpoint URL if that URL does not work for the local Quarkus endpoint and a more specific value is required. For example, one can imagine that in the above example, a provider which supports both global and application specific end-session endpoints returns a global end-session URL such as `http://localhost:8180/oidcprovider/account/global-logout` which will logout the user from all the applications this user is currently logged in, while the current application only wants to get this user logged out from this application, therefore, `quarkus.oidc.end-session-path=logout` is used to override the global end-session URL. - -=== Token propagation -For information about Authorization Code Flow access token propagation to the downstream services, see the xref:security-openid-connect-client-reference.adoc#token-propagation[Token Propagation] section. - -[[oidc-provider-client-authentication]] -=== OIDC provider client authentication - -`quarkus.oidc.runtime.OidcProviderClient` is used when a remote request to an OpenID Connect Provider has to be done. It has to authenticate to the OpenID Connect Provider when the authorization code has to be exchanged for the ID, access and refresh tokens, when the ID and access tokens have to be refreshed or introspected. - -All the https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication[OIDC Client Authentication] options are supported, for example: - -`client_secret_basic`: - -[source,properties] ----- -quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/ -quarkus.oidc.client-id=quarkus-app -quarkus.oidc.credentials.secret=mysecret ----- - -or - -[source,properties] ----- -quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/ -quarkus.oidc.client-id=quarkus-app -quarkus.oidc.credentials.client-secret.value=mysecret ----- - -or with the secret retrieved from a xref:credentials-provider.adoc[CredentialsProvider]: - -[source,properties] ----- -quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/ -quarkus.oidc.client-id=quarkus-app - -# This is a key which will be used to retrieve a secret from the map of credentials returned from CredentialsProvider -quarkus.oidc.credentials.client-secret.provider.key=mysecret-key -# Set it only if more than one CredentialsProvider can be registered -quarkus.oidc.credentials.client-secret.provider.name=oidc-credentials-provider ----- - -`client_secret_post`: +Now, the following code will work when the user is signing in into your application with both Google or GitHub: -[source,properties] ----- -quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/ -quarkus.oidc.client-id=quarkus-app -quarkus.oidc.credentials.client-secret.value=mysecret -quarkus.oidc.credentials.client-secret.method=post +[source,java] ---- +import jakarta.inject.Inject; +import jakarta.ws.rs.GET; +import jakarta.ws.rs.Path; +import jakarta.ws.rs.Produces; -`client_secret_jwt`, signature algorithm is HS256: +import io.quarkus.security.Authenticated; +import io.quarkus.security.identity.SecurityIdentity; -[source,properties] ----- -quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/ -quarkus.oidc.client-id=quarkus-app -quarkus.oidc.credentials.jwt.secret=AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow ----- +@Path("/service") +@Authenticated +public class TokenResource { -or with the secret retrieved from a xref:credentials-provider.adoc[CredentialsProvider]: + @Inject + SecurityIdentity identity; -[source,properties] ----- -quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/ -quarkus.oidc.client-id=quarkus-app + @GET + @Path("/google") + @Produces("application/json") + public String getUserName() { + return identity.getPrincipal().getName(); + } -# This is a key which will be used to retrieve a secret from the map of credentials returned from CredentialsProvider -quarkus.oidc.credentials.jwt.secret-provider.key=mysecret-key -# Set it only if more than one CredentialsProvider can be registered -quarkus.oidc.credentials.jwt.secret-provider.name=oidc-credentials-provider + @GET + @Path("/github") + @Produces("application/json") + public String getUserName() { + return identity.getPrincipal().getUserName(); + } +} ---- -`private_key_jwt` with the PEM key file, signature algorithm is RS256: +Possibly a simpler alternative is to inject both `@IdToken JsonWebToken` and `UserInfo` and use `JsonWebToken` when dealing with the providers returning `IdToken` and `UserInfo` - with the providers which do not return `IdToken`. -[source,properties] ----- -quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/ -quarkus.oidc.client-id=quarkus-app -quarkus.oidc.credentials.jwt.key-file=privateKey.pem ----- +The last important point is to make sure the callback path you enter in the GitHub OAuth application configuration matches the endpoint path where you'd like the user be redirected to after a successful GitHub authentication and application authorization, in this case it has to be set to `http:localhost:8080/github/userinfo`. -`private_key_jwt` with the key store file, signature algorithm is RS256: -[source,properties] ----- -quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/ -quarkus.oidc.client-id=quarkus-app -quarkus.oidc.credentials.jwt.key-store-file=keystore.jks -quarkus.oidc.credentials.jwt.key-store-password=mypassword -quarkus.oidc.credentials.jwt.key-password=mykeypassword +=== Listening to important authentication events -# Private key alias inside the keystore -quarkus.oidc.credentials.jwt.key-id=mykeyAlias ----- +One can register `@ApplicationScoped` bean which will observe important OIDC authentication events. The listener will be updated when a user has logged in for the first time or re-authenticated, as well as when the session has been refreshed. More events may be reported in the future. For example: -Using `client_secret_jwt` or `private_key_jwt` authentication methods ensures that no client secret goes over the wire. +[source, java] +---- +import jakarta.enterprise.context.ApplicationScoped; +import jakarta.enterprise.event.Observes; -==== Additional JWT authentication options +import io.quarkus.oidc.IdTokenCredential; +import io.quarkus.oidc.SecurityEvent; +import io.quarkus.security.identity.AuthenticationRequestContext; +import io.vertx.ext.web.RoutingContext; -If `client_secret_jwt`, `private_key_jwt` authentication methods are used or an Apple `post_jwt` method is used, then the JWT signature algorithm, key identifier, audience, subject and issuer can be customized, for example: +@ApplicationScoped +public class SecurityEventListener { -[source,properties] + public void event(@Observes SecurityEvent event) { + String tenantId = event.getSecurityIdentity().getAttribute("tenant-id"); + RoutingContext vertxContext = event.getSecurityIdentity().getAttribute(RoutingContext.class.getName()); + vertxContext.put("listener-message", String.format("event:%s,tenantId:%s", event.getEventType().name(), tenantId)); + } +} ---- -# private_key_jwt client authentication -quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/ -quarkus.oidc.client-id=quarkus-app -quarkus.oidc.credentials.jwt.key-file=privateKey.pem +=== Propagating tokens to downstream services -# This is a token key identifier 'kid' header - set it if your OpenID Connect provider requires it. -# Note if the key is represented in a JSON Web Key (JWK) format with a `kid` property then -# using 'quarkus.oidc.credentials.jwt.token-key-id' is not necessary. -quarkus.oidc.credentials.jwt.token-key-id=mykey +For information about Authorization Code Flow access token propagation to the downstream services, see the xref:security-openid-connect-client-reference.adoc#token-propagation[Token Propagation] section. -# Use RS512 signature algorithm instead of the default RS256 -quarkus.oidc.credentials.jwt.signature-algorithm=RS512 -# The token endpoint URL is the default audience value, use the base address URL instead: -quarkus.oidc.credentials.jwt.audience=${quarkus.oidc-client.auth-server-url} +== Integration considerations -# custom subject instead of the client id : -quarkus.oidc.credentials.jwt.subject=custom-subject +Your OIDC backed application integrates in an environment such as calling from a single page application, using well known OIDC providers etc. +This section discusses these considerations. -# custom issuer instead of the client id : -quarkus.oidc.credentials.jwt.issuer=custom-issuer ----- +=== Single-page applications -==== Apple POST JWT +Check if implementing SPAs the way it is suggested in the xref:security-oidc-bearer-token-authentication-concept.adoc#single-page-applications[Single-page Applications for Service Applications] section can meet your requirements. -Apple OpenID Connect Provider uses a `client_secret_post` method where a secret is a JWT produced with a `private_key_jwt` authentication method but with Apple account specific issuer and subject claims. +If you prefer to use SPA and JavaScript API such as `Fetch` or `XMLHttpRequest`(XHR) with Quarkus web applications, be aware that OpenID Connect Providers may not support CORS for Authorization endpoints where the users are authenticated after a redirect from Quarkus. This will lead to authentication failures if the Quarkus application and the OpenID Connect Provider are hosted on the different HTTP domains/ports. -`quarkus-oidc` supports a non-standard `client_secret_post_jwt` authentication method which can be configured as follows: +In such cases, set the `quarkus.oidc.authentication.java-script-auto-redirect` property to `false` which will instruct Quarkus to return a `499` status code and `WWW-Authenticate` header with the `OIDC` value. The browser script also needs to be updated to set `X-Requested-With` header with the `JavaScript` value and reload the last requested page in case of `499`, for example: -[source,properties] +[source,javascript] ---- -# Apple provider configuration sets a 'client_secret_post_jwt' authentication method -quarkus.oidc.provider=apple - -quarkus.oidc.client-id=${apple.client-id} -quarkus.oidc.credentials.jwt.key-file=ecPrivateKey.pem -quarkus.oidc.credentials.jwt.token-key-id=${apple.key-id} -# Apple provider configuration sets ES256 signature algorithm +Future callQuarkusService() async { + Map headers = Map.fromEntries([MapEntry("X-Requested-With", "JavaScript")]); -quarkus.oidc.credentials.jwt.subject=${apple.subject} -quarkus.oidc.credentials.jwt.issuer=${apple.issuer} + await http + .get("https://localhost:443/serviceCall") + .then((response) { + if (response.statusCode == 499) { + window.location.assign("https://localhost.com:443/serviceCall"); + } + }); + } ---- -==== Mutual TLS (mTLS) +=== Cross-origin resource sharing -Some OpenID Connect providers may require that a client is authenticated as part of the `Mutual TLS` authentication process. +If you plan to consume this application from a Single-page application running on a different domain, you will need to configure CORS (Cross-Origin Resource Sharing). For more information, see the xref:http-reference.adoc#cors-filter[HTTP CORS documentation]. -`quarkus-oidc` can be configured as follows to support `mTLS`: +=== Calling Cloud provider services -[source,properties] +==== Google Cloud + +You can have Quarkus OIDC `web-app` applications access **Google Cloud services** such as **BigQuery** on behalf of the currently authenticated users who have enabled OpenID Connect (Authorization Code Flow) permissions to such services in their Google Developer Consoles. + +It is super easy to do with https://github.com/quarkiverse[Quarkiverse] https://github.com/quarkiverse/quarkiverse-google-cloud-services[Google Cloud Services], only add +the https://github.com/quarkiverse/quarkiverse-google-cloud-services/releases/latest[latest tag] service dependency, for example: + +[source,xml,role="primary asciidoc-tabs-target-sync-cli asciidoc-tabs-target-sync-maven"] +.pom.xml +---- + + io.quarkiverse.googlecloudservices + quarkus-google-cloud-bigquery + ${quarkiverse.googlecloudservices.version} + ---- -quarkus.oidc.tls.verification=certificate-validation -# Keystore configuration -quarkus.oidc.tls.key-store-file=client-keystore.jks -quarkus.oidc.tls.key-store-password=${key-store-password} +[source,gradle,role="secondary asciidoc-tabs-target-sync-gradle"] +.build.gradle +---- +implementation("io.quarkiverse.googlecloudservices:quarkus-google-cloud-bigquery:${quarkiverse.googlecloudservices.version}") +---- -# Add more keystore properties if needed: -#quarkus.oidc.tls.key-store-alias=keyAlias -#quarkus.oidc.tls.key-store-alias-password=keyAliasPassword +and configure Google OIDC properties: -# Truststore configuration -quarkus.oidc.tls.trust-store-file=client-truststore.jks -quarkus.oidc.tls.trust-store-password=${trust-store-password} -# Add more truststore properties if needed: -#quarkus.oidc.tls.trust-store-alias=certAlias +[source, properties] +---- +quarkus.oidc.provider=google +quarkus.oidc.client-id={GOOGLE_CLIENT_ID} +quarkus.oidc.credentials.secret={GOOGLE_CLIENT_SECRET} +quarkus.oidc.token.issuer=https://accounts.google.com ---- -=== Introspection endpoint authentication +=== Running Quarkus application behind a reverse proxy -Some OpenID Connect Providers may require authenticating to its introspection endpoint using Basic authentication with the credentials different to `client_id` and `client_secret` which may have already been configured to support `client_secret_basic` or `client_secret_post` client authentication methods described in the <> section. +OIDC authentication mechanism can be affected if your Quarkus application is running behind a reverse proxy/gateway/firewall when HTTP `Host` header may be reset to the internal IP address, HTTPS connection may be terminated, etc. For example, an authorization code flow `redirect_uri` parameter may be set to the internal host instead of the expected external one. -If the tokens have to be introspected and the introspection endpoint specific authentication mechanism is required, then you can configure `quarkus-oidc` like this: +In such cases configuring Quarkus to recognize the original headers forwarded by the proxy will be required, for more information, see the xref:http-reference.adoc#reverse-proxy[Running behind a reverse proxy] Vert.x documentation section. + +For example, if your Quarkus endpoint runs in a cluster behind Kubernetes Ingress then a redirect from the OpenID Connect Provider back to this endpoint may not work since the calculated `redirect_uri` parameter may point to the internal endpoint address. This problem can be resolved with the following configuration: [source,properties] ---- -quarkus.oidc.introspection-credentials.name=introspection-user-name -quarkus.oidc.introspection-credentials.secret=introspection-user-secret +quarkus.http.proxy.proxy-address-forwarding=true +quarkus.http.proxy.allow-forwarded=false +quarkus.http.proxy.enable-forwarded-host=true +quarkus.http.proxy.forwarded-host-header=X-ORIGINAL-HOST ---- +where `X-ORIGINAL-HOST` is set by Kubernetes Ingress to represent the external endpoint address. + +`quarkus.oidc.authentication.force-redirect-https-scheme` property may also be used when the Quarkus application is running behind an SSL terminating reverse proxy. + +=== External and internal access to the OIDC provider + +Note that the OpenID Connect Provider externally accessible authorization, logout and other endpoints may have different HTTP(S) URLs compared to the URLs auto-discovered or configured relative to `quarkus.oidc.auth-server-url` internal URL. +In such cases an issuer verification failure may be reported by the endpoint and redirects to the externally accessible Connect Provider endpoints may fail. + +In such cases, if you work with Keycloak then please start it with a `KEYCLOAK_FRONTEND_URL` system property set to the externally accessible base URL. +If you work with other Openid Connect providers then please check your provider's documentation. + [[integration-testing]] -=== Testing +== Testing + +Testing is often tricky when it comes to authentification to a separate OIDC like server. +Quarkus offers several options from mocking to a local run of an OIDC provider. Start by adding the following dependencies to your test project: @@ -1052,7 +1115,7 @@ testImplementation("io.quarkus:quarkus-junit5") ---- [[integration-testing-wiremock]] -==== Wiremock +=== Wiremock Add the following dependency: @@ -1136,7 +1199,7 @@ Additionally, `OidcWiremockTestResource` set token issuer and audience to `https `OidcWiremockTestResource` can be used to emulate all OpenID Connect providers. [[integration-testing-keycloak-devservices]] -==== Dev services for Keycloak +=== Dev services for Keycloak Using xref:security-openid-connect-dev-services.adoc[Dev Services for Keycloak] is recommended for the integration testing against Keycloak. `Dev Services for Keycloak` will launch and initialize a test container: it will create a `quarkus` realm, a `quarkus-app` client (`secret` secret) and add `alice` (`admin` and `user` roles) and `bob` (`user` role) users, where all of these properties can be customized. @@ -1169,7 +1232,7 @@ public class CodeFlowAuthorizationTest { ---- [[integration-testing-keycloak]] -==== Using KeycloakTestResourceLifecycleManager +=== Using KeycloakTestResourceLifecycleManager Use `KeycloakTestResourceLifecycleManager` for your tests only if there is a good reason not to use `Dev Services for Keycloak`. If you need to do the integration testing against Keycloak then you are encouraged to do it with <>. @@ -1234,7 +1297,7 @@ By default, `KeycloakTestResourceLifecycleManager` uses HTTPS to initialize a Ke Default realm name is `quarkus` and client id - `quarkus-web-app` - set `keycloak.realm` and `keycloak.web-app.client` system properties to customize the values if needed. [[integration-testing-security-annotation]] -==== TestSecurity annotation +=== TestSecurity annotation See xref:security-oidc-bearer-token-authentication-concept.adoc#integration-testing-security-annotation[Use TestingSecurity with injected JsonWebToken] section for more information about using `@TestSecurity` and `@OidcSecurity` annotations for testing the `web-app` application endpoint code which depends on the injected ID and access `JsonWebToken` as well as `UserInfo` and `OidcConfigurationMetadata`. @@ -1256,60 +1319,7 @@ quarkus.log.category."io.quarkus.oidc.runtime.OidcRecorder".level=TRACE quarkus.log.category."io.quarkus.oidc.runtime.OidcRecorder".min-level=TRACE ---- -=== Running Quarkus application behind a reverse proxy - -OIDC authentication mechanism can be affected if your Quarkus application is running behind a reverse proxy/gateway/firewall when HTTP `Host` header may be reset to the internal IP address, HTTPS connection may be terminated, etc. For example, an authorization code flow `redirect_uri` parameter may be set to the internal host instead of the expected external one. - -In such cases configuring Quarkus to recognize the original headers forwarded by the proxy will be required, for more information, see the xref:http-reference.adoc#reverse-proxy[Running behind a reverse proxy] Vert.x documentation section. - -For example, if your Quarkus endpoint runs in a cluster behind Kubernetes Ingress then a redirect from the OpenID Connect Provider back to this endpoint may not work since the calculated `redirect_uri` parameter may point to the internal endpoint address. This problem can be resolved with the following configuration: - -[source,properties] ----- -quarkus.http.proxy.proxy-address-forwarding=true -quarkus.http.proxy.allow-forwarded=false -quarkus.http.proxy.enable-forwarded-host=true -quarkus.http.proxy.forwarded-host-header=X-ORIGINAL-HOST ----- - -where `X-ORIGINAL-HOST` is set by Kubernetes Ingress to represent the external endpoint address. - -`quarkus.oidc.authentication.force-redirect-https-scheme` property may also be used when the Quarkus application is running behind an SSL terminating reverse proxy. - -=== External and internal access to the OIDC provider - -Note that the OpenID Connect Provider externally accessible authorization, logout and other endpoints may have different HTTP(S) URLs compared to the URLs auto-discovered or configured relative to `quarkus.oidc.auth-server-url` internal URL. -In such cases an issuer verification failure may be reported by the endpoint and redirects to the externally accessible Connect Provider endpoints may fail. - -In such cases, if you work with Keycloak then please start it with a `KEYCLOAK_FRONTEND_URL` system property set to the externally accessible base URL. -If you work with other Openid Connect providers then please check your provider's documentation. - -=== Customizing authentication requests - -By default, only the `response_type` (set to `code`), `scope` (set to 'openid'), `client_id`, `redirect_uri` and `state` properties are passed as HTTP query parameters to the OpenID Connect provider's authorization endpoint when the user is redirected to it to authenticate. - -You can add more properties to it with `quarkus.oidc.authentication.extra-params`. For example, some OpenID Connect providers may choose to return the authorization code as part of the redirect URI's fragment which would break the authentication process - it can be fixed as follows: - -[source,properties] ----- -quarkus.oidc.authentication.extra-params.response_mode=query ----- - -=== Customizing the authentication error response - -If the user authentication has failed at the OpenID Connect Authorization endpoint, for example, due to an invalid scope or other invalid parameters included in the redirect to the provider, then the provider will redirect the user back to Quarkus not with the `code` but `error` and `error_description` parameters. - -In such cases HTTP `401` will be returned by default. However, you can instead request that a custom public error endpoint is called in order to return a user-friendly HTML error page. Use `quarkus.oidc.authentication.error-path`, for example: - -[source,properties] ----- -quarkus.oidc.authentication.error-path=/error ----- - -It has to start from a forward slash and be relative to the base URI of the current endpoint. -For example, if it is set as '/error' and the current request URI is `https://localhost:8080/callback?error=invalid_scope` then a final redirect will be made to `https://localhost:8080/error?error=invalid_scope`. - -It is important that this error endpoint is a public resource to avoid the user redirected to this page be authenticated again. +You can also from `quarkus dev` console hit `j` to change the application global log level. == References From bc497fd4ff019a2cc6566e7a614eb6b755d73c2c Mon Sep 17 00:00:00 2001 From: Emmanuel Bernard Date: Fri, 2 Jun 2023 14:20:44 +0200 Subject: [PATCH 5/6] OIDC doc - Replace with user-info-required verify-access-token-with-user-info property In OAuth2 case, the latter is more correct. --- .../security-oidc-code-flow-authentication-concept.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc b/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc index 1dcfda4ab9bbd..07048ff5228aa 100644 --- a/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc +++ b/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc @@ -807,7 +807,7 @@ This simplifies how you handle an application supporting multiple OIDC providers The next step is to ensure that the returned access token can be useful and is valid to the current Quarkus endpoint. The first way is to call the OAuth2 provider introspection endpoint by configuring `quarkus.oidc.introspection-path` if the provider offers such an endpoint. In this case you can use the access token as a source of role using `quarkus.oidc.roles.source=accesstoken`. -If no introspection endpoint is present, your next best step is to request <> from the provider as it will at least validate the access token. Use `quarkus.oidc.authentication.user-info-required=true`. +If no introspection endpoint is present, your next best step is to request <> from the provider as it will at least validate the access token. Use `quarkus.oidc.token.verify-access-token-with-user-info=true`. You also need to set the `quarkus.oidc.user-info-path` property to a URL endpoint fetching the user info (or at least to an endpoint protected by the access token). For GitHub, since it does not have an introspection endpoint, we use the last method. From 554a328e3c4f3f61a2b863110f6feedd6151d2c9 Mon Sep 17 00:00:00 2001 From: Emmanuel Bernard Date: Fri, 2 Jun 2023 15:15:36 +0200 Subject: [PATCH 6/6] Apply feedback from Michelle, Sheila, Sergey --- ...oidc-code-flow-authentication-concept.adoc | 344 +++++++++++------- 1 file changed, 212 insertions(+), 132 deletions(-) diff --git a/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc b/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc index 07048ff5228aa..20849967b3272 100644 --- a/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc +++ b/docs/src/main/asciidoc/security-oidc-code-flow-authentication-concept.adoc @@ -9,7 +9,7 @@ include::_attributes.adoc[] :categories: security,web :toclevels: 4 -To protect your web applications, you can use the industry standard authorization code flow mechanism provided by the Quarkus OpenID Connect (OIDC) extension. +To protect your web applications, you can use the industry-standard authorization code flow mechanism provided by the Quarkus OpenID Connect (OIDC) extension. == Overview of the OIDC authorization code flow mechanism @@ -33,7 +33,7 @@ image::authorization_code_flow.png[alt=Authorization Code Flow, width="60%", ali The authorization code flow is completed and the Quarkus web-app uses the tokens issued to access information about the user and grants the relevant role-based authorization to that user. The following tokens are issued: -* ID token: The Quarkus web-app uses the user information in the ID token to enable the authenticated user to log in securely and to provide role-based access to the web-app. +* ID token: The Quarkus `web-app` application uses the user information in the ID token to enable the authenticated user to log in securely and to provide role-based access to the web application. * Access token: The Quarkus web-app might use the access token to access the UserInfo API to get additional information about the authenticated user or to propagate it to another endpoint. * Refresh token: (Optional) If the ID and access tokens expire, the Quarkus web-app can use the refresh token to get new ID and access tokens. @@ -46,13 +46,13 @@ For information about how to support multiple tenants, see xref:security-openid- == Using the authorization code flow mechanism -=== Configuring access to the OIDC Provider endpoint +=== Configuring access to the OIDC provider endpoint -OIDC `web-app` application needs to know the endpoint URLs of OpenID Connect provider's authorization, token, `JsonWebKey` (JWK) set and possibly `UserInfo`, introspection and end session (RP-initiated logout). +The OIDC `web-app` application requires URLs of the OIDC provider's authorization, token, `JsonWebKey` (JWK) set, and possibly the `UserInfo`, introspection, and end session (RP-initiated logout) endpoints. By convention, they are discovered by adding a `/.well-known/openid-configuration` path to the configured `quarkus.oidc.auth-server-url`. -Alternatively, if the discovery endpoint is not available, or if you would like to save on the discovery endpoint round-trip, you can disable the discovery and configure them with relative path values, for example: +Alternatively, if the discovery endpoint is not available, or you prefer to reduce the discovery endpoint round-trip, you can disable endpoint discovery and configure relative path values, for example: [source, properties] ---- @@ -72,7 +72,8 @@ quarkus.oidc.introspection-path=/protocol/openid-connect/token/introspect quarkus.oidc.end-session-path=/protocol/openid-connect/logout ---- -Sometimes, your OpenId Connect provider supports a metadata discovery but does not return all the endpoint URLs required for the authorization code flow to complete or for the application to support the additional functions such as a user logout. In such cases, you can simply configure missing endpoints URL locally: +Some OIDC providers support metadata discovery but do not return all the endpoint URL values required for the authorization code flow to complete or to support application functions, for example, user logout. +To work around this limitation, you can configure the missing endpoint URL values locally, as outlined in the following example: [source, properties] ---- @@ -84,18 +85,21 @@ quarkus.oidc.auth-server-url=http://localhost:8180/oidcprovider/account quarkus.oidc.end-session-path=logout ---- -Exactly the same configuration can be used to override a discovered endpoint URL if that URL does not work for the local Quarkus endpoint and a more specific value is required. For example, one can imagine that in the above example, a provider which supports both global and application specific end-session endpoints returns a global end-session URL such as `http://localhost:8180/oidcprovider/account/global-logout` which will logout the user from all the applications this user is currently logged in, while the current application only wants to get this user logged out from this application, therefore, `quarkus.oidc.end-session-path=logout` is used to override the global end-session URL. +You can use this same configuration to override a discovered endpoint URL if that URL does not work for the local Quarkus endpoint and a more specific value is required. +For example, a provider that supports both global and application-specific end-session endpoints returns a global end-session URL such as `http://localhost:8180/oidcprovider/account/global-logout`. +This URL will log the user out of all of the applications that the user is currently logged into. +However, if the requirement is for the current application to log the user out of only the specific application, you can override the global end-session URL, by setting the `quarkus.oidc.end-session-path=logout` parameter. [[oidc-provider-client-authentication]] ==== OIDC provider client authentication -OIDC providers typically require using applications to be identified and authenticated when they interact with the OIDC endpoints. -Quarkus OIDC (specifically `quarkus.oidc.runtime.OidcProviderClient`) authenticates to the OpenID Connect Provider when the authorization code has to be exchanged for the ID, access and refresh tokens, when the ID and access tokens have to be refreshed or introspected. +OIDC providers typically require applications to be identified and authenticated when they interact with the OIDC endpoints. +Quarkus OIDC, specifically the `quarkus.oidc.runtime.OidcProviderClient` class, authenticates to the OIDC provider when the authorization code must be exchanged for the ID, access, and refresh tokens, or when the ID and access tokens need to be refreshed or introspected. -Typically, client id and client secrets are defined for a given application when it enlist to the OIDC provider. +Typically, client id and client secrets are defined for a given application when it enlists to the OIDC provider. All the https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication[OIDC Client Authentication] options are supported, for example: -`client_secret_basic`: +.Example of `client_secret_basic`: [source,properties] ---- @@ -104,7 +108,7 @@ quarkus.oidc.client-id=quarkus-app quarkus.oidc.credentials.secret=mysecret ---- -or +Or: [source,properties] ---- @@ -113,7 +117,7 @@ quarkus.oidc.client-id=quarkus-app quarkus.oidc.credentials.client-secret.value=mysecret ---- -or with the secret retrieved from a xref:credentials-provider.adoc[CredentialsProvider]: +The following example shows the secret retrieved from a xref:credentials-provider.adoc[credentials provider]: [source,properties] ---- @@ -126,7 +130,7 @@ quarkus.oidc.credentials.client-secret.provider.key=mysecret-key quarkus.oidc.credentials.client-secret.provider.name=oidc-credentials-provider ---- -`client_secret_post`: +.Example of `client_secret_post` [source,properties] ---- @@ -136,7 +140,7 @@ quarkus.oidc.credentials.client-secret.value=mysecret quarkus.oidc.credentials.client-secret.method=post ---- -`client_secret_jwt`, signature algorithm is HS256: +.Example of `client_secret_jwt`, where the signature algorithm is HS256: [source,properties] ---- @@ -145,7 +149,7 @@ quarkus.oidc.client-id=quarkus-app quarkus.oidc.credentials.jwt.secret=AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow ---- -or with the secret retrieved from a xref:credentials-provider.adoc[CredentialsProvider]: +.Example of `client_secret_jwt`, where the secret is retrieved from a xref:credentials-provider.adoc[credentials provider]: [source,properties] ---- @@ -158,7 +162,7 @@ quarkus.oidc.credentials.jwt.secret-provider.key=mysecret-key quarkus.oidc.credentials.jwt.secret-provider.name=oidc-credentials-provider ---- -`private_key_jwt` with the PEM key file, signature algorithm is RS256: +Example of `private_key_jwt` with the PEM key file, and where the signature algorithm is RS256: [source,properties] ---- @@ -167,7 +171,7 @@ quarkus.oidc.client-id=quarkus-app quarkus.oidc.credentials.jwt.key-file=privateKey.pem ---- -`private_key_jwt` with the key store file, signature algorithm is RS256: +.Example of `private_key_jwt` with the keystore file, where the signature algorithm is RS256: [source,properties] ---- @@ -181,7 +185,7 @@ quarkus.oidc.credentials.jwt.key-password=mykeypassword quarkus.oidc.credentials.jwt.key-id=mykeyAlias ---- -Using `client_secret_jwt` or `private_key_jwt` authentication methods ensures that no client secret goes over the wire. +Using `client_secret_jwt` or `private_key_jwt` authentication methods ensures that a client secret does not get sent to the OIDC provider, therefore avoiding the risk of a secret being intercepted by a 'man-in-the-middle' attack. ===== Additional JWT authentication options @@ -215,9 +219,9 @@ quarkus.oidc.credentials.jwt.issuer=custom-issuer ===== Apple POST JWT -Apple OpenID Connect Provider uses a `client_secret_post` method where a secret is a JWT produced with a `private_key_jwt` authentication method but with Apple account specific issuer and subject claims. +The Apple OIDC provider uses a `client_secret_post` method whereby a secret is a JWT produced with a `private_key_jwt` authentication method but with the Apple account-specific issuer and subject claims. -`quarkus-oidc` supports a non-standard `client_secret_post_jwt` authentication method which can be configured as follows: +In Quarkus Security, `quarkus-oidc` supports a non-standard `client_secret_post_jwt` authentication method, which you can configure as follows: [source,properties] ---- @@ -233,11 +237,11 @@ quarkus.oidc.credentials.jwt.subject=${apple.subject} quarkus.oidc.credentials.jwt.issuer=${apple.issuer} ---- -===== Mutual TLS (mTLS) +===== mutual TLS (mTLS) -Some OpenID Connect providers may require that a client is authenticated as part of the `Mutual TLS` authentication process. +Some OpenID Connect providers might require that a client is authenticated as part of the mutual TLS authentication process. -`quarkus-oidc` can be configured as follows to support `mTLS`: +The following example shows how you can configure `quarkus-oidc` to support `mTLS`: [source,properties] ---- @@ -260,9 +264,10 @@ quarkus.oidc.tls.trust-store-password=${trust-store-password} ==== Introspection endpoint authentication -Some OpenID Connect Providers may require authenticating to its introspection endpoint using Basic authentication with the credentials different to `client_id` and `client_secret` which may have already been configured to support `client_secret_basic` or `client_secret_post` client authentication methods described in the <> section. +Some OIDC providers require authenticating to its introspection endpoint by using Basic authentication and with credentials that are different to the `client_id` and `client_secret`. +If you have previously configured security authentication to support either the`client_secret_basic` or `client_secret_post` client authentication methods as described in the <> section, you might need to apply the additional configuration, as follows. -If the tokens have to be introspected and the introspection endpoint specific authentication mechanism is required, then you can configure `quarkus-oidc` like this: +If the tokens have to be introspected and the introspection endpoint-specific authentication mechanism is required, then you can configure `quarkus-oidc`, as follows: [source,properties] ---- @@ -272,23 +277,26 @@ quarkus.oidc.introspection-credentials.secret=introspection-user-secret ==== Redirecting to and from the OIDC provider -When the user is redirected to the OpenID Connect Provider to authenticate, the redirect URL includes a `redirect_uri` query parameter which indicates to the provider where the user has to be redirected to once the authentication has been completed. +When a user is redirected to the OpenID Connect provider to authenticate, the redirect URL includes a `redirect_uri` query parameter, which indicates to the provider where the user has to be redirected to when the authentication is complete. In our case, this is the Quarkus application. -Quarkus will set this parameter to the current application request URL by default. For example, if the user is trying to access a Quarkus service endpoint at `http://localhost:8080/service/1` then the `redirect_uri` parameter will be set to `http://localhost:8080/service/1`. Similarly, if the request URL is `http://localhost:8080/service/2` then the `redirect_uri` parameter will be set to `http://localhost:8080/service/2`, etc. +Quarkus sets this parameter to the current application request URL by default. +For example, if a user is trying to access a Quarkus service endpoint at `http://localhost:8080/service/1` then the `redirect_uri` parameter is set to `http://localhost:8080/service/1`. +Similarly, if the request URL is `http://localhost:8080/service/2` then the `redirect_uri` parameter is set to `http://localhost:8080/service/2`. -Some OpenID Connect Providers require the `redirect_uri` to have the same value for a given application (e.g. `http://localhost:8080/service/callback`) for all the redirect URLs. -In such cases, a `quarkus.oidc.authentication.redirect-path` property has to be set, for example, `quarkus.oidc.authentication.redirect-path=/service/callback`, and Quarkus will set the `redirect_uri` parameter to an absolute URL such as `http://localhost:8080/service/callback` which will be the same regardless of the current request URL. +Some OIDC providers require the `redirect_uri` to have the same value for a given application, for example, `http://localhost:8080/service/callback`, for all the redirect URLs. +In such cases, a `quarkus.oidc.authentication.redirect-path` property has to be set, for example, `quarkus.oidc.authentication.redirect-path=/service/callback`, and Quarkus will set the `redirect_uri` parameter to an absolute URL such as `http://localhost:8080/service/callback`, which will be the same regardless of the current request URL. -If `quarkus.oidc.authentication.redirect-path` is set but -If you need the original request URL to be restored after the user has been redirected back to a unique callback URL such as `http://localhost:8080/service/callback`, set `quarkus.oidc.authentication.restore-path-after-redirect` property to `true`. +If `quarkus.oidc.authentication.redirect-path` is set but you need the original request URL to be restored after the user has been redirected back to a unique callback URL, for example, `http://localhost:8080/service/callback`, set `quarkus.oidc.authentication.restore-path-after-redirect` property to `true`. This will restore the request URL such as `http://localhost:8080/service/1`. ==== Customizing authentication requests By default, only the `response_type` (set to `code`), `scope` (set to 'openid'), `client_id`, `redirect_uri` and `state` properties are passed as HTTP query parameters to the OpenID Connect provider's authorization endpoint when the user is redirected to it to authenticate. -You can add more properties to it with `quarkus.oidc.authentication.extra-params`. For example, some OpenID Connect providers may choose to return the authorization code as part of the redirect URI's fragment which would break the authentication process - it can be fixed as follows: +You can add more properties to it with `quarkus.oidc.authentication.extra-params`. +For example, some OIDC providers might choose to return the authorization code as part of the redirect URI's fragment, which would break the authentication process. +The following example shows how you can work around this issue: [source,properties] ---- @@ -297,19 +305,22 @@ quarkus.oidc.authentication.extra-params.response_mode=query ==== Customizing the authentication error response -If the user authentication has failed at the OpenID Connect Authorization endpoint, for example, due to an invalid scope or other invalid parameters included in the redirect to the provider, then the provider will redirect the user back to Quarkus not with the `code` but `error` and `error_description` parameters. +If the user authentication fails at the OIDC authorization endpoint, then the provider will redirect the user back to Quarkus with `error` and `error_description` parameters instead of `code`. +For example, this can happen when an invalid scope or other invalid parameters are included in the redirect to the provider. -In such cases HTTP `401` will be returned by default. However, you can instead request that a custom public error endpoint is called in order to return a user-friendly HTML error page. Use `quarkus.oidc.authentication.error-path`, for example: +In such cases, an HTTP `401`error will be returned by default. +However, you can instead request that a custom public error endpoint is called to return a more user-friendly HTML error page. +To do this, set the `quarkus.oidc.authentication.error-path` property, as shown in the following example: [source,properties] ---- quarkus.oidc.authentication.error-path=/error ---- -It has to start from a forward slash and be relative to the base URI of the current endpoint. +Ensure that the property starts with a forward slash (/) character and the path is relative to the base URI of the current endpoint. For example, if it is set as '/error' and the current request URI is `https://localhost:8080/callback?error=invalid_scope` then a final redirect will be made to `https://localhost:8080/error?error=invalid_scope`. -It is important that this error endpoint is a public resource to avoid the user redirected to this page be authenticated again. +It is important to ensure that this error endpoint is a public resource to prevent the user from being redirected to this page to be authenticated again. === Accessing authorization data @@ -321,7 +332,7 @@ Let's first discuss how to access information around authorization. The OIDC code authentication mechanism acquires three tokens during the authorization code flow: https://openid.net/specs/openid-connect-core-1_0.html#IDToken[IDToken], Access Token, and Refresh Token. ID Token is always a JWT token and is used to represent a user authentication with the JWT claims. -You can for example get which OIDC enpoint issued it, the user name and other information called _claims_. +You can use this to get the issuing OIDC endpoint, the username, and other information called _claims_. One can access ID Token claims by injecting `JsonWebToken` with an `IdToken` qualifier: [source, java] @@ -378,17 +389,17 @@ public class ProtectedResource { } ---- -Note that `AccessTokenCredential` is used if the Access Token issued to the Quarkus `web-app` application is opaque (binary) and can not be parsed to a `JsonWebToken` or if the inner content is necessary for the application. +Note that `AccessTokenCredential` is used if the access token issued to the Quarkus `web-app` application is opaque (binary) and can not be parsed to a `JsonWebToken` or if the inner content is necessary for the application. Injection of the `JsonWebToken` and `AccessTokenCredential` is supported in both `@RequestScoped` and `@ApplicationScoped` contexts. -RefreshToken is used (by Quarkusn OIDC) to refresh the current ID and access tokens as part of its <> process. +RefreshToken is used by Quarkusn OIDC to refresh the current ID and access tokens as part of its <> process. [[user-info]] ==== User info -If the ID token does not provide enough information about the currently-authenticated user, you can get more information from the user info endpoint. -Set the `quarkus.oidc.authentication.user-info-required=true` property for a https://openid.net/specs/openid-connect-core-1_0.html#UserInfo[UserInfo] JSON object from the OIDC userinfo endpoint to be requested. +If the ID token does not provide enough information about the currently-authenticated user, you can get more information from the `UserInfo` endpoint. +Set the `quarkus.oidc.authentication.user-info-required=true` property for a link:https://openid.net/specs/openid-connect-core-1_0.html#UserInfo[UserInfo] JSON object from the OIDC `UserInfo` endpoint to be requested. A request will be sent to the OpenID Provider UserInfo endpoint using the access token returned with the authorization code grant response and an `io.quarkus.oidc.UserInfo` (a simple `jakarta.json.JsonObject` wrapper) object will be created. `io.quarkus.oidc.UserInfo` can be either injected or accessed as a SecurityIdentity `userinfo` attribute. @@ -400,14 +411,15 @@ The current tenant's discovered link:https://openid.net/specs/openid-connect-dis The default tenant's `OidcConfigurationMetadata` is injected if the endpoint is public. [[token-claims-roles]] -==== Mapping Token claims and SecurityIdentity roles +==== Mapping token claims and `SecurityIdentity` roles The way the roles are mapped to the SecurityIdentity roles from the verified tokens is identical to how it is done for the xref:security-oidc-bearer-token-authentication-concept.adoc[Bearer tokens] with the only difference being that https://openid.net/specs/openid-connect-core-1_0.html#IDToken[ID Token] is used as a source of the roles by default. [NOTE] --- -If you use Keycloak then you should set a `microprofile_jwt` client scope for ID token to contain a `groups` claim, please see the https://www.keycloak.org/docs/latest/server_admin/#protocol[Keycloak Server Administration Guide] for more information. --- +==== +If you use Keycloak, set a `microprofile_jwt` client scope for ID token to contain a `groups` claim. +For more information, see the link:https://www.keycloak.org/docs/latest/server_admin/#protocol[Keycloak Server Administration Guide]. +==== But depending on your OIDC provider, roles might be stored in the access token or the user info. @@ -425,11 +437,11 @@ This is done by ensuring tokens are trustable. [[token-verification-introspection]] ==== Token verification and introspection -OIDC inherits the bearer authentication token verification and introspection logic described in detail at xref:security-oidc-bearer-token-authentication-concept.adoc#token-verification-introspection[Token Verification And Introspection]. +The verification process of OIDC authorization code flow tokens follows the bearer authentication token verification and introspection logic. For more information, see the xref:security-oidc-bearer-token-authentication-concept.adoc#token-verification-introspection[Token Verification And Introspection] section of the "Quarkus OpenID Connect (OIDC) Bearer authentication" guide. [NOTE] -- -In case of `web-app` applications, only the `IdToken` is verified by default since the access token is not used to access the current Quarkus `web-app` endpoint and rather meant to be propagated to the services expecting this access token. +With Quarkus `web-app` applications, only the `IdToken` is verified by default because the access token is not used to access the current Quarkus `web-app` endpoint and is intended to be propagated to the services expecting this access token. If you expect the access token to contain the roles required to access the current Quarkus endpoint (`quarkus.oidc.roles.source=accesstoken`) then it will also be verified. -- @@ -437,7 +449,7 @@ If you expect the access token to contain the roles required to access the curre ==== Token introspection and UserInfo cache Code flow access tokens are not introspected unless they are expected to be the source of roles. -It will however be used to get `UserInfo`. +They will however be used to get `UserInfo`. There will be one or two remote calls with the code flow access token, if the token introspection and/or `UserInfo` are required. Please see xref:security-oidc-bearer-token-authentication-concept.adoc#token-introspection-userinfo-cache[Token Introspection and UserInfo cache] for more information about using a default token cache or registering a custom cache implementation. @@ -448,13 +460,14 @@ Please see xref:security-oidc-bearer-token-authentication-concept.adoc#token-int Please see xref:security-oidc-bearer-token-authentication-concept.adoc#jwt-claim-verification[JSON Web Token Claim verification] section about the claim verification, including the `iss` (issuer) claim. It applies to ID tokens but also to access tokens in a JWT format if the `web-app` application has requested the access token verification. -==== Further security with Proof key for code exchange (PKCE) +==== Further security with Proof Key for Code Exchange (PKCE) -link:https://datatracker.ietf.org/doc/html/rfc7636[Proof Key for Code Exchange] (PKCE) minimizes the risk of the authorization code interception. +link:https://datatracker.ietf.org/doc/html/rfc7636[Proof Key for Code Exchange] (PKCE) minimizes the risk of authorization code interception. -While `PKCE` is of primary importance to the public OpenID Connect clients (such as the SPA scripts running in a browser), it can also provide an extra level of protection to Quarkus OIDC `web-app` applications which are confidential OpenID Connect clients capable of securely storing the client secret and using it to exchange the code for the tokens. +While PKCE is of primary importance to public OpenID Connect clients, such as SPA scripts running in a browser, it can also provide an extra level of protection to Quarkus OIDC `web-app` applications. +With PKCE, Quarkus OIDC `web-app` applications are confidential OpenID Connect clients capable of securely storing the client secret and using it to exchange the code for the tokens. -You can enable `PKCE` for your OIDC `web-app` endpoint with a `quarkus.oidc.authentication.pkce-required` property and a 32 characters long secret, for example: +You can enable `PKCE` for your OIDC `web-app` endpoint with a `quarkus.oidc.authentication.pkce-required` property and a 32-character secret, as shown in the following example: [source, properties] ---- @@ -462,56 +475,79 @@ quarkus.oidc.authentication.pkce-required=true quarkus.oidc.authentication.pkce-secret=eUk1p7UB3nFiXZGUXi0uph1Y9p34YhBU ---- -If you already have a 32 characters long client secret then `quarkus.oidc.authentication.pkce-secret` does not have to be set unless you prefer to use a different secret key. +If you already have a 32-characters client secret then you do not need to set the `quarkus.oidc.authentication.pkce-secret` property unless you prefer to use a different secret key. -The secret key is required for encrypting a randomly generated `PKCE` `code_verifier` while the user is being redirected with the `code_challenge` query parameter to OpenID Connect Provider to authenticate. The `code_verifier` will be decrypted when the user is redirected back to Quarkus and sent to the token endpoint alongside the `code`, client secret and other parameters to complete the code exchange. The provider will fail the code exchange if a `SHA256` digest of the `code_verifier` does not match the `code_challenge` provided during the authentication request. +The secret key is required for encrypting a randomly generated `PKCE` `code_verifier` while the user is being redirected with the `code_challenge` query parameter to an OIDC provider to authenticate. +The `code_verifier` is decrypted when the user is redirected back to Quarkus and sent to the token endpoint alongside the `code`, client secret, and other parameters to complete the code exchange. +The provider will fail the code exchange if a `SHA256` digest of the `code_verifier` does not match the `code_challenge` that was provided during the authentication request. -=== Handling and controlling the life time of authentication +=== Handling and controlling the lifetime of authentication -Another important aspect of authentication is to be sure that data it is based on is fresh while not requiring the user to authenticate at every single request. -There are also situation when a logout is explicitly requested. -This section discusses the various key notions necessarity to find the right balance for your Quarkus application. +Another important requirement for authentication is to ensure that the data the session is based on is up-to-date without requiring the user to authenticate for every single request. +There are also situations where a logout event is explicitly requested. +Use the following key points to find the right balance for securing your Quarkus applications: [[oidc-cookies]] ==== Cookies The OIDC adapter uses cookies to keep the session, code flow, and post-logout state. -This state is a key element controlling the life time of authentication data. +This state is a key element controlling the lifetime of authentication data. -`quarkus.oidc.authentication.cookie-path` property is used to ensure the same cookie is visible when you access the protected resources with overlapping or different roots, for example: +Use the `quarkus.oidc.authentication.cookie-path` property to ensure that the same cookie is visible when you access protected resources with overlapping or different roots, for example: * `/index.html` and `/web-app/service` * `/web-app/service1` and `/web-app/service2` * `/web-app1/service` and `/web-app2/service` -`quarkus.oidc.authentication.cookie-path` is set to `/` by default but can be narrowed to a more specific root path such as `/web-app`. +By default, `quarkus.oidc.authentication.cookie-path` is set to `/` but you can change this to a more specific path if required, for example, `/web-app`. -Sometimes the cookie path needs to be set dynamically. +To set the cookie path dynamically, configure the `quarkus.oidc.authentication.cookie-path-header` property. Set the `quarkus.oidc.authentication.cookie-path-header` property. -For example, setting `quarkus.oidc.authentication.cookie-path-header=X-Forwarded-Prefix` means that the value of HTTP `X-Forwarded-Prefix` header will be used to set a cookie path. +For example, to set the cookie path dynamically by using the value of the`X-Forwarded-Prefix` HTTP header, configure the property to `quarkus.oidc.authentication.cookie-path-header=X-Forwarded-Prefix`. If `quarkus.oidc.authentication.cookie-path-header` is set but no configured HTTP header is available in the current request then the `quarkus.oidc.authentication.cookie-path` will be checked. -If your application is deployed across multiple domains, set a `quarkus.oidc.authentication.cookie-domain` property for the session cookie be visible to all protected Quarkus services, for example, if you have 2 services deployed at: +If your application is deployed across multiple domains, set the `quarkus.oidc.authentication.cookie-domain` property so that the session cookie is visible to all protected Quarkus services. +For example, if you have Quarkus services deployed on the following two domains, then you must set the `quarkus.oidc.authentication.cookie-domain` property to `company.net`. -* https://whatever.wherever.company.net/ -* https://another.address.company.net/ +* \https://whatever.wherever.company.net/ +* \https://another.address.company.net/ -then the `quarkus.oidc.authentication.cookie-domain` property must be set to `company.net`. [[token-state-manager]] ===== Customizing the cookie with TokenStateManager -OIDC `CodeAuthenticationMechanism` is using the default `io.quarkus.oidc.TokenStateManager` interface implementation to keep the ID, access and refresh tokens returned in the authorization code or refresh grant responses in a session cookie. It makes Quarkus OIDC endpoints completely stateless. +OIDC `CodeAuthenticationMechanism` uses the default `io.quarkus.oidc.TokenStateManager` interface implementation to keep the ID, access, and refresh tokens returned in the authorization code or to refresh grant responses in a session cookie. +This makes Quarkus OIDC endpoints completely stateless. + +An access token is only required if the endpoint needs to: + +* Retrieve `UserInfo` +* Access the downstream service with this access token +* Use the roles associated with the access token, which are checked by default + +In such cases, use the `quarkus.oidc.token-state-manager.strategy` property to configure the token state strategy as follows: + +[Attributes] +|=== +|To... |Set the property to ... + +|Keep the ID and refresh tokens only +|`quarkus.oidc.token-state-manager.strategy=id-refresh-token` -Note that some endpoints do not require the access token. An access token is only required if the endpoint needs to retrieve `UserInfo` or access the downstream service with this access token or use the roles associated with the access token (the roles in the ID token are checked by default). In such cases you can set either `quarkus.oidc.token-state-manager.strategy=id-refresh-token` (keep ID and refresh tokens only) or `quarkus.oidc.token-state-manager.strategy=id-token` (keep ID token only). +|Keep the ID token only +|`quarkus.oidc.token-state-manager.strategy=id-token` -If the ID, access and refresh tokens are JWT tokens then combining all of them (if the strategy is the default `keep-all-tokens`) or only ID and refresh tokens (if the strategy is `id-refresh-token`) may produce a session cookie value larger than 4KB and the browsers may not be able to keep this cookie. -In such cases, you can use `quarkus.oidc.token-state-manager.split-tokens=true` to have a unique session token per each of these tokens. +|=== -Note that `TokenStateManager` will encrypt the tokens before storing them in the session cookie. -For example, here is how you configure it to split the tokens and encrypt them: + +If your chosen cookie strategy combines tokens and generates a large session cookie value that is greater than 4KB, some browsers might not be able to handle such cookie sizes. +This can occur when the ID, access, and refresh tokens are JWT tokens and the selected strategy is `keep-all-tokens` or with ID and refresh tokens when the strategy is `id-refresh-token`. +To workaround this issue, you can set `quarkus.oidc.token-state-manager.split-tokens=true` to create a unique session token for each token. + +`TokenStateManager` encrypts the tokens before storing them in the session cookie. +The following example shows how you configure `TokenStateManager` to split the tokens and encrypt them: [source, properties] ---- @@ -523,13 +559,22 @@ quarkus.oidc.token-state-manager.split-tokens=true quarkus.oidc.token-state-manager.encryption-secret=eUk1p7UB3nFiXZGUXi0uph1Y9p34YhBU ---- -The token encryption secret must be at least 32 characters long. If this key is not configured then either `quarkus.oidc.credentials.secret` or `quarkus.oidc.credentials.jwt.secret` will be hashed to create an encryption key. +The token encryption secret must be at least 32 characters long. +If this key is not configured then either `quarkus.oidc.credentials.secret` or `quarkus.oidc.credentials.jwt.secret` will be hashed to create an encryption key. + + +Configure the `quarkus.oidc.token-state-manager.encryption-secret` property if Quarkus authenticates to the OpenId Connect Provider by using one of the following authentication methods: + +* mTLS +* `private_key_jwt`, where a private RSA or EC key is used to sign a JWT token -`quarkus.oidc.token-state-manager.encryption-secret` should be configured if Quarkus authenticates to OpenId Connect Provider using either mTLS or `private_key_jwt` (where a private RSA or EC key is used to sign a JWT token) authentication methods, otherwise a random key will be generated which will be problematic if the Quarkus application is running in the cloud with multiple pods managing the requests. +Otherwise, a random key is generated, which can be problematic if the Quarkus application is running in the cloud with multiple pods managing the requests. -If you need you can disable encrypting the tokens in the session cookie with `quarkus.oidc.token-state-manager.encryption-required=false`. +You can disable token encryption in the session cookie by setting `quarkus.oidc.token-state-manager.encryption-required=false`. -Register your own `io.quarkus.oidc.TokenStateManager' implementation as an `@ApplicationScoped` CDI bean if you need to customize the way the tokens are associated with the session cookie. For example, you may want to keep the tokens in a database and have only a database pointer stored in a session cookie. Note though that it may present some challenges in making the tokens available across multiple microservices nodes. +Register your own `io.quarkus.oidc.TokenStateManager' implementation as an `@ApplicationScoped` CDI bean if you need to customize the way the tokens are associated with the session cookie. +For example, you may want to keep the tokens in a database and have only a database pointer stored in a session cookie. +Note that this approach might introduce some challenges if you need to make the tokens available across multiple microservices nodes. Here is a simple example: @@ -589,7 +634,7 @@ public class CustomTokenStateManager implements TokenStateManager { ==== Logout and expiration -There are two main ways for the authentication information to expire: the tokens are expired and no longer renewed or an explicit logout operation is triggered. +There are two main ways for the authentication information to expire: the tokens expired and were not renewed or an explicit logout operation was triggered. Let's start with explicit logout operations. @@ -606,7 +651,7 @@ The user will be returned to the endpoint post logout page once the logout has b If the `quarkus.oidc.logout.post-logout-path` is set then a `q_post_logout` cookie will be created and a matching `state` query parameter will be added to the logout redirect URI and the OpenID Connect Provider will return this `state` once the logout has been completed. It is recommended for the Quarkus `web-app` applications to check that a `state` query parameter matches the value of the `q_post_logout` cookie which can be done for example in a Jakarta REST filter. -Note that a cookie name will vary when using xref:security-openid-connect-multitenancy.adoc[OpenID Connect Multi-Tenancy]. For example, it will be named `q_post_logout_tenant_1` for a tenant with a `tenant_1` ID, and so on. +Note that a cookie name varies when using xref:security-openid-connect-multitenancy.adoc[OpenID Connect Multi-Tenancy]. For example, it will be named `q_post_logout_tenant_1` for a tenant with a `tenant_1` ID, and so on. Here is an example of how to configure a Quarkus app initiated logout flow: @@ -634,10 +679,11 @@ You may also need to set `quarkus.oidc.authentication.cookie-path` to a path val For more information, see the <> section. [NOTE] --- -Some OpenID Connect providers do not support https://openid.net/specs/openid-connect-session-1_0.html#RPLogout[RP-Initiated Logout] specification (possibly because it is still technically a draft) and do not return an OpenID Connect well-known `end_session_endpoint` metadata property. However, it is not be a problem since these providers' specific logout mechanisms only differ in how the logout URL query parameters are named. +==== +Some OIDC providers do not support link:https://openid.net/specs/openid-connect-session-1_0.html#RPLogout[RP-initiated logout] specification and do not return an OpenID Connect well-known `end_session_endpoint` metadata property. +However, this is not a problem for Quarkus because the specific logout mechanisms of such OIDC providers only differ in how the logout URL query parameters are named. -According to the https://openid.net/specs/openid-connect-session-1_0.html#RPLogout[RP-Initiated Logout] specification, the `quarkus.oidc.logout.post-logout-path` property is represented as a `post_logout_redirect_uri` query parameter which will not be recognized by the providers which do not support this specification. +According to the https://openid.net/specs/openid-connect-session-1_0.html#RPLogout[RP-initiated logout] specification, the `quarkus.oidc.logout.post-logout-path` property is represented as a `post_logout_redirect_uri` query parameter, which is not recognized by the providers that do not support this specification. You can use `quarkus.oidc.logout.post-logout-url-param` to work around this issue. You can also request more logout query parameters added with `quarkus.oidc.logout.extra-params`. For example, here is how you can support a logout with `Auth0`: @@ -660,7 +706,7 @@ quarkus.oidc.logout.post-logout-uri-param=returnTo # For example, if 'client_id' is provided then a valid logout URI should be set as Auth0 Application property, without it - as Auth0 Tenant property. quarkus.oidc.logout.extra-params.client_id=${quarkus.oidc.client-id} ---- --- +==== [[back-channel-logout]] ===== Back-channel logout @@ -682,9 +728,11 @@ quarkus.oidc.application-type=web-app quarkus.oidc.logout.backchannel.path=/back-channel-logout ---- -Absolute `Back-Channel Logout` URL is calculated by adding `quarkus.oidc.back-channel-logout.path` to the current endpoint URL, for example, `http://localhost:8080/back-channel-logout`. You will need to configure this URL in the Admin Console of your OpenID Connect Provider. +The absolute `back-channel logout` URL is calculated by adding `quarkus.oidc.back-channel-logout.path` to the current endpoint URL, for example, `http://localhost:8080/back-channel-logout`. +You will need to configure this URL in the admin console of your OIDC provider. -Note that you will also need to configure a token age property for the logout token verification to succeed if your OpenID Connect Provider does not set an expiry claim in the current logout token, for example, `quarkus.oidc.token.age=10S` sets a number of seconds that must not elapse since the logout token's `iat` (issued at) time to 10. +You will also need to configure a token age property for the logout token verification to succeed if your OpenID Connect Provider does not set an expiry claim in the current logout token. +For example, set `quarkus.oidc.token.age=10S` to ensure that no more than 10 seconds elapse since the logout token's `iat` (issued at) time. [[front-channel-logout]] ===== Front-channel logout @@ -710,12 +758,12 @@ This path will be compared against the current request's path and the user will [[local-logout]] ===== Local logout -<> will log the person out from the OIDC provider, if it is used as single sign on, it might not be what you desire. -If for example your OIDC provider is Google, you will be logged out from Google and its services. +<> will log the user out of the OIDC provider, if it is used as single sign-on, it might not be what you require. +If, for example, your OIDC provider is Google, you will be logged out from Google and its services. Instead the user might just want to log out of that specific application. -Another use case if if the OIDC provider does not have a logout endpoint. +Another use case might be when the OIDC provider does not have a logout endpoint. -You can support a local logout with the help of the <> which only clears the local session cookie, for example: +By using <>, you can support a local logout, which means that only the local session cookie is cleared, as shown in the following example: [source,java] ---- @@ -740,44 +788,62 @@ public class ServiceResource { ---- [[oidc-session]] -====== Using OidcSession for local logout +====== Using `OidcSession` for local logout -`io.quarkus.oidc.OidcSession` is a wrapper around the current `IdToken`. It can help to perform a <>, retrieve the current session's tenant identifier and check when the session will expire. More useful methods will be added to it over time. +`io.quarkus.oidc.OidcSession` is a wrapper around the current `IdToken`, which can help to perform a <>, retrieve the current session's tenant identifier, and check when the session will expire. +More useful methods will be added to it over time. [[session-management]] -==== Expiration via Session management +==== Session management -By default, the logout is based on the expiration time of the ID Token issued by the OpenID Connect Provider. When the ID Token expires, the current user session at the Quarkus endpoint is invalidated and the user is redirected to the OpenID Connect Provider again to authenticate. If the session at the OpenID Connect Provider is still active, users are automatically re-authenticated without having to provide their credentials again. +By default, logout is based on the expiration time of the ID token issued by the OIDC provider. When the ID token expires, the current user session at the Quarkus endpoint is invalidated and the user is redirected to the OIDC provider again to authenticate. +If the session at the OIDC provider is still active, users are automatically re-authenticated without needing to provide their credentials again. -The current user session may be automatically extended by enabling a `quarkus.oidc.token.refresh-expired` property. If it is set to `true` then when the current ID Token expires a Refresh Token Grant will be used to refresh ID Token as well as Access and Refresh Tokens. +The current user session can be automatically extended by enabling the `quarkus.oidc.token.refresh-expired` property. +If set to `true`, when the current ID token expires, a refresh token grant will be used to refresh the ID token as well as access and refresh tokens. [TIP] -- -If you have a xref:security-oidc-bearer-token-authentication-concept.adoc#single-page-applications[Single Page Application for Service Applications] where your OpenID Connect Provider script such as `keycloak.js` is managing an authorization code flow then that script will also control the SPA authentication session lifespan. +If you have a xref:security-oidc-bearer-token-authentication-concept.adoc#single-page-applications[single page application for service applications] where your OIDC provider script such as `keycloak.js` is managing an authorization code flow then that script will also control the SPA authentication session lifespan. -- -If you work with a Quarkus OIDC `web-app` application then it is Quarkus OIDC Code Authentication mechanism which is managing the user session lifespan. +If you work with a Quarkus OIDC `web-app` application, then it is the Quarkus OIDC code authentication mechanism that is managing the user session lifespan. -To use the refresh token, you should carefully configure the various lifespan of the ID token, the refresh token, the cookie, etc so they work in tandem. -The so called session age should be longer than the ID token lifespan and close to or equal to the refresh token lifespan. +To use the refresh token, you should carefully configure the session cookie age. +The session age should be longer than the ID token lifespan and close to or equal to the refresh token lifespan. -The session age is calculated by adding the lifespan value of the current IDToken and the values of the `quarkus.oidc.authentication.session-age-extension` and `quarkus.oidc.token.lifespan-grace` properties. Of the last two properties only `quarkus.oidc.authentication.session-age-extension` should be used to significantly extend the session lifespan if required since `quarkus.oidc.token.lifespan-grace` is only meant for taking some small clock skews into consideration. +You calculate the session age by adding the lifespan value of the current ID token and the values of the `quarkus.oidc.authentication.session-age-extension` and `quarkus.oidc.token.lifespan-grace` properties. +[TIP] +-- +You use only the `quarkus.oidc.authentication.session-age-extension` property to significantly extend the session lifespan, if required. +You use the `quarkus.oidc.token.lifespan-grace` property only for taking some small clock skews into consideration. +-- -When the currently authenticated user returns to the protected Quarkus endpoint and the ID token associated with the session cookie has expired then, by default, the user will be auto-redirected to the OIDC Authorization endpoint to re-authenticate. Most likely the OIDC provider will challenge the user again though not necessarily if the session between the user and this OIDC provider is still active which may happen if it is configured to last longer than the ID token. +When the current authenticated user returns to the protected Quarkus endpoint and the ID token associated with the session cookie has expired, then, by default, the user is automatically redirected to the OIDC Authorization endpoint to re-authenticate. +The OIDC provider might challenge the user again if the session between the user and this OIDC provider is still active, which might happen if the session is configured to last longer than the ID token. -If the `quarkus.oidc.token.refresh-expired` is set to `true`, then the expired ID token (as well as the access token) will be refreshed using the refresh token returned with the initial authorization code grant response. This refresh token may also be recycled (refreshed) itself as part of this process. As a result the new session cookie will be created and the session will be extended. +If the `quarkus.oidc.token.refresh-expired` is set to `true`, then the expired ID token (as well as the access token) is refreshed by using the refresh token returned with the initial authorization code grant response. +This refresh token might also be recycled (refreshed) itself as part of this process. +As a result, the new session cookie is created and the session is extended. [NOTE] -- -`quarkus.oidc.authentication.session-age-extension` can be important when dealing with expired ID tokens, when the user is not very active. If the ID token expires, then the session cookie may not be returned to the Quarkus endpoint during the next user request as the cookie lifespan would ahve elapsed. Quarkus will assume it is the first authentication request. Set `quarkus.oidc.authentication.session-age-extension` to be _reasonably_ long for your barely active users and in accordance with your security policies. +In instances where the user is not very active, you can use the `quarkus.oidc.authentication.session-age-extension` property to help handle expired ID tokens. +If the ID token expires, the session cookie might not be returned to the Quarkus endpoint during the next user request as the cookie lifespan would have elapsed. +Quarkus assumes that this request is the first authentication request. +Set `quarkus.oidc.authentication.session-age-extension` to be _reasonably_ long for your barely-active users and in accordance with your security policies. -- You can go one step further and proactively refresh ID tokens or access tokens that are about to expire. Set `quarkus.oidc.token.refresh-token-time-skew` to the value you want to anticipate the refresh. If, during the current user request, it is calculated that the current ID token will expire within this `quarkus.oidc.token.refresh-token-time-skew` then it will be refreshed and the new session cookie will be created. This property should be set to a value which is less than the ID token lifespan; the closer it is to this lifespan value the more often the ID token will be refreshed. -You can have this process further optimized by having a simple JavaScript function periodically emulating the user activity by pinging your Quarkus endpoint thus minimizing the window during which the user may have to be re-authenticated. +You can further optimize this process by having a simple JavaScript function ping your Quarkus endpoint to periodically emulate the user activity, which minimizes the time frame during which the user might have to be re-authenticated. -Note this user session can not be extended forever - the returning user with the expired ID token will have to re-authenticate at the OIDC provider endpoint once the refresh token has expired. +[NOTE] +-- +You cannot extend the user session indefinitely. +The returning user with the expired ID token will have to re-authenticate at the OIDC provider endpoint once the refresh token has expired. +-- [[oauth2]] === Integration with GitHub and non-OIDC OAuth2 providers @@ -785,42 +851,48 @@ Note this user session can not be extended forever - the returning user with the Some well known providers such as GitHub or LinkedIn are not OpenID Connect but OAuth2 providers which support the `authorization code flow`, for example, link:https://docs.github.com/en/developers/apps/building-oauth-apps/authorizing-oauth-apps[GitHub OAuth2] and link:https://docs.microsoft.com/en-us/linkedin/shared/authentication/authorization-code-flow[LinkedIn OAuth2]. Remember, OIDC is built on top of OAuth2. -The main difference between OpenID Connect and OAuth2 providers is that OpenID Connect providers return an `ID Token` representing a user authentication, in addition to the standard authorization code flow `access` and `refresh` tokens returned by `OAuth2` providers. +The main difference between OpenID Connect and OAuth2 providers is that OpenID Connect providers return an `ID Token` that represents a user authentication, in addition to the standard authorization code flow `access` and `refresh` tokens returned by `OAuth2` providers. OAuth2 providers such as GitHub do not return `IdToken`, the fact of the user authentication is implicit and is indirectly represented by the `access` token which represents an authenticated user authorizing the current Quarkus `web-app` application to access some data on behalf of the authenticated user. -While in the OIDC case, we validate the ID Token as proof of the authentication validity, in the raw OAuth2 case, we need to validate the access token. +For OIDC, you validate the ID token as proof of authentication validity whereas in the case of OAuth2, you validate the access token. This is done by subsequently calling an endpoint that requires the access token and that typically returns user information. -This very much the same as the OIDC <> approach which is fetched by the OIDC flow on your behalf. +This approach is similar to the OIDC <> approach, with `UserInfo` fetched by Quarkus OIDC on your behalf. -For example, when working with GitHub, the Quarkus endpoint can acquire an `access` token which will allow it to request a GitHub profile of the current user. +For example, when working with GitHub, the Quarkus endpoint can acquire an `access` token which allows the Quarkus endpoint to request a GitHub profile for the current user. To support the integration with such OAuth2 servers, `quarkus-oidc` needs to be configured a bit differently to allow the authorization code flow responses without `IdToken`: `quarkus.oidc.authentication.id-token-required=false`. [NOTE] -- -Even though you will configure the extension to support the authorization code flows without `IdToken`, an internal `IdToken` will be generated to standardize the way `quarkus-oidc` operates: an `IdToken` is used to support the authentication session and to avoid redirecting the user to the provider such as GitHub on every request. In this case the session lifespan is set to 5 minutes which can be extended further as described in the <> section. +Even though you configure the extension to support the authorization code flows without `IdToken`, an internal `IdToken` is generated to standardize the way `quarkus-oidc` operates. +You use an `IdToken` to support the authentication session and to avoid redirecting the user to the provider, such as GitHub, on every request. +In this case, the session lifespan is set to 5 minutes, which you can can extend further as described in the <> section. -This simplifies how you handle an application supporting multiple OIDC providers. +This simplifies how you handle an application that supports multiple OIDC providers. -- The next step is to ensure that the returned access token can be useful and is valid to the current Quarkus endpoint. -The first way is to call the OAuth2 provider introspection endpoint by configuring `quarkus.oidc.introspection-path` if the provider offers such an endpoint. -In this case you can use the access token as a source of role using `quarkus.oidc.roles.source=accesstoken`. -If no introspection endpoint is present, your next best step is to request <> from the provider as it will at least validate the access token. Use `quarkus.oidc.token.verify-access-token-with-user-info=true`. -You also need to set the `quarkus.oidc.user-info-path` property to a URL endpoint fetching the user info (or at least to an endpoint protected by the access token). -For GitHub, since it does not have an introspection endpoint, we use the last method. +The first way is to call the OAuth2 provider introspection endpoint by configuring `quarkus.oidc.introspection-path`, if the provider offers such an endpoint. +In this case you can use the access token as a source of roles using `quarkus.oidc.roles.source=accesstoken`. +If no introspection endpoint is present, you can attempt instead to request <> from the provider as it will at least validate the access token. +To do so, specify `quarkus.oidc.token.verify-access-token-with-user-info=true`. +You also need to set the `quarkus.oidc.user-info-path` property to a URL endpoint that fetches the user info (or to an endpoint protected by the access token). +For GitHub, since it does not have an introspection endpoint, requesting the UserInfo is required. [NOTE] --- -Requiring <> involves making a remote call on every request - therefore you may want to consider caching `UserInfo` data, see xref:security-oidc-bearer-token-authentication-concept.adoc#token-introspection-userinfo-cache[Token Introspection and UserInfo cache] for more details. +==== +Requiring <> involves making a remote call on every request. +Therefore, you might want to consider caching `UserInfo` data. +For more information, see the xref:security-oidc-bearer-token-authentication-concept.adoc#token-introspection-userinfo-cache[Token Introspection and UserInfo cache] section of the "OpenID Connect (OIDC) Bearer authentication" guide. Alternatively, you may want to request that `UserInfo` is embedded into the internal generated `IdToken` with the `quarkus.oidc.cache-user-info-in-idtoken=true` property - the advantage of this approach is that by default no cached `UserInfo` state will be kept with the endpoint - instead it will be stored in a session cookie. You may also want to consider encrypting `IdToken` in this case if `UserInfo` contains sensitive data. For more information, see <>. --- +==== -OAuth2 servers may not support a well-known configuration endpoint in which case the discovery has to be disabled and the authorization, token, and introspection and/or userinfo endpoint paths have to be configured manually. +OAuth2 servers might not support a well-known configuration endpoint. +In this case, you must disable the discovery and configure the authorization, token, and introspection and the userinfo endpoint paths manually. -This can look a bit daunting but Quarkus simplifies your life for well known OIDC or OAuth2 providers like Apple, Facebook, GitHub, Google, Microsoft, Spotify and Twitter. Use the `quarkus.oidc.provider` property. +For well-known OIDC or OAuth2 providers, like Apple, Facebook, GitHub, Google, Microsoft, Spotify, and Twitter, Quarkus can help significantly simplify your application's configuration with the `quarkus.oidc.provider` property. Here is how you can integrate `quarkus-oidc` with GitHub after you have link:https://docs.github.com/en/developers/apps/building-oauth-apps/creating-an-oauth-app[created a GitHub OAuth application]. Configure your Quarkus endpoint like this: [source,properties] @@ -913,7 +985,7 @@ public class CustomSecurityIdentityAugmentor implements SecurityIdentityAugmento } ---- -Now, the following code will work when the user is signing in into your application with both Google or GitHub: +Now, the following code will work when the user signs into your application by using Google or GitHub: [source,java] ---- @@ -948,14 +1020,17 @@ public class TokenResource { } ---- -Possibly a simpler alternative is to inject both `@IdToken JsonWebToken` and `UserInfo` and use `JsonWebToken` when dealing with the providers returning `IdToken` and `UserInfo` - with the providers which do not return `IdToken`. +Possibly a simpler alternative is to inject both `@IdToken JsonWebToken` and `UserInfo` and use `JsonWebToken` when dealing with the providers returning `IdToken` and `UserInfo` with the providers which do not return `IdToken`. -The last important point is to make sure the callback path you enter in the GitHub OAuth application configuration matches the endpoint path where you'd like the user be redirected to after a successful GitHub authentication and application authorization, in this case it has to be set to `http:localhost:8080/github/userinfo`. +You must ensure that the callback path you enter in the GitHub OAuth application configuration matches the endpoint path where you'd like the user be redirected to after a successful GitHub authentication and application authorization, in this case it has to be set to `http:localhost:8080/github/userinfo`. === Listening to important authentication events -One can register `@ApplicationScoped` bean which will observe important OIDC authentication events. The listener will be updated when a user has logged in for the first time or re-authenticated, as well as when the session has been refreshed. More events may be reported in the future. For example: +You can register the `@ApplicationScoped` bean which will observe important OIDC authentication events. +When a user logs in for the first time, reauthenticates, or refreshes the session, the listener is updated. +In the future, more events might be reported. +For example: [source, java] ---- @@ -980,21 +1055,25 @@ public class SecurityEventListener { === Propagating tokens to downstream services -For information about Authorization Code Flow access token propagation to the downstream services, see the xref:security-openid-connect-client-reference.adoc#token-propagation[Token Propagation] section. +For information about Authorization Code Flow access token propagation to downstream services, see the xref:security-openid-connect-client-reference.adoc#token-propagation[Token Propagation] section. == Integration considerations -Your OIDC backed application integrates in an environment such as calling from a single page application, using well known OIDC providers etc. +Your application secured by OIDC integrates in an environment where it can be called from single-page applications, needs to work with well-known OIDC providers, run behind HTTP Reverse Proxy, require external and internal access, etc. + This section discusses these considerations. === Single-page applications -Check if implementing SPAs the way it is suggested in the xref:security-oidc-bearer-token-authentication-concept.adoc#single-page-applications[Single-page Applications for Service Applications] section can meet your requirements. +You can check if implementing single-page applications (SPAs) the way it is suggested in the xref:security-oidc-bearer-token-authentication-concept.adoc#single-page-applications[Single-page applications] section of the "OpenID Connect (OIDC) Bearer authentication" guide meets your requirements. -If you prefer to use SPA and JavaScript API such as `Fetch` or `XMLHttpRequest`(XHR) with Quarkus web applications, be aware that OpenID Connect Providers may not support CORS for Authorization endpoints where the users are authenticated after a redirect from Quarkus. This will lead to authentication failures if the Quarkus application and the OpenID Connect Provider are hosted on the different HTTP domains/ports. +If you prefer to use SPAs and JavaScript APIs such as `Fetch` or `XMLHttpRequest`(XHR) with Quarkus web applications, be aware that OpenID Connect providers might not support cross-origin resource sharing (CORS) for authorization endpoints where the users are authenticated after a redirect from Quarkus. +This will lead to authentication failures if the Quarkus application and the OpenID Connect provider are hosted on different HTTP domains, ports, or both. -In such cases, set the `quarkus.oidc.authentication.java-script-auto-redirect` property to `false` which will instruct Quarkus to return a `499` status code and `WWW-Authenticate` header with the `OIDC` value. The browser script also needs to be updated to set `X-Requested-With` header with the `JavaScript` value and reload the last requested page in case of `499`, for example: +In such cases, set the `quarkus.oidc.authentication.java-script-auto-redirect` property to `false`, which will instruct Quarkus to return a `499` status code and a `WWW-Authenticate` header with the `OIDC` value. +You must also update the browser script to set the `X-Requested-With` header with the `JavaScript` value and reload the last requested page in case of a `499` status code. +For example: [source,javascript] ---- @@ -1013,13 +1092,14 @@ Future callQuarkusService() async { === Cross-origin resource sharing -If you plan to consume this application from a Single-page application running on a different domain, you will need to configure CORS (Cross-Origin Resource Sharing). For more information, see the xref:http-reference.adoc#cors-filter[HTTP CORS documentation]. +If you plan to consume this application from a single-page application running on a different domain, you need to configure cross-origin resource sharing (CORS). +For more information, see the xref:http-reference.adoc#cors-filter[CORS filter] section of the "HTTP reference" guide. === Calling Cloud provider services ==== Google Cloud -You can have Quarkus OIDC `web-app` applications access **Google Cloud services** such as **BigQuery** on behalf of the currently authenticated users who have enabled OpenID Connect (Authorization Code Flow) permissions to such services in their Google Developer Consoles. +You can have Quarkus OIDC `web-app` applications access **Google Cloud services** such as **BigQuery** on behalf of the currently-authenticated users who have enabled OpenID Connect (Authorization Code Flow) permissions to such services in their Google developer consoles. It is super easy to do with https://github.com/quarkiverse[Quarkiverse] https://github.com/quarkiverse/quarkiverse-google-cloud-services[Google Cloud Services], only add the https://github.com/quarkiverse/quarkiverse-google-cloud-services/releases/latest[latest tag] service dependency, for example: