[MODLOGINKC-1] mod-login-keycloak - token endpoint response adjustments Created: 31/Dec/23  Updated: 26/Jan/24  Resolved: 26/Jan/24

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

Type: Bug Priority: P3
Reporter: Craig McNally Assignee: Oleksandr Oliinyk
Resolution: Done Votes: 0
Labels: back-end, epam-eureka, eureka-phase4
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: File MODLOGINKC-1_with_header.mp4     File MODLOGINKC-1_without_header.mp4    
Issue links:
Defines
defines UXPROD-4605 Component Ownership In Progress
Relates
relates to FAT-11523 Review of C423957 test case Closed
Requires
requires FOLIO-3948 Fix pipelines for new modules and libs Closed
requires STCOR-796 integrate RTR with Eureka authenticat... In Review
is required by STCOR-792 Error when logging in PoC environment... In Review
Sprint: Eureka Sprint 43, Eureka Sprint 44
Story Points: 2
Development Team: Eureka

 Description   

In US1147677: mod-login-keycloak - return access/refresh tokens in http-only cookies it's described that the ""token"" endpoint in mod-login-keycloak will support two modes, one which returns AT/RT in cookies as well as response headers, and another which only returns the cookies.  It's stated that the response body in both modes should conform to https://github.com/folio-org/mod-login/blob/master/ramls/loginResponseWithExpiry.json (AT expiration and RT expiration). What I'm seeing in the demo env is that we're returning a response body from the ""token"" endpoint which includes the actual AT and RT, not just their expiration info.



 Comments   
Comment by Natalia Zaitseva [ 31/Dec/23 ]

This is what the current response from the token endpoint looks like:

Comment by Yauhen Viazau [ 04/Jan/24 ]

Oleksandr Oliinyk - is there a way to test both modes using Postman? I see that the mode will be defined by value of X_OKAPI_TOKEN_HEADER_ENABLED environment variable, but not sure how I can set or emulate it

Also, should login with expiry (/authn/login-with-expiry) also be affected by mode change or it should always work in cookie-only mode, as it works now?

Comment by Oleksandr Oliinyk [ 04/Jan/24 ]

Yauhen Viazau It cannot be changed in runtime, I guess we could deploy on two envs in different modes.

Also, should login with expiry (/authn/login-with-expiry) also be affected by mode change or it should always work in cookie-only mode, as it works now?

This is a new endpoint introduced in login 7.3, I don't see why would it support legacy mode too.

 

Comment by Natalia Zaitseva [ 24/Jan/24 ]

Cannot be verified without UI changes. Zak Burke can you help with corresponding changes (or link the existing ticket if it is already in our backlog)

Comment by Yauhen Viazau [ 25/Jan/24 ]

Tested on "evrk" environment - works as expected

  • When  X_OKAPI_TOKEN_HEADER_ENABLED = true, "x-okapi-token" header with access token value is returned by request to /authn/token
  • When  X_OKAPI_TOKEN_HEADER_ENABLED = false, "x-okapi-token" header is not present in the response
  • In both cases:
    • response body only contains expiration date-times for access and refresh tokens (no tokens themselves in body)
    • response sets cookies for access and refresh tokens

See examples:

Comment by Craig McNally [ 26/Jan/24 ]

Since these changes were reverted in evrk I was unable to verify myself, but the recordings provided by Yauhen Viazau are sufficient to accepted this.  Thanks guys!

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