From 236ce1eb037caf66e38788b1ff15c12d77cff383 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Mon, 23 Oct 2023 15:16:31 +0000 Subject: [PATCH] Script updating gh-pages from 5d2a4cd. [ci skip] --- draft-ietf-oauth-browser-based-apps.html | 54 +++++------ draft-ietf-oauth-browser-based-apps.txt | 117 ++++++++++++----------- 2 files changed, 87 insertions(+), 84 deletions(-) diff --git a/draft-ietf-oauth-browser-based-apps.html b/draft-ietf-oauth-browser-based-apps.html index 8551d15..48f3982 100644 --- a/draft-ietf-oauth-browser-based-apps.html +++ b/draft-ietf-oauth-browser-based-apps.html @@ -1032,7 +1032,7 @@ Parecki, et al. -Expires 21 April 2024 +Expires 25 April 2024 [Page] @@ -1045,12 +1045,12 @@
draft-ietf-oauth-browser-based-apps-latest
Published:
- +
Intended Status:
Best Current Practice
Expires:
-
+
Authors:
@@ -1104,7 +1104,7 @@

time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

- This Internet-Draft will expire on 21 April 2024.

+ This Internet-Draft will expire on 25 April 2024.

@@ -1660,8 +1660,8 @@
-

The BFF relies on traditional browser cookies to keep track of the user's session, which is used to access the user's tokens. Cookie-based sessions, both server-side and client-side, are often thought of as problematic.

-

Server-side sessions only expose a session identifier and keep all data on the server. Doing so ensures a great level of control over active sessions, along with the possibility to revoke any session at will. The downside of this approach is the impact on scalability, requiring solutions such as sticky sessions, or session replication. Given these downsides, using server-side sessions with a BFF is only recommended in small-scale scenarios.

+

The BFF relies on traditional browser cookies to keep track of the user's session, which is used to access the user's tokens. Cookie-based sessions, both server-side and client-side, have some downsides.

+

Server-side sessions only expose a session identifier and keep all data on the server. Doing so ensures a great level of control over active sessions, along with the possibility to revoke any session at will. The downside of this approach is the impact on scalability, requiring solutions such as "sticky sessions", or "session replication". Given these downsides, using server-side sessions with a BFF is only recommended in small-scale scenarios.

Client-side sessions push all data to the browser in a signed, and optionally encrypted, object. This pattern absolves the server of keeping track of any session data, but severely limits control over active sessions and makes it difficult to handle session revocation. However, when client-side sessions are used in the context of a BFF, these properties change significantly. Since the cookie-based session is only used to obtain a user's tokens, all control and revocation properties follow from the use of access tokens and refresh tokens. It suffices to revoke the user's access token and/or refresh token to prevent ongoing access to protected resources, without the need to explicitly invalidate the cookie-based session.

Best practices to secure the session cookie are discussed in section Section 6.1.3.2.

@@ -1671,7 +1671,7 @@
6.1.2.3. Combining OAuth and OpenID Connect
-

The OAuth flow used by this application architecture can be combined with OpenID Connect by including the proper scopes in the authorization request (C). In that case, the BFF will receive an ID Token in step F. The BFF can associate the information from the ID Token with the user's session and provide it to the JavaScript application in step B or I.

+

The OAuth flow used by this application architecture can be combined with OpenID Connect by including the necessary OpenID Connect scopes in the authorization request (C). In that case, the BFF will receive an ID Token in step F. The BFF can associate the information from the ID Token with the user's session and provide it to the JavaScript application in step B or I.

When needed, the BFF can use the access token associated with the user's session to make requests to the UserInfo endpoint.

@@ -1753,12 +1753,12 @@
6.1.3.3.2. Cross-Origin Resource Sharing (CORS)

The BFF can rely on CORS as a CSRF defense mechanism. CORS is a security mechanism implemented by browsers that restricts cross-origin JavaScript-based requests, unless the server explicitly approves such a request by setting the proper CORS headers.

-

CORS is designed in such a way that every JavaScript-based request that does not mimic a legacy browser interaction, such as a navigation or image load, requires approval by the server through a preflight. Unless the preflight response explicitly approves the request, the browser will refuse to send it.

+

Browsers typically restrict cross-origin HTTP requests initiated from scripts. CORS can remove this restriction if the target server approves the request, which is checked through an initial "preflight" request. Unless the preflight response explicitly approves the request, the browser will refuse to send the full request.

Because of this property, the BFF can rely on CORS as a CSRF defense. When the attacker tries to launch a cross-origin request to the BFF from the user's browser, the BFF will not approve the request in the preflight response, causing the browser to block the actual request. Note that the attacker can always launch the request from their own machine, but then the request will not carry the user's cookies, so the attack will fail.

When relying on CORS as a CSRF defense, it is important to realize that certain requests are possible without a preflight. For such requests, named "Simple Requests" in CORS terminology, the browser will simply send the request and prevent access to the response if the server did not send the proper CORS headers. This behavior is enforced for requests that can be triggered via other means than JavaScript, such as a GET request or a form-based POST request.

The consequence of this behavior is that certain endpoints of the resource server could become vulnerable to CSRF, even with CORS enabled as a defense. For example, if the resource server is an API that exposes an endpoint to a body-less POST request, there will be no preflight request and no CSRF defense.

To avoid such bypasses against the CORS policy, the BFF SHOULD require that every request includes a custom request header. Cross-origin requests with a custom request header always require a preflight, which makes CORS an effective CSRF defense. Implementing this mechanism is as simple as requiring every request to have a static request header, such as X-CORS-Security: 1.

-

Finally, note that the JavaScript application is often deployed on the same-origin as the BFF. This ensures that legitimate interactions between the frontend and the BFF do not require any preflights, so there's no additional overhead.

+

It is also possible to deploy the JavaScript application on the same origin as the BFF. This ensures that legitimate interactions between the frontend and the BFF do not require any preflights, so there's no additional overhead.

@@ -1768,7 +1768,7 @@
6.1.3.4. Advanced Security
-

All OAuth responsibilities have been moved to the BFF, a server-side component acting as a confidential client. Since server-side applications are more powerful than browser-based applications, it becomes easier to adopt advanced OAuth security practices. Examples include key-based client authentication and sender-constrained tokens.

+

In the BFF pattern, all OAuth responsibilities have been moved to the BFF, a server-side component acting as a confidential client. Since server-side applications are more powerful than browser-based applications, it becomes easier to adopt advanced OAuth security practices. Examples include key-based client authentication and sender-constrained tokens.

@@ -1905,7 +1905,7 @@
6.2.2.1. Refresh Tokens

It is recommended to use both access tokens and refresh tokens, as it enables access tokens to be short-lived and minimally scoped (e.g., using [RFC8707]). When using refresh tokens, the token-mediating backend obtains the refresh token in step F and associates it with the user's session.

-

If the JavaScript application notices that the user's access token has expired, it can contact the token-mediating backend to request a fresh access token. The token-mediating backend relies on the cookies associated with this request to obtain the user's refresh token and run a Refresh Token flow. These steps are not shown in the diagram. Note that this Refresh Token flow involves a confidential client, thus requires client authentication.

+

If the JavaScript application notices that the user's access token has expired, it can contact the token-mediating backend to request a fresh access token. The token-mediating backend relies on the cookies associated with this request to use the user's refresh token to run a Refresh Token flow. These steps are not shown in the diagram. Note that this Refresh Token flow involves a confidential client, thus requires client authentication.

When the refresh token expires, there is no way to recover without running an entirely new Authorization Code flow. Therefore, it is recommended to configure the lifetime of the cookie-based session to be equal to the maximum lifetime of the refresh token. Additionally, when the token-mediating backend learns that a refresh token for an active session is no longer valid, it is recommended to invalidate the session.

@@ -1916,7 +1916,7 @@

Depending on the resource servers being accessed and the configuration of scopes at the authorization server, the JavaScript application may wish to request access tokens with different scope configurations. This behavior would allow the JavaScript application to follow the best practice of using minimally-scoped access tokens.

The JavaScript application can inform the token-mediating backend of the desired scopes when it checks for the active session (Step A/I). It is up to the token-mediating backend to decide if previously obtained access tokens fall within the desired scope criteria.

-

It should be noted that this access token caching mechanism at the token-mediating backend can cause scope elevation risks when applied indiscriminately. If the cached access token features a superset of the scopes requested by the frontend, the token-mediating backend SHOULD NOT return it to the frontend; instead it SHOULD use the refresh token to request an access token with the smaller set of scopes from the authorization server. Note that support of such an access token downscoping mechanism is at the discretion of the authorization server.

+

It should be noted that this access token caching mechanism at the token-mediating backend can cause scope elevation risks when applied indiscriminately. If the cached access token features a superset of the scopes requested by the frontend, the token-mediating backend SHOULD NOT return it to the frontend; instead it SHOULD use the refresh token to request an access token with the smaller set of scopes from the authorization server. Note that support of such an access token downscoping mechanism is at the discretion of the authorization server.

The token-mediating backend can use a similar mechanism to downscoping when relying on [RFC8707] to obtain access token for a specific resource server.

@@ -1941,7 +1941,7 @@
6.2.2.5. Practical Deployment Scenarios
-

Serving the static JavaScript code is a separate responsibility from handling interactions with the authorization server. In the diagram presented above, the token-mediating backend and static web host are shown as two separate entities. In real-world deployment scenarios, these components can be deployed as a single service (i.e., the token-mediating backend serving the static JS code), as two separate services (i.e., a CDN and a token-mediating backend), or as two components in a single service (i.e., static hosting and serverless functions on a cloud platform).

+

Serving the static JavaScript code is a separate responsibility from handling interactions with the authorization server. In the diagram presented above, the token-mediating backend and static web host are shown as two separate entities. In real-world deployment scenarios, these components can be deployed as a single service (i.e., the token-mediating backend serving the static JS code), as two separate services (i.e., a CDN and a token-mediating backend), or as two components in a single service (i.e., static hosting and serverless functions on a cloud platform). These deployment differences do not affect the relationships described in this pattern.

@@ -2059,7 +2059,7 @@
6.2.4.3.1. Secure Token Storage
-

Given the nature of the token-mediating backend pattern, there is no need for persistent token storage in the browser. When needed ,the application can always use its cookie-based session to obtain an access token from the token-mediating backend. Section Section 8 provides more details on the security properties of various storage mechanisms in the browser.

+

Given the nature of the token-mediating backend pattern, there is no need for persistent token storage in the browser. When needed, the application can always use its cookie-based session to obtain an access token from the token-mediating backend. Section Section 8 provides more details on the security properties of various storage mechanisms in the browser.

Note that even when the access token is stored out of reach of malicious JavaScript code, the attacker still has the ability to request the access token from the token-mediating backend.

@@ -2159,7 +2159,7 @@

ensuring the authorization server supports PKCE, or

  • -

    by using the OAuth 2.0 "state" parameter or the OpenID Connect "nonce" parameter to carry one-time use CSRF tokens

    +

    by using the OAuth 2.0 state parameter or the OpenID Connect nonce parameter to carry one-time use CSRF tokens

    • @@ -2237,7 +2237,7 @@
    user may inspect their copy and learn the shared secret. For this reason, and those stated in Section 5.3.1 of [RFC6819], it is NOT RECOMMENDED for authorization servers to require client authentication of browser-based -applications using a shared secret, as this serves little value beyond +applications using a shared secret, as this serves no value beyond client identification which is already provided by the client_id parameter.

    Authorization servers that still require a statically included shared secret for SPA clients MUST treat the client as a public @@ -2413,7 +2413,7 @@

    When handling tokens directly, the application can choose different storage mechanisms to handle access tokens and refresh tokens. Universally accessible storage areas, such as Local Storage, are easier to access from malicious JavaScript than highly isolated storage areas, such as a Web Worker. Section Section 8 discusses different storage mechanisms with their trade-off in more detail.

    A practical implementation pattern can use a Web Worker to isolate the refresh token, and provide the application with the access token making requests to resource servers.

    -

    Note that even the perfect token storage mechanism does not prevent the attacker from running a new flow to obtain a fresh set of tokens (See Section 5.1.3).

    +

    Note that even a perfect token storage mechanism does not prevent the attacker from running a new flow to obtain a fresh set of tokens (See Section 5.1.3).

    @@ -2421,8 +2421,8 @@
    6.3.3.2.2. Using Sender-Constrained Tokens
    -

    Browser-based OAuth 2.0 clients can implement [DPoP] to transition from bearer access tokens and bearer refresh tokens to sender-constrained tokens. In such an implementation, the private key used to sign DPoP proofs is handled by the browser and cannot be extracted. As a result, the use of DPoP effectively prevents scenarios where the attacker exfiltrates the applications tokens (See Section 5.1.1 and Section 5.1.2).

    -

    Note that the use of DPoP does not prevent the attacker from running a new flow to obtain a fresh set of tokens (See Section 5.1.3). Even when DPoP is mandatory, the attacker can bind the fresh set of tokens to a key pair under their control, effectively allowing them to calculate the necessary DPoP proofs.

    +

    Browser-based OAuth 2.0 clients can implement [DPoP] to transition from bearer access tokens and bearer refresh tokens to sender-constrained tokens. In such an implementation, the private key used to sign DPoP proofs is handled by the browser and cannot be extracted. As a result, the use of DPoP effectively prevents scenarios where the attacker exfiltrates the application's tokens (See Section 5.1.1 and Section 5.1.2).

    +

    Note that the use of DPoP does not prevent the attacker from running a new flow to obtain a fresh set of tokens (See Section 5.1.3). Even when DPoP is mandatory, the attacker can bind the fresh set of tokens to a key pair under their control, allowing them to calculate the necessary DPoP proofs to use the tokens.

    @@ -2432,8 +2432,8 @@

    The scenario where the attacker obtains a fresh set of tokens (See Section 5.1.3) relies on the ability to directly interact with the authorization server from within the browser. In theory, a defense that prevents the attacker from silently interacting with the authorization server could solve the most dangerous payload. However, in practice, such defenses are ineffective or impractical.

    For completeness, this BCP lists a few options below. Note that none of these defenses are recommended, as they do not offer practically usable security benefits.

    -

    The authorization server could block authorization requests that originate from within an iframe. While this would prevent the exact scenario from section Section 5.1.3, it would not work for slight variations of the attack scenario. For example, the attacker can launch the silent flow in a popup window, or a pop under window. Additionally, browser-only OAuth 2.0 clients typically rely on a silent frame-based flow to bootstrap the user's authentication state, so this approach would significantly impact the user experience.

    -

    The authorization server could opt to make user consent mandatory in every Authorization Code flow, thus requiring user interaction before issuing an authorization code. This approach would make it harder for an attacker to run a silent flow to obtain a fresh set of tokens. However, it also significantly impacts the user experience by continuously requiring consent. As a result, this approach would result in "consent fatigue", which makes it likely that the user will blindly approve the consent, even when it is associated with a flow that was initialized by the attacker.

    +

    The authorization server could block authorization requests that originate from within an iframe. While this would prevent the exact scenario from section Section 5.1.3, it would not work for slight variations of the attack scenario. For example, the attacker can launch the silent flow in a popup window, or a pop-under window. Additionally, browser-only OAuth 2.0 clients typically rely on a silent frame-based flow to bootstrap the user's authentication state, so this approach would significantly impact the user experience.

    +

    The authorization server could opt to make user consent mandatory in every Authorization Code flow (as described in Section 10.2 OAuth 2.0 [RFC6749]), thus requiring user interaction before issuing an authorization code. This approach would make it harder for an attacker to run a silent flow to obtain a fresh set of tokens. However, it also significantly impacts the user experience by continuously requiring consent. As a result, this approach would result in "consent fatigue", which makes it likely that the user will blindly approve the consent, even when it is associated with a flow that was initialized by the attacker.

    @@ -2458,7 +2458,7 @@

    7. Discouraged and Deprecated Architecture Patterns

    -

    Client applications and backend applications have evolved quite a bit over the last two decades, along with threats, attacker models, and our understanding of modern application security. As a result, previous recommendations are often no longer recommended and proposed solutions often fall short of meeting the expected security requirements.

    +

    Client applications and backend applications have evolved significantly over the last two decades, along with threats, attacker models, and our understanding of modern application security. As a result, previous recommendations are often no longer recommended and proposed solutions often fall short of meeting the expected security requirements.

    This section discusses a few alternative architecture patterns, which are not recommended for use in modern browser-based OAuth applications. This section discusses each of the patterns, along with a threat analysis that investigates the attack payloads and consequences when relevant.

    @@ -2466,7 +2466,7 @@

    7.1. Single-Domain Browser-Based Apps (not using OAuth)

    Too often, simple applications are made needlessly complex by using OAuth to replace the concept of session management. A typical example is the modern incarnation of a server-side MVC application, which now consists of a browser-based frontend backed by a server-side API.

    -

    In such an application, the use of OpenID connect to offload user authentication to a dedicated provider can significantly simply the application's architecture and development. However, the use of OAuth for governing access between the frontend and the backend is often not needed. Instead of using access tokens, the application can rely on traditional cookie-based session management to keep track of the user's authentication status. The security guidelines to protect the session cookie are discussed in section Section 6.1.3.2.

    +

    In such an application, the use of OpenID connect to offload user authentication to a dedicated provider can significantly simplify the application's architecture and development. However, the use of OAuth for governing access between the frontend and the backend is often not needed. Instead of using access tokens, the application can rely on traditional cookie-based session management to keep track of the user's authentication status. The security guidelines to protect the session cookie are discussed in section Section 6.1.3.2.

    While the advice to not use OAuth seems out-of-place in this document, it is important to note that OAuth was originally created for third-party or federated access to APIs, so it may not be the best solution in a single common-domain deployment. That said, there are still some advantages in using OAuth even in a common-domain architecture:

    • @@ -2681,7 +2681,7 @@

      or use third-party identity providers. In contrast, the Resource Owner Password Credentials Grant does not provide any built-in mechanism for these, and would instead need to be extended with custom protocols.

      To conform to this best practice, browser-based applications using OAuth or OpenID -Connect MUST use a redirect-based flow (such as the OAuth Authorization Code flow) +Connect MUST use a redirect-based flow (e.g. the OAuth Authorization Code flow) as described in this document.

    @@ -2900,7 +2900,7 @@

    at least two authorization servers. To conform to this BCP such clients MUST apply countermeasures to defend against mix-up attacks.

    It is RECOMMENDED to defend against mix-up attacks by identifying and validating the issuer -of the authorization response. This can be achieved either by using the "iss" response +of the authorization response. This can be achieved either by using the iss response parameter, as defined in [RFC9207], or by using the iss claim of the ID token when using OpenID Connect.

    Alternative countermeasures, such as using distinct redirect URIs for each issuer, SHOULD @@ -3058,7 +3058,7 @@

    Appendix B. Document History

    [[ To be removed from the final specification ]]

    -

    -latest

    +

    -15