[Aleks334]

Changes

• add service for issuing access & refresh tokens
• /api/auth/callback and /api/auth/refresh sets JWTs as cookies in response
• new command handler and new route for refreshing user session: /api/auth/refresh
• unit testing of token issuing service is done via in memory sqlite db
• add IUserContext abstraction that allows application layer to access claims from access token within use cases

Access token - shortlived (30 min), gives access to resources on server, appened in every request in domain. The only claim that I set is sub equal to user's id.

Refresh token - longlived (7 days), appended only when requesting /api/auth/refresh. Allows user session refreshing (getting new tokens). It is stored in database (later it can use cache like redis) and revoked once user refreshes session. In fact this is not JWT but random sequence of 64 bytes encoded in base64 string

How to test (optional)

1. see mermaid sequence diagram of auth flow in server/README.md (it should render automatically on github)
2. Call GET /api/auth/login to provision user and issue JWTs that are set in response as cookies
3. You can inspect cookies with devtools. Look at their atrributes. Access token can be decoded with tool: https://www.jwt.io/
4. call PATCH /api/users/{userId}/nickname endpoint. You should get the result
5. Remove cookies from browser and repeat step above. You will get 401 http status.
6. Login again and call GET /api/auth/refresh. If your refresh token is not stale you will get new JWT pair as cookies in return. Repeat step 4, you should get 200 status this time

I implemented it based on:

• https://milanjovanovic.tech/blog/jwt-authentication-aspnetcore
• https://milanjovanovic.tech/blog/getting-the-current-user-in-clean-architecture
• https://learn.microsoft.com/en-us/ef/core/testing/choosing-a-testing-strategy
• https://learn.microsoft.com/en-us/ef/core/testing/testing-without-the-database#sqlite-in-memory
• https://stackoverflow.com/questions/52184431/in-asp-net-core-read-jwt-token-from-cookie-instead-of-headers
• https://www.jwt.io/
• https://learn.microsoft.com/en-us/ef/core/saving/concurrency

Screenshots / recordings (for UI stuff)

Checklist

• PR is linked to an issue (tab on the right).
• Acceptance criteria (from issue) are met.
• All status checks (CI) are green.
• Tests added / updated.
• Docs updated (if applicable).

---

To have your PR reviewed put the link e.g. https://github.com/akai-org/put-wiki/pull/0 to the Review PR thread on put-wiki dc channel (you must be member of the AKAI discord server)

[Joszkooo]

Git gut, poniżej masz co znalazłem

[Joszkooo]

Sekret request tokena OAuth trzyma IMemoryCache pod kluczem oauth_token, więc callback nie jest związany z przeglądarką, która zaczęła logowanie. Do tej pory nie miało to dużego znaczenia, ale ten PR sprawia, że callback ustanawia sesję (ustawia cookies). Scenariusz:

1. Atakujący woła /api/auth/login, loguje się w USOS swoim kontem i przechwytuje URL .../api/auth/callback oauth_token=T&oauth_verifier=V (nie wchodzi w niego).
2. W ciągu 10 minut (TTL cache) wysyła link ofierze.
3. Ofiara klika i jej przeglądarka dostaje cookies sesji atakującego. Wszystko, co ofiara potem zrobi na wiki (komentarze, oceny prowadzących), trafia na konto atakującego.

[Aleks334]

musze to zobaczyc, bo juz nie pamietam jak byl pisany serwis pod USOS OAuth1

[Joszkooo]

Lmk jak coś znajdziesz