[MODLOGINKC-10] /authn/token returns RT cookie with incorrect path Created: 26/Jan/24  Updated: 07/Feb/24

Status: Open
Project: mod-login-keycloak
Components: None
Affects versions: None
Fix versions: None

Type: Bug Priority: TBD
Reporter: Zak Burke Assignee: Yauhen Vavilkin
Resolution: Unresolved Votes: 0
Labels: back-end, epam-eureka, eureka-phase4
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to UXPROD-4640 Integrating with FOLIO on Eureka In Progress
relates to STCOR-796 integrate RTR with Eureka authenticat... In Review
Sprint: Eureka Sprint 46
Story Points: 1
Development Team: Eureka
RCA Group: TBD

 Description   

Summary: /authn/token?code=... returns an RT cookie with the path set to /; it should be /authn.

Deatils: After authenticating via keycloak, you are redirected back to the stripes UI and stripes makes a request to /authn/token?code=... to exchange keycloak's OTP for FOLIO's AT and RT cookies. This all works properly (yay, RTR coming soon!) but the path on the RT cookie is / instead of /authn as it is in legacy FOLIO (login to folio-snapshot and look at the cookies returned in the request to bl-users/login-with-expiry). This means the RT cookie is sent on every request. This isn't technically wrong (functionally, it's harmless) but it's bad from a security angle because the RT's only job is getting a new AT, so it should only be sent over the wire once, and only in a request to an endpoint to refresh the tokens.


Generated at Thu Feb 08 22:31:46 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.