Redirecting to client after login does not recognise that the user has been logged in (TypeScript client and BFF (3.x))

[norgie]

Hi all,
The title may be a wee bit misleading but let me explain my problem. Currently we've got an existing SPA which communicates directly with an IdSrvr (7.x). Now we're in the process of introducing the BFF into this set-up. When running said BFF and the SPA on my machine (localhost), the login flow works without a hitch. However, when I deploy the BFF-application to our test/integration server and then point the SPA to use this BFF instance, then when the user clicks on the login "button" he/she doesn't get logged in but are instead returned to the same page with the log in button still enabled . Using the browser's developer tools I notice that fetching user info from the BFF returns a 401 in this scenario which leads me to think that perhaps the cookie isn't present or not sent to the BFF. Btw, our same-site policy is set to Lax. Any help/pointers etc. would be very welcome.

TIA.

[AndersAbel]

Can you check the network traffic in the browser dev tools? The IdentityServer redirects back to the BFF (default path /signin-oidc). If you inspect the response headers and cookie information for that request, is there a session cookie set? Is that session cookie included in the subsequent calls to /bff/user?

[norgie]

The only cookie set in the browser is one called 'io'. Comparing this to the 'local' scenario we seem to be missing our *_bff cookie. By extension, no cookie present in the request to /bff/user

[pgermishuys]

@norgie given that this is working for you locally and not when you have provisioned / deployed your BFF application to the test/integration setup, we might need to understand a little more about your environment to diagnose further.

This very much feels like a cross origin cookie issue, but without enough information, we need to dig into this a little more.

Can you provide an example of what domains your BFF and SPA are on? foo.com, sample.foo.com?
Could you potentially also analyze and compare the authentication flow between localhost and your provisioned test/integration environment?

[norgie]

@pgermishuys @AndersAbel

Scenario 1:

SPA: localhost:9000
BFF: localhost:33444
AUTH: auth.someapplication.somewhere.com (IdentityServer <-> EntraId)

Cleaned all tokens and user sessions entries.

Started the BFF and the SPA.
Click Log In in the SPA. /bff/login gets called (Login endpoint triggering Challenge with returnUrl http://localhost:9000/)
Protocol: HTTP/1.1
Method: GET
Scheme: http
PathBase:
Path: /bff/login
StatusCode: 302
Location: https://auth.someapplication.somewhere.com/connect/authorize?client_id=our_bff&request_uri=[Redacted]
Set-Cookie: .AspNetCore.OpenIdConnect.Nonce.....
HTTP GET /bff/login responded 302 in ... ms

Interacting with external identity access provider

Path: /signin-oidc
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Connection: keep-alive
Host: localhost:33444
Cookie: .AspNetCore.OpenIdConnect.Nonce...
StatusCode: 302
Cache-Control: [Redacted]
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Location: http://localhost:9000/
Pragma: [Redacted]
Set-Cookie: .AspNetCore.Correlation.....=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/signin-oidc; secure; samesite=lax; httponly,.AspNetCore.OpenIdConnect.Nonce...; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/signin-oidc; secure; samesite=lax; httponly,__our-bff=...; path=/; secure; samesite=lax; httponly
Duration: 843,6378
2025-10-30 15:06:03.401 +01:00 HTTP GET /signin-oidc responded 302 in 846.3514 ms

Protocol: HTTP/1.1
Method: GET
Scheme: http
PathBase:
Path: /bff/user
Accept: /
Connection: keep-alive
Host: localhost:33444
Cookie: io=...; __our-bff=...
Origin: [Redacted]
Referer: [Redacted]
x-csrf: [Redacted]
DNT: 1
Sec-GPC: [Redacted]
Sec-Fetch-Dest: [Redacted]
Sec-Fetch-Mode: [Redacted]
Sec-Fetch-Site: [Redacted]
Priority: [Redacted]
StatusCode: 200
Content-Type: application/json
ResponseBody: [Redacted]

Scenario 2:

SPA: localhost:9000
BFF: bff.someapplication.somewhere.com
AUTH: auth.someapplication.somewhere.com (IdentityServer <-> EntraId)

Cleaned all tokens and user sessions entries.

Started the BFF and the SPA.
Click Log In in the SPA. /bff/login gets called (Login endpoint triggering Challenge with returnUrl http://localhost:9000/)
Protocol: HTTP/1.1
Method: GET
Scheme: https
PathBase:
Path: /bff/login
Connection: keep-alive
Host: bff.someapplication.somewhere.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:144.0) Gecko/20100101 Firefox/144.0
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-GB,nb-NO;q=0.9,nb;q=0.7,no-NO;q=0.6,no;q=0.4,en-US;q=0.3,en;q=0.1
Cookie: AMP_dummy-toke=...; __Stlmnt-bff=...
Referer: [Redacted]
Upgrade-Insecure-Requests: [Redacted]
DNT: 1
Sec-GPC: [Redacted]
Sec-Fetch-Dest: [Redacted]
Sec-Fetch-Mode: [Redacted]
Sec-Fetch-Site: [Redacted]
Sec-Fetch-User: [Redacted]
Priority: [Redacted]
StatusCode: 302
Location: https://auth.someapplication.somewhere.com/connect/authorize?client_id=our_bff&request_uri=[Redacted]
Set-Cookie: .AspNetCore.OpenIdConnect.Nonce....; expires=Fri, 31 Oct 2025 08:22:25 GMT; path=/signin-oidc; secure; samesite=lax; httponly,.AspNetCore.Correlation....; expires=Fri, 31 Oct 2025 08:22:25 GMT; path=/signin-oidc; secure; samesite=lax; httponly
HTTP GET /bff/login responded 302 in 299.2275 ms

NO visual interaction with the external identity access provider
(IdentityServer's log confirms that communication from/with the bff (/Account/Login, /authorize and /userinfo) was successful. The same goes for IdSrvr to EntraId and back)

Protocol: HTTP/1.1
Method: GET
Scheme: https
PathBase:
Path: /signin-oidc
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Connection: keep-alive
Host: bff.someapplication.somewhere.com
Cookie: .AspNetCore.OpenIdConnect.Nonce...; .AspNetCore.Correlation...; AMP_dummy-toke...; __our-bff=...
Referer: [Redacted]
Upgrade-Insecure-Requests: [Redacted]
DNT: 1
Sec-GPC: [Redacted]
Sec-Fetch-Dest: [Redacted]
Sec-Fetch-Mode: [Redacted]
Sec-Fetch-Site: [Redacted]
Sec-Fetch-User: [Redacted]
Priority: [Redacted]
StatusCode: 302
Cache-Control: [Redacted]
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Location: http://localhost:9000/
Pragma: [Redacted]
Set-Cookie: .AspNetCore.Correlation...; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/signin-oidc; secure; samesite=lax; httponly,.AspNetCore.OpenIdConnect.Nonce...; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/signin-oidc; secure; samesite=lax; httponly,__our-bff=...
Strict-Transport-Security: [Redacted]
HTTP GET /signin-oidc responded 302 in 484.4796 ms

Processing user request
User endpoint indicates the user is not logged in, using status code 401
Request and Response:
Protocol: HTTP/1.1
Method: GET
Scheme: https
PathBase:
Path: /bff/user
Accept: /
Connection: keep-alive
Host: bff.someapplication.somewhere.com
Origin: [Redacted]
Referer: [Redacted]
x-csrf: [Redacted]
DNT: 1
Sec-GPC: [Redacted]
Sec-Fetch-Dest: [Redacted]
Sec-Fetch-Mode: [Redacted]
Sec-Fetch-Site: [Redacted]
Priority: [Redacted]
StatusCode: 401
Strict-Transport-Security: [Redacted]
Duration: 1,1036
2025-10-31 09:07:26.531 +01:00 HTTP GET /bff/user responded 401 in 1.2190 ms

[pgermishuys]

The issue is a cross-domain cookie problem . Your BFF sets the session cookie (__our-bff) on bff.someapplication.somewhere.com, but then redirects to http://localhost:9000/. Browsers cannot share cookies across different domains, so when your SPA makes requests from localhost:9000 to bff.someapplication.somewhere.com, the authentication cookie isn't sent which is why you see your user not being authenticated.

The BFF pattern requires same-domain deployment to leverage secure, http only cookies for session management.

You can read more about BFF and hosting models here: https://docs.duendesoftware.com/bff/architecture/ui-hosting/#host-the-ui-separately.

The important bits from the docs is

You’ll need to ensure that the two components are hosted on subdomains of the same domain so that third party cookie blocking doesn’t prevent the frontend from including cookies in its requests to the BFF host.

[norgie]

We had begun to suspect as much, but it is always nice to have the community experts confirm that it was in fact a x-domain cookie issue. Thanks for your explanation and corresponding link.

We made sure our test-client in the same (sub-) domain as the BFF and as expected login worked without a hitch. Again thanks for your help and thanks to the Duende team for making such awesome software.