diff --git a/docs/src/main/asciidoc/security-authentication-mechanisms.adoc b/docs/src/main/asciidoc/security-authentication-mechanisms.adoc index ead7ae4238a0e..df72bd312e02d 100644 --- a/docs/src/main/asciidoc/security-authentication-mechanisms.adoc +++ b/docs/src/main/asciidoc/security-authentication-mechanisms.adoc @@ -48,7 +48,10 @@ ifndef::no-webauthn-authentication[] |WebAuthn |xref:security-webauthn.adoc[WebAuthn] endif::no-webauthn-authentication[] +ifndef::no-quarkus-kerberos[] |Kerberos ticket |link:https://quarkiverse.github.io/quarkiverse-docs/quarkus-kerberos/dev/index.html[Kerberos] +endif::no-quarkus-kerberos[] + |==== For more information, see the following <> table. diff --git a/docs/src/main/asciidoc/security-oidc-bearer-token-authentication-tutorial.adoc b/docs/src/main/asciidoc/security-oidc-bearer-token-authentication-tutorial.adoc index 67717da4065b1..fc7725b33d0e8 100644 --- a/docs/src/main/asciidoc/security-oidc-bearer-token-authentication-tutorial.adoc +++ b/docs/src/main/asciidoc/security-oidc-bearer-token-authentication-tutorial.adoc @@ -190,7 +190,7 @@ Where: * `%prod.quarkus.oidc.auth-server-url` sets the base URL of the OpenID Connect (OIDC) server. The `%prod.` profile prefix ensures that `Dev Services for Keycloak` launches a container when you run the application in development (dev) mode. -For more information, see the <> section. +For more information, see the <> section. * `quarkus.oidc.client-id` sets a client id that identifies the application. * `quarkus.oidc.credentials.secret` sets the client secret, which is used by the `client_secret_basic` authentication method. @@ -206,7 +206,7 @@ You do not need to do this if you have already built a link:{quickstarts-tree-ur [NOTE] ==== Do not start the Keycloak server when you run the application in dev mode; `Dev Services for Keycloak` will start a container. -For more information, see the <> section. +For more information, see the <> section. ==== + . To start a Keycloak server, you can use Docker to run the following command: @@ -238,7 +238,7 @@ endif::no-quarkus-keycloak-admin-client[] -[[keycloak-dev-mode]] +[[keycloak-dev-mode-a]] == Run the application in dev mode . To run the application in dev mode, run the following commands: @@ -301,7 +301,7 @@ include::{includes}/devtools/build-native.adoc[] == Test the application -For information about testing your application in dev mode, see the preceding <> section. +For information about testing your application in dev mode, see the preceding <> section. You can test the application launched in JVM or native modes with `curl`. diff --git a/docs/src/main/asciidoc/security-oidc-bearer-token-authentication.adoc b/docs/src/main/asciidoc/security-oidc-bearer-token-authentication.adoc index 0e3650ea89011..f725dac834196 100644 --- a/docs/src/main/asciidoc/security-oidc-bearer-token-authentication.adoc +++ b/docs/src/main/asciidoc/security-oidc-bearer-token-authentication.adoc @@ -88,20 +88,20 @@ Injection of `JsonWebToken` is supported in `@ApplicationScoped`, `@Singleton`, However, the use of `@RequestScoped` is required if the individual claims are injected as simple types. For more information, see the xref:security-jwt.adoc#supported-injection-scopes[Supported injection scopes] section of the Quarkus "Using JWT RBAC" guide. -[[user-info]] +[[user-info-a]] === `UserInfo` If you must request a UserInfo JSON object from the OIDC `UserInfo` endpoint, set `quarkus.oidc.authentication.user-info-required=true`. A request is sent to the OIDC provider `UserInfo` endpoint, and an `io.quarkus.oidc.UserInfo` (a simple `javax.json.JsonObject` wrapper) object is created. `io.quarkus.oidc.UserInfo` can be injected or accessed as a `SecurityIdentity` `userinfo` attribute. -`quarkus.oidc.authentication.user-info-required` is automatically enabled if one of these conditions is met: +`quarkus.oidc.authentication.user-info-required` is automatically enabled if one of these conditions is met: - if `quarkus.oidc.roles.source` is set to `userinfo` or `quarkus.oidc.token.verify-access-token-with-user-info` is set to `true` or `quarkus.oidc.authentication.id-token-required` is set to `false`, the current OIDC tenant must support a UserInfo endpoint in these cases. - if `io.quarkus.oidc.UserInfo` injection point is detected but only if the current OIDC tenant supports a UserInfo endpoint. -[[config-metadata]] +[[config-metadata-a]] === Configuration metadata 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 injected or accessed as a `SecurityIdentity` `configuration-metadata` attribute. @@ -207,7 +207,7 @@ public class ProtectedResource { For more information about the `io.quarkus.security.PermissionsAllowed` annotation, see the xref:security-authorize-web-endpoints-reference.adoc#permission-annotation[Permission annotation] section of the "Authorization of web endpoints" guide. -[[token-verification-introspection]] +[[token-verification-introspection-a]] === Token verification and introspection If the token is a JWT token, then, by default, it is verified with a `JsonWebKey` (JWK) key from a local `JsonWebKeySet`, retrieved from the OIDC provider's JWK endpoint. diff --git a/docs/src/main/asciidoc/security-oidc-code-flow-authentication.adoc b/docs/src/main/asciidoc/security-oidc-code-flow-authentication.adoc index 7a2ebc6cd5a4e..d5641c2295bde 100644 --- a/docs/src/main/asciidoc/security-oidc-code-flow-authentication.adoc +++ b/docs/src/main/asciidoc/security-oidc-code-flow-authentication.adoc @@ -640,7 +640,7 @@ Injection of the `JsonWebToken` and `AccessTokenCredential` is supported in both Quarkus OIDC uses the refresh token to refresh the current ID and access tokens as part of its <> process. -[[user-info]] +[[user-info-b]] ==== User info If the ID token does not provide enough information about the currently authenticated user, you can get more information from the `UserInfo` endpoint. @@ -655,7 +655,7 @@ A request is sent to the OIDC provider `UserInfo` endpoint by using the access t - if `io.quarkus.oidc.UserInfo` injection point is detected but only if the current OIDC tenant supports a UserInfo endpoint. -[[config-metadata]] +[[config-metadata-b]] ==== 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 injected or accessed as a `SecurityIdentity` `configuration-metadata` attribute. @@ -689,11 +689,11 @@ You can also map `SecurityIdentity` roles created from token claims to deploymen A core part of the authentication process is ensuring the chain of trust and validity of the information. This is done by ensuring tokens can be trusted. -[[token-verification-introspection]] +[[token-verification-introspection-b]] ==== Token verification and introspection The verification process of OIDC authorization code flow tokens follows the Bearer token authentication token verification and introspection logic. -For more information, see the xref:security-oidc-bearer-token-authentication.adoc#token-verification-introspection[Token verification and introspection] section of the "Quarkus OpenID Connect (OIDC) Bearer token authentication" guide. +For more information, see the xref:security-oidc-bearer-token-authentication.adoc#token-verification-introspection-a[Token verification and introspection] section of the "Quarkus OpenID Connect (OIDC) Bearer token authentication" guide. [NOTE] ==== @@ -1276,7 +1276,7 @@ This `access` token represents an authenticated user authorizing the current Qua 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 approach is similar to the OIDC <> approach, with `UserInfo` fetched by Quarkus OIDC 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 allows the Quarkus endpoint to request a GitHub profile for the current user. @@ -1298,14 +1298,14 @@ This simplifies how you handle an application that supports multiple OIDC provid 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 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. +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. +Requiring <> involves making a remote call on every request. Therefore, `UserInfo` is embedded in the internal generated `IdToken` and saved in the encrypted session cookie. It can be disabled with `quarkus.oidc.cache-user-info-in-idtoken=false`. diff --git a/docs/src/main/asciidoc/security-openid-connect-client.adoc b/docs/src/main/asciidoc/security-openid-connect-client.adoc index ef1c2287d3694..d56b4cdb87908 100644 --- a/docs/src/main/asciidoc/security-openid-connect-client.adoc +++ b/docs/src/main/asciidoc/security-openid-connect-client.adoc @@ -535,12 +535,12 @@ The preceding configuration references Keycloak, which is used by `ProtectedReso Both REST clients point to `ProtectedResource`'s HTTP address. NOTE: Adding a `%prod.` profile prefix to `quarkus.oidc.auth-server-url` ensures that `Dev Services for Keycloak` launches a container for you when the application is run in dev or test modes. -For more information, see the <> section. +For more information, see the <> section. == Starting and configuring the Keycloak server NOTE: Do not start the Keycloak server when you run the application in dev or test modes; `Dev Services for Keycloak` launches a container. -For more information, see the <> section. +For more information, see the <> section. Ensure you put the link:{quickstarts-tree-url}/security-openid-connect-client-quickstart/config/quarkus-realm.json[realm configuration file] on the classpath, in the `target/classes` directory. This placement ensures that the file is automatically imported in dev mode. However, if you have already built a link:{quickstarts-tree-url}/security-openid-connect-quickstart[complete solution], you do not need to add the realm file to the classpath because the build process has already done so. @@ -566,7 +566,7 @@ This `quarkus` realm file adds a `frontend` client, and `alice` and `admin` user `alice` has a `user` role. `admin` has both `user` and `admin` roles. -[[keycloak-dev-mode]] +[[keycloak-dev-mode-b]] == Running the application in dev mode To run the application in a dev mode, use: @@ -627,7 +627,7 @@ After a little while, when the build finishes, you can run the native binary dir == Testing the application -For more information about testing your application in dev mode, see the preceding <> section. +For more information about testing your application in dev mode, see the preceding <> section. You can test the application launched in JVM or Native modes with `curl`.