Details
-
New Feature
-
Status: Closed (View Workflow)
-
P3
-
Resolution: Won't Do
-
None
-
None
-
-
CP: R3 2022 roadmap
-
3
-
Core: Platform
Description
Both the regular and refresh tokens should be returned as part of the login operation JSON response body and not as response headers.
The security problems related to token leaks (FOLIO-2287 and FOLIO-2286) suggest that current design is prone to exploitation because the authentication headers are used both as request and response headers.
This is a breaking login API change and requires client (stripes and mod-user-bl) changes.
Additionally, as discussed in FOLIO-2556 and in the #core-platform channel – there is a potential use-case to return the token as a cookie (Set-Cookie header) to allow for transparent handling of tokens in stripes (it's a good practice to prevent JS to access JWT tokens). This should be verified with StripesForce team.
Example:
POST /login HTTP/1.1 Content-type: application/json { "user":.. "pass":.. "tokenTransport": "body" } HTTP/1.1 200 OK { "accessToken" : "1234", }
and for the “cookie” transported version:
POST /login HTTP/1.1 Content-type: application/json { "user":.. "pass":.. "tokenTransport" : "cookie", } HTTP/1.1 200 OK Set-Cookie: tok=1245 { "tokenTransport" : "cookie", }
TestRail: Results
Attachments
Issue Links
- relates to
-
FOLIO-2523 SPIKE: improve design of authn/z
-
- Blocked
-
-
FOLIO-2556 SPIKE: investigate refresh tokens support in FOLIO
-
- Closed
-
-
MODLOGIN-163 POST /authn/login response contains clear text password
-
- Closed
-
-
STCOR-391 Fix invalid x-okapi-token header error
-
- Closed
-
-
FOLIO-2287 Valid X-Okapi-Token (with permissions) returned on invalid login
-
- Closed
-
-
FOLIO-2564 investigate HTTP Response Header injection
-
- Closed
-
-
OKAPI-763 Prevent X-Okapi-Token being returned by a module
-
- Closed
-