Move oidc documentation to guides (#31627)

Closes #31329 Signed-off-by: Giuseppe Graziano <g.graziano94@gmail.com>
2026-05-07 23:50:03 -05:00 · 2024-07-30 09:46:14 +02:00
parent d91d6d18d5
commit c3019fb2d3
27 changed files with 122 additions and 148 deletions
@@ -13,13 +13,13 @@ The authentication session usually expires after 30 minutes by default. The exac

 As described in the previous section, a situation can involve a user who is trying to authenticate to the {project_name} server from multiple tabs of a single browser. However, when that user authenticates in one browser tab,
 the other browser tabs will automatically restart the authentication. This authentication occurs due to the small javascript available on the {project_name} login pages. The restart will typically
-authenticate the user in other browser tabs and redirect to clients because there is an SSO session now due to the fact that the user just successfully authenticated in first browser tab. 
+authenticate the user in other browser tabs and redirect to clients because there is an SSO session now due to the fact that the user just successfully authenticated in first browser tab.
 Some rare exceptions exist when a user is not automatically authenticated in other browser tabs, such as for instance when using an OIDC parameter _prompt=login_ or <<_step-up-flow, step-up authentication>>  requesting a stronger
 authentication factor than the currently authenticated factor.

 In some rare cases, it can happen that after authentication in the first browser tab, other browser tabs are not able to restart authentication because the authentication session is already
 expired. In this case, the particular browser tab will redirect the error about the expired authentication session back to the client in a protocol specific way. For more details, see the corresponding sections
-of  link:{adapterguide_link}#_oidc-errors[OIDC documentation] and  link:{adapterguide_link}#_saml-errors[SAML documentation]. When the client application receives such an error, it can immediately resubmit the OIDC/SAML authentication request to {project_name} as
+of  *OIDC documentation* in the link:{securing_apps_link}[securing apps] section and  link:{adapterguide_link}#_saml-errors[SAML documentation]. When the client application receives such an error, it can immediately resubmit the OIDC/SAML authentication request to {project_name} as
 this should usually automatically authenticate the user due to the existing SSO session as described earlier. As a result, the end user is authenticated automatically in all browser tabs.
-The link:{adapterguide_link}#_javascript_adapter[{project_name} Javascript adapter], link:{adapterguide_link}#_saml[{project_name} SAML adapter], and <<_identity_broker, {project_name} Identity provider>>
+The *Keycloak JavaScript adapter* in the link:{securing_apps_link}[securing apps] section, link:{adapterguide_link}#_saml[{project_name} SAML adapter], and <<_identity_broker, {project_name} Identity provider>>
 support to handle this error automatically and retry the authentication to the {project_name} server in such a case.
@@ -16,7 +16,7 @@ An _authentication flow_ is a container of authentications, screens, and actions
 image:images/browser-flow.png[Browser Flow]

 ===== Auth type
-The name of the authentication or the action to execute. If an authentication is indented, it is in a sub-flow. It may or may not be executed, depending on the behavior of its parent. 
+The name of the authentication or the action to execute. If an authentication is indented, it is in a sub-flow. It may or may not be executed, depending on the behavior of its parent.

 . Cookie
 +
@@ -60,12 +60,12 @@ The element does not count to mark a flow as successful.

 ====== Conditional

-This requirement type is only set on sub-flows. 
+This requirement type is only set on sub-flows.

-* A _Conditional_ sub-flow contains executions. These executions must evaluate to logical statements. 
-* If all executions evaluate as _true_, the _Conditional_ sub-flow acts as _Required_. 
+* A _Conditional_ sub-flow contains executions. These executions must evaluate to logical statements.
+* If all executions evaluate as _true_, the _Conditional_ sub-flow acts as _Required_.
 * If any executions evaluate as _false_, the _Conditional_ sub-flow acts as _Disabled_.
-* If you do not set an execution, the _Conditional_ sub-flow acts as _Disabled_. 
+* If you do not set an execution, the _Conditional_ sub-flow acts as _Disabled_.
 * If a flow contains executions and the flow is not set to _Conditional_, {project_name} does not evaluate the executions, and the executions are considered functionally _Disabled_.

 ==== Creating flows
@@ -118,7 +118,7 @@ AMR claim, see https://www.rfc-editor.org/rfc/rfc8176.html[RFC-8176]). When the
 image:images/config-authenticator-reference.png[Configuring an Authenticator Reference Value]

 Two types of executions exist, _automatic executions_ and _interactive executions_. _Automatic executions_ are similar to the *Cookie* execution and will automatically
-perform their action in the flow. _Interactive executions_ halt the flow to get input. Executions executing successfully set their status to _success_.  For a flow to complete, it needs at least one execution with a status of _success_. 
+perform their action in the flow. _Interactive executions_ halt the flow to get input. Executions executing successfully set their status to _success_.  For a flow to complete, it needs at least one execution with a status of _success_.

 You can add sub-flows to top-level flows with the *Add sub-flow* button. The *Add sub-flow* button displays the *Create Execution Flow* page. This page is similar to the *Create Top Level Form* page. The difference is that the *Flow Type* can be *basic* (default) or *form*. The *form* type constructs a sub-flow that generates a form for the user, similar to the built-in *Registration* flow.
 Sub-flows success depends on how their executions evaluate, including their contained sub-flows. See the <<_execution-requirements, execution requirements section>> for an in-depth explanation of how sub-flows work.
@@ -343,7 +343,7 @@ claims= {
 ----

 The {project_name} javascript adapter has support for easy construct of this JSON and sending it in the login request.
-See link:{adapterguide_link_js_adapter}[Javascript adapter documentation] for more details.
+See *Keycloak JavaScript adapter* in the link:{securing_apps_link}[securing apps] section for more details.

 You can also use simpler parameter `acr_values` instead of `claims` parameter to request particular levels as non-essential. This is mentioned
 in the OIDC specification.
@@ -382,7 +382,7 @@ and that level expired, the user is not required to re-authenticate, but `acr` i
 based solely on `long-lived browser cookie` as mentioned in the section 2 of OIDC Core 1.0 specification.

 NOTE: During the first authentication of the user, the first configured subflow with the *Conditional - Level Of Authentication* is always executed (regardless of the requested level) as
-the user does not yet have any level. Therefore, we recommend that the first level subflow contains the minimal required authenticators for user authentication. In addition, ensure that the subflows with different values of *Conditional - Level Of Authentication* are ordered starting with the lowest as shown 
+the user does not yet have any level. Therefore, we recommend that the first level subflow contains the minimal required authenticators for user authentication. In addition, ensure that the subflows with different values of *Conditional - Level Of Authentication* are ordered starting with the lowest as shown
 in the example above. For example, if you configure a subflow with level 2 and then add another subflow with level 1, the level 2 subflow will be always asked during the first authentication, which may
 not be the desired behavior.

@@ -415,7 +415,7 @@ Usually when the user is redirected to the {project_name} from client applicatio
 that realm registration is enabled and the user clicks `Register` on the login screen. Also, if <<enabling-forgot-password,Forget password>> is enabled for the realm, the user can
 click `Forget password` on the login screen, which triggers the `Reset credentials` flow where users can reset credentials after email address confirmation.

-Sometimes it can be useful for the client application to directly redirect the user to the *Registration* screen or to the *Reset credentials* flow. The resulting action will match the action of when the 
+Sometimes it can be useful for the client application to directly redirect the user to the *Registration* screen or to the *Reset credentials* flow. The resulting action will match the action of when the
 user clicks *Register* or *Forget password* on the normal login screen. Automatic redirect to the registration or reset-credentials screen can be done as follows:

 * When the client wants the user to be redirected directly to the registration, the OIDC client should replace the very last snippet from the OIDC login URL path (`/auth`) with `/registrations` . So the full URL
@@ -467,7 +467,7 @@ with password and OTP:

 image:images/authentication-user-session-limits-browser.png[Authentication User Session Limits Browser Flow]

-Regarding `Post Broker login flow`,  you can add the `User Session Limits` as the only authenticator in the authentication flow  as long as you have no other authenticators that you  trigger after authentication with your identity provider.  However, make sure that this flow is configured as `Post Broker Flow` at your identity providers. This requirement exists needed so that 
+Regarding `Post Broker login flow`,  you can add the `User Session Limits` as the only authenticator in the authentication flow  as long as you have no other authenticators that you  trigger after authentication with your identity provider.  However, make sure that this flow is configured as `Post Broker Flow` at your identity providers. This requirement exists needed so that
 the authentication with Identity providers also participates in the session limits.

 NOTE: Currently, the administrator is responsible for maintaining consistency between the different configurations. So make sure that all your flows use same the configuration
@@ -191,7 +191,7 @@ image:images/x509-directgrant-flow-bindings.png[X509 Direct Grant Flow Bindings]
 ===== Example using CURL

 The following example shows how to obtain an access token for a user in the realm `test` with the direct grant flow. The example is using
-link:{adapterguide_link}#_resource_owner_password_credentials_flow[OAuth2 Resource Owner Password Credentials Grant] and the confidential client `resource-owner`:
+*OAuth2 Resource Owner Password Credentials Grant* in the link:{securing_apps_link}[securing apps] section and the confidential client `resource-owner`:

 [source,bash,subs="attributes+"]
 ----
@@ -214,7 +214,7 @@ According to your environment, it might be needed to use more options to CURL co
 * Option `--capath` to include the whole directory containing the certificate authority path
 * Options `--cert-type` or `--key-type` in case you want to use different files than `PEM`

-Please consult the documentation of the `curl` tool for the details if needed. If you are using other tools than `curl`, 
+Please consult the documentation of the `curl` tool for the details if needed. If you are using other tools than `curl`,
 consult the documentation of your tool. However, the setup would be similar.  A need exists to include keystore and truststore as well as client credentials in case you are using a confidential
 client.

@@ -29,7 +29,7 @@ Validation of client configurations::
    the advanced security requirements. In the future, individual client configuration settings may be replaced by Client Policies directly performing required validations.

 Conformance to a required security standards and profiles such as FAPI and OAuth 2.1::
-    The _Global client profiles_ are client profiles pre-configured in {project_name} by default. They are pre-configured to be compliant with standard security profiles like link:{adapterguide_link}#_fapi-support[FAPI] and link:{adapterguide_link}#_oauth21-support[OAuth 2.1],
+    The _Global client profiles_ are client profiles pre-configured in {project_name} by default. They are pre-configured to be compliant with standard security profiles like *FAPI* and *OAuth 2.1*  in the link:{securing_apps_link}[securing apps] section,
    which makes it easy for the administrator to secure their client application to be compliant with the particular security profile. At this moment, {project_name} has global
    profiles for the support of FAPI and OAuth 2.1 specifications. The administrator will just need to configure the client policies to specify which clients should
    be compliant with the FAPI and OAuth 2.1. The administrator can configure client profiles and client policies, so that {project_name} clients can be easily made compliant with various other
@@ -37,7 +37,7 @@ Conformance to a required security standards and profiles such as FAPI and OAuth

 == Protocol

-The client policy concept is independent of any specific protocol. {project_name} currently supports especially client profiles for the link:{adapterguide_link}#_oidc[OpenID Connect (OIDC) protocol], but there is
+The client policy concept is independent of any specific protocol. {project_name} currently supports especially client profiles for the link:{securing_apps_link}[OpenID Connect (OIDC) protocol], but there is
 also a client profile available for the link:{adapterguide_link}#_saml[SAML protocol].

 == Architecture
@@ -80,7 +80,7 @@ Client Role::
    Applies for clients with the client role of the specified name. Typically you can create a client role of specified name to requested clients and use it as a "marker role" to make
    sure that specified client policy will be applied for requested clients.

-NOTE: A use-case often exists for requiring the application of a particular client policy for the specified clients such as `my-client-1` and `my-client-2`. The best way to achieve this result 
+NOTE: A use-case often exists for requiring the application of a particular client policy for the specified clients such as `my-client-1` and `my-client-2`. The best way to achieve this result
 is to use a *Client Role* condition in your policy and then a create client role of specified name to requested clients. This client role can be used as a "marker role" used solely
 for marking that particular client policy for particular clients.

@@ -144,7 +144,7 @@ One of several purposes for this executor is to realize the security requirement

 A profile consists of several executors, which can realize a security profile like FAPI and OAuth 2.1. Profile can be configured by the Admin REST API (Admin Console) together with its executors.
 Three _global profiles_ exist and they are configured in {project_name} by default with pre-configured executors compliant with the FAPI 1 Baseline, FAPI 1 Advanced, FAPI CIBA, FAPI 2 and OAuth 2.1 specifications.
-More details exist in the FAPI and OAuth 2.1 section of the link:{adapterguide_link}#_fapi-support[{adapterguide_name}].
+More details exist in the *FAPI* and *OAuth 2.1*  in the link:{securing_apps_link}[securing apps] section.

 [[_client_policy_policy]]
 === Policy
@@ -91,4 +91,4 @@ Using a lightweight access token in {project_name}::
  By applying `use-lightweight-access-token` executor of <<_client_policies, client policies>> to a client, the client can receive a lightweight access token instead of an access token. The lightweight access token contains a claim controlled by a protocol mapper where its setting `Add to lightweight access token`(default OFF) is turned ON. Also, by turning ON its setting `Add to token introspection` of the protocol mapper, the client can obtain the claim by sending the access token to {project_name}'s token introspection endpoint.

 Introspection endpoint::
-  In some cases, it might be useful to trigger the token introspection endpoint with the HTTP header `Accept: application/jwt` instead of `Accept: application/json`, which can be useful especially for lightweight access tokens. See the details in the link:{adapterguide_link}#_token_introspection_endpoint[Token Introspection endpoint] section.
+  In some cases, it might be useful to trigger the token introspection endpoint with the HTTP header `Accept: application/jwt` instead of `Accept: application/json`, which can be useful especially for lightweight access tokens. See the details of *Token Introspection endpoint* in the link:{securing_apps_link}[securing apps] section.
@@ -9,7 +9,7 @@ In the environment where trust among services is low, you may encounter this sce

 . A frontend client application requires authentication against {project_name}.

-. {project_name} authenticates a user. 
+. {project_name} authenticates a user.

 . {project_name} issues a token to the application.

@@ -27,11 +27,11 @@ To prevent any misuse of the access token, limit the audience on the token and c

 . A frontend application authenticates against {project_name}.

-. {project_name} authenticates a user. 
+. {project_name} authenticates a user.

 . {project_name} issues a token to the application. The application knows that it will need to invoke an untrusted service so it places *scope=<untrusted service>* in the authentication request sent to {project_name} (see <<_client_scopes, Client Scopes section>> for more details about the _scope_ parameter).
 +
-The token issued to the application contains a reference to the untrusted service in its audience (*"audience": [ "<untrusted service>" ]*) which declares that the client uses this access token to invoke the untrusted service. 
+The token issued to the application contains a reference to the untrusted service in its audience (*"audience": [ "<untrusted service>" ]*) which declares that the client uses this access token to invoke the untrusted service.
 +
 .The untrusted service serves the request to the client application but also keeps the token.

@@ -70,7 +70,7 @@ you can use the access token issued for the confidential client to invoke the se

 [NOTE]
 ====
-If you want to ensure that the audience is not added automatically, do not configure role scope mappings directly on the confidential client. Instead, you can create a dedicated client scope that contains the role scope mappings for the client roles of your dedicated client scope. 
+If you want to ensure that the audience is not added automatically, do not configure role scope mappings directly on the confidential client. Instead, you can create a dedicated client scope that contains the role scope mappings for the client roles of your dedicated client scope.

 Assuming that the client scope is added as an optional client scope to the confidential client, the client roles and the audience will be added to the token if explicitly requested by the *scope=<trusted service>*  parameter.
 ====
@@ -103,16 +103,16 @@ image:images/audience_mapper.png[]
 On the confidential client:
 +
 . Click the _Client Scopes_ tab.
-. Assign *good-service* as an optional (or default) client scope. 
+. Assign *good-service* as an optional (or default) client scope.
 +
 See <<_client_scopes_linking, Client Scopes Linking section>> for more details.

 * You can optionally <<_client_scopes_evaluate, Evaluate Client Scopes>> and generate an example access token. *good-service* will be added to the audience of the generated access token if *good-service* is included in the _scope_ parameter, when you assigned it as an optional client scope.

-* In your confidential client application, ensure that the _scope_ parameter is used. The value *good-service* must be included when you want to issue the token for accessing *good-service*. 
+* In your confidential client application, ensure that the _scope_ parameter is used. The value *good-service* must be included when you want to issue the token for accessing *good-service*.
 +
 See:
 +
-** link:{adapterguide_link}#_javascript_adapter[javascript adapter section] if your application uses the javascript adapter.
+** *Keycloak JavaScript adapter* in the link:{securing_apps_link}[securing apps] section if your application uses the javascript adapter.

 NOTE: Both the _Audience_ and _Audience Resolve_ protocol mappers add the audiences to the access token only, by default. The ID Token typically contains only a single audience, the client ID for which the token was issued, a requirement of the OpenID Connect specification. However, the access token does not necessarily have the client ID, which was the token issued for, unless the audience mappers added it.
@@ -5,8 +5,8 @@ The *Mappers* tab contains the protocol mappers and the *Scope* tab contains the

 .Procedure
 . Click the *Client Scopes* tab for the client.
-. Open the sub-tab *Evaluate*. 
-. Select the optional client scopes that you want to apply. 
+. Open the sub-tab *Evaluate*.
+. Select the optional client scopes that you want to apply.

 This will also show you the value of the *scope* parameter. This parameter needs to be sent from the application to the {project_name} OpenID Connect authorization endpoint.

@@ -15,7 +15,7 @@ image:images/client-scopes-evaluate.png[]

 [NOTE]
 ====
-To send a custom value for a *scope* parameter from your application, see the link:{adapterguide_link_latest}#_javascript_adapter[javascript adapter section], for javascript adapters.
+To send a custom value for a *scope* parameter from your application, see the *Keycloak JavaScript adapter* in the link:{securing_apps_link}[securing apps] section, for javascript adapters.
 ====

-All examples are generated for the particular user and issued for the particular client, with the specified value of the *scope* parameter. The examples include all of the claims and role mappings used.
+All examples are generated for the particular user and issued for the particular client, with the specified value of the *scope* parameter. The examples include all of the claims and role mappings used.
@@ -20,7 +20,7 @@ to exchange the code for an _identity_ and _access_ and _refresh_ token.  To pre

 [NOTE]
 ====
-A system is vulnerable to a stolen token for the lifetime of that token. For security and scalability reasons, access tokens are generally set to expire quickly so subsequent token requests fail. If a token expires, an application can obtain a new access token using the additional _refresh_ token sent by the login protocol. 
+A system is vulnerable to a stolen token for the lifetime of that token. For security and scalability reasons, access tokens are generally set to expire quickly so subsequent token requests fail. If a token expires, an application can obtain a new access token using the additional _refresh_ token sent by the login protocol.
 ====

 [[_confidential-clients]]
@@ -33,13 +33,13 @@ _Public_ clients are secure when HTTPS is strictly enforced and redirect URIs re

 ===== Implicit Flow

-The Implicit Flow is a browser-based protocol. It is similar to the Authorization Code Flow but with fewer requests and no refresh tokens. 
+The Implicit Flow is a browser-based protocol. It is similar to the Authorization Code Flow but with fewer requests and no refresh tokens.

 [NOTE]
 ====
 The possibility exists of _access_ tokens leaking in the browser history when tokens are transmitted via redirect URIs (see below).

-Also, this flow does not provide clients with refresh tokens. Therefore, access tokens have to be long-lived or users  have to re-authenticate when they expire.  
+Also, this flow does not provide clients with refresh tokens. Therefore, access tokens have to be long-lived or users  have to re-authenticate when they expire.

 We do not advise using this flow. This flow is supported because it is in the OIDC and OAuth 2.0 specification.
 ====
@@ -89,7 +89,7 @@ It is possible to specify that the refresh token is considered invalid once it i
 which were already used, would not be considered valid anymore by {project_name}. This is possible to set with the use of _Revoke Refresh token_ option as specified in the <<_timeouts,timeouts section>>.

 {project_name} also supports the situation that no refresh token rotation exists. In this case, a refresh token is returned during login, but subsequent responses from refresh-token requests will not
-return new refresh tokens. This practice is recommended for instance in the link:{adapterguide_link}#_fapi-support[FAPI 2 draft specification].
+return new refresh tokens. This practice is recommended for instance in the *FAPI 2 draft specification* in the link:{securing_apps_link}[securing apps] section.
 In {project_name}, it is possible to skip refresh token rotation with the use of <<_client_policies,client policies>>. You can add executor `suppress-refresh-token-rotation` to some client
 profile and configure client policy to specify for which clients would be the profile triggered, which means that for those clients the refresh token rotation is going to be skipped.

@@ -107,11 +107,11 @@ This is used by clients running on internet-connected devices that have limited
 This feature is used by clients who want to initiate the authentication flow by communicating with the OpenID Provider directly without redirect through the user's browser like OAuth 2.0's authorization code grant. Here's a brief summary of the protocol:

 . The client requests {project_name} an auth_req_id that identifies the authentication request made by the client. {project_name} creates the auth_req_id.
-. After receiving this auth_req_id, this client repeatedly needs to poll {project_name} to obtain an Access Token, Refresh Token and ID Token from {project_name} in return for the auth_req_id until the user is authenticated. 
+. After receiving this auth_req_id, this client repeatedly needs to poll {project_name} to obtain an Access Token, Refresh Token and ID Token from {project_name} in return for the auth_req_id until the user is authenticated.

 An administrator can configure Client Initiated Backchannel Authentication (CIBA) related operations as `CIBA Policy` per realm.

-Also please refer to other places of {project_name} documentation like link:{adapterguide_link}#_backchannel_authentication_endpoint[Backchannel Authentication Endpoint section] of {adapterguide_name} and link:{adapterguide_link}#_client_initiated_backchannel_authentication_grant[Client Initiated Backchannel Authentication Grant section] of {adapterguide_name}.
+Also please refer to other places of {project_name} documentation like *Backchannel Authentication Endpoint* and *Client Initiated Backchannel Authentication Grant* in the link:{securing_apps_link}[securing apps] section.

 ====== CIBA Policy

@@ -177,10 +177,10 @@ Authentication Channel Provider is provided as SPI provider so that users of {pr

 If a user of {project_name} user want to use the HTTP Authentication Channel Provider, they need to know its contract between {project_name} and the authentication entity consisting of the following two parts.

-Authentication Delegation Request/Response:: 
+Authentication Delegation Request/Response::
 {project_name} sends an authentication request to the authentication entity.

-Authentication Result Notification/ACK:: 
+Authentication Result Notification/ACK::
 The authentication entity notifies the result of the authentication to {project_name}.

 Authentication Delegation Request/Response consists of the following messaging.
@@ -109,11 +109,11 @@ This is used by clients running on internet-connected devices that have limited
 This is used by clients who want to initiate the authentication flow by communicating with the OpenID Provider directly without redirect through the user's browser like OAuth 2.0's authorization code grant. Here's a brief summary of the protocol:

 . The client requests {project_name} an auth_req_id that identifies the authentication request made by the client. {project_name} creates the auth_req_id.
-. After receiving this auth_req_id, this client repeatedly needs to poll {project_name} to obtain an Access Token, Refresh Token and ID Token from {project_name} in return for the auth_req_id until the user is authenticated. 
+. After receiving this auth_req_id, this client repeatedly needs to poll {project_name} to obtain an Access Token, Refresh Token and ID Token from {project_name} in return for the auth_req_id until the user is authenticated.

 An administrator can configure Client Initiated Backchannel Authentication (CIBA) related operations as `CIBA Policy` per realm.

-Also please refer to other places of {project_name} documentation like link:{adapterguide_link}#_backchannel_authentication_endpoint[Backchannel Authentication Endpoint section] of {adapterguide_name} and link:{adapterguide_link}#_client_initiated_backchannel_authentication_grant[Client Initiated Backchannel Authentication Grant section] of {adapterguide_name}.
+Also please refer to other places of {project_name} documentation like *Backchannel Authentication Endpoint* and *Client Initiated Backchannel Authentication Grant* in the link:{securing_apps_link}[securing apps] section.

 ====== CIBA Policy

@@ -180,10 +180,10 @@ Authentication Channel Provider is provided as SPI provider so that users of {pr

 If a user of {project_name} user want to use the HTTP Authentication Channel Provider, they need to know its contract between {project_name} and the authentication entity consisting of the following two parts.

-Authentication Delegation Request/Response:: 
+Authentication Delegation Request/Response::
 {project_name} sends an authentication request to the authentication entity.

-Authentication Result Notification/ACK:: 
+Authentication Result Notification/ACK::
 The authentication entity notifies the result of the authentication to {project_name}.

 Authentication Delegation Request/Response consists of the following messaging.
@@ -2,6 +2,6 @@
 === FAPI compliance

 To make sure that {project_name} server will validate your client to be more secure and FAPI compliant, you can configure client policies
-for the FAPI support. Details are described in the FAPI section of link:{adapterguide_link}#_fapi-support[{adapterguide_name}]. Among other things, this ensures some security best practices
+for the FAPI support. *FAPI* details are described in the link:{securing_apps_link}[securing apps] section. Among other things, this ensures some security best practices
 described above like SSL required for clients, secure redirect URI used and more of similar best practices.

@@ -2,4 +2,4 @@
 === OAuth 2.1 compliance

 To make sure that {project_name} server will validate your client to be more secure and OAuth 2.1 compliant, you can configure client policies
-for the OAuth 2.1 support. Details are described in the OAuth 2.1 section of link:{adapterguide_link}#_oauth21-support[{adapterguide_name}].
+for the OAuth 2.1 support. *OAuth 2.1* details are described in the link:{securing_apps_link}[securing apps] section.