Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sunset quickstart "javascript applications without a backend" #516

Merged
merged 3 commits into from
Sep 12, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 12 additions & 11 deletions IdentityServer/v7/docs/content/quickstarts/js_clients/_index.md
Original file line number Diff line number Diff line change
@@ -1,32 +1,33 @@
+++
title = "Building JavaScript client applications"
title = "Building Browser-Based Client Applications"
weight = 10
chapter = true
+++

# JavaScript/SPA Client Applications
# Building Browser-Based Client Applications

When building JavaScript (or SPA) applications, there are two main styles: those
When building browser-based or SPA applications using javascript, there are two main styles: those
with a backend and those without.

JavaScript applications **with a backend** are more secure, making it the
preferred style. This style uses the ["Backend For Frontend"
Browser-based applications **with a backend** are more secure, making it the
recommended style. This style uses the ["Backend For Frontend"
pattern](https://blog.duendesoftware.com/posts/20210326_bff/), or "BFF" for
short, which relies on the backend host to implement all of the security
protocol interactions with the token server. The *Duende.BFF* library is used in
this quickstart to easily support the BFF pattern.
[this quickstart]({{< ref "js_with_backend.md" >}}) to easily support the BFF pattern.

JavaScript applications **without a backend** need to do all the security
Browser-based applications **without a backend** need to do all the security
protocol interactions on the client-side, including driving user authentication
and token requests, session and token management, and token storage. This leads
to more complex JavaScript, cross-browser incompatibilities, and a considerably
higher attack surface. Since this style inherently needs to store security
sensitive artifacts (like tokens) in JavaScript reachable locations, this style
is not encouraged for applications dealing with sensitive data. As the ["OAuth
2.0 for Browser-Based Apps" IETF/OAuth working group BCP
is not recommended. **Consequently we don't offer a quickstart for this style**.

As the ["OAuth 2.0 for Browser-Based Apps" IETF/OAuth working group BCP
document](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps)
says
>there is no browser API that allows to store tokens in a completely secure way.
says:
>there is no browser API that allows to store tokens in a completely secure way.

Additionally, modern browsers have recently added or are planning to add privacy
features that can break some front-channel protocol interactions. See
Expand Down
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
---
title: "JavaScript applications with a backend"
title: "Browser-Based Applications with a BFF"
weight: 10
---

Expand Down Expand Up @@ -106,7 +106,6 @@ builder.Services
.AddBff()
.AddRemoteApis();

JwtSecurityTokenHandler.DefaultMapInboundClaims = false;
builder.Services
.AddAuthentication(options =>
{
Expand All @@ -125,6 +124,7 @@ builder.Services
options.Scope.Add("offline_access");
options.SaveTokens = true;
options.GetClaimsFromUserInfoEndpoint = true;
options.MapInboundClaims = false;
});

var app = builder.Build();
Expand Down Expand Up @@ -153,11 +153,7 @@ app.UseAuthentication();
app.UseBff();

app.UseAuthorization();

app.UseEndpoints(endpoints =>
{
endpoints.MapBffManagementEndpoints();
});
app.MapBffManagementEndpoints();

app.Run();
```
Expand Down Expand Up @@ -412,25 +408,20 @@ HttpContext.GetUserAccessTokenAsync();*
### Update routing to accept local and remote API calls

Next, you need to register both the local API and the BFF proxy for the remote
API in the ASP.NET Core routing system. Add the code below to the *UseEndpoints*
call in *src/JavaScriptClient/Program.cs*.
API in the ASP.NET Core routing system. Add the code below to the endpoint configuration code in *src/JavaScriptClient/Program.cs*.

```cs
app.UseEndpoints(endpoints =>
{
endpoints.MapBffManagementEndpoints();

// Uncomment this for Controller support
// endpoints.MapControllers()
// .AsBffApiEndpoint();
app.MapBffManagementEndpoints();

endpoints.MapGet("/local/identity", LocalIdentityHandler)
.AsBffApiEndpoint();
// Uncomment this for Controller support
// app.MapControllers()
// .AsBffApiEndpoint();

endpoints.MapRemoteBffApiEndpoint("/remote", "https://localhost:6001")
.RequireAccessToken(Duende.Bff.TokenType.User);
app.MapGet("/local/identity", LocalIdentityHandler)
.AsBffApiEndpoint();

});
app.MapRemoteBffApiEndpoint("/remote", "https://localhost:6001")
.RequireAccessToken(Duende.Bff.TokenType.User);
```
The call to the *AsBffApiEndpoint()* fluent helper method adds BFF support to
the local APIs. This includes anti-forgery protection as well as suppressing
Expand Down
Original file line number Diff line number Diff line change
@@ -1,4 +1,5 @@
---
expiryDate: 2024-09-11
title: "JavaScript applications without a backend"
weight: 20
---
Expand Down
Loading