Exchange JWT for sda-download session cookie #9

New issue

Closed

opened 2026-02-09 01:07:30 +00:00 by aaperis · 1 comment

aaperis commented

2026-02-09 01:07:30 +00:00

(Migrated from github.com)

Question: It is quite possible that sda-download actually uses an internal sesison cookie that it uses to keep a session alive on its side. In this case, the external behavior is unchanged and the issue below is irrelevant.
This needs to be clarified.

As a user,
I want the UI to exchange my JWT for an sda-download session cookie
so that
subsequent API calls are fast and do not require repeated visa checks.

Description

Call the appropriate sda-download endpoint with Authorization: Bearer
Ensure browser accepts Set-Cookie and sends cookies back on subsequent calls

AC:

After login, the UI can successfully establish an sda-download session and receive a cookie
Subsequent API calls succeed using the cookie-based session

Question: It is quite possible that `sda-download` actually uses an **internal** sesison cookie that it uses to keep a session alive on its side. In this case, the external behavior is unchanged and the issue below is irrelevant. This needs to be clarified. As a user, I want the UI to exchange my JWT for an sda-download session cookie so that subsequent API calls are fast and do not require repeated visa checks. ## Description - Call the appropriate `sda-download` endpoint with Authorization: Bearer <jwt> - Ensure browser accepts Set-Cookie and sends cookies back on subsequent calls AC: - [ ] After login, the UI can successfully establish an `sda-download` session and receive a cookie - [ ] Subsequent API calls succeed using the cookie-based session

aaperis commented

2026-08-25 13:57:15 +00:00

(Migrated from github.com)

According to Jonas' response :
Short answer: the cookie is nothing the website needs to store or use. It is an opaque handle to state that lives in the download container's memory (who you are, which datasets, until when), and it is HttpOnly so page JavaScript cannot read it anyway. Just send Authorization: Bearer on every call. v2 also caches on a hash of the token itself, so you get exactly the same cache hit without the cookie ever being involved.

So, the issue is closed.

According to Jonas' [response](https://nbisweden.slack.com/archives/G01NHJJA9R9/p1787666040101429?thread_ts=1787210872.840779&cid=G01NHJJA9R9) : Short answer: the cookie is nothing the website needs to store or use. It is an opaque handle to state that lives in the download container's memory (who you are, which datasets, until when), and it is HttpOnly so page JavaScript cannot read it anyway. Just send Authorization: Bearer <token> on every call. v2 also caches on a hash of the token itself, so you get exactly the same cache hit without the cookie ever being involved. So, the issue is closed.