[FOLIO-3627] Poppy 2023 R2 - Implement refresh token rotation (RTR) in all affected modules Created: 03/Nov/22 Updated: 08/Feb/24 |
|
| Status: | In Progress |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Epic | Priority: | P2 |
| Reporter: | Steve Ellis | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | NFR, refresh-tokens | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||||||
| Epic Name: | Refresh token rotation | ||||||||||||||||||||||||
| Sprint: | |||||||||||||||||||||||||
| Development Team: | None | ||||||||||||||||||||||||
| Description |
|
The core platform has been modified to support two security enhancements: All modules that rely on the current login interface of mod-login need to replace use of the authn/login endpoint use the new authn/login-with-expiry endpoint. This new endpoint will return a token pair consisting of a refresh token (RT) and an access token (AT) in the form of Set-Cookie headers. Both the AT and RT have a TTL, and the RT may be used to request a new AT/RT pair prior to expiration. Converting to the new API is non-optional. The old login endpoint and the new login endpoint will not exist together in any FOLIO release, although both endpoints may be available in snapshot to ease the pain of switching over. See the following page for details including: https://folio-org.atlassian.net/wiki/pages/viewpage.action?pageId=1396980
|
| Comments |
| Comment by Steve Ellis [ 21/Nov/22 ] |
|
Adam Dickmeiss has implemented a shared library and sample usage for vertx-based modules here: https://github.com/adamdickmeiss/folio-vertx-login |
| Comment by Erin Nettifee [ 16/Dec/22 ] |
|
Steve Ellis as the work on this progresses, can a developer help with creating some wiki on how subject-matter staff would use this approach in Postman? Many of us (myself included) are doing a lot of API work with Postman because our scripting skills are not advanced, and so this will be a change that people will have to be able to understand. |
| Comment by Steve Ellis [ 21/Dec/22 ] |
|
Erin Nettifee Thanks for your question and sorry for the delay in replying. Your point is well taken. We need to create a wiki page for people who are used to the way the current tokens work. Using the new tokens won't be as convenient as the old ones, but getting a new token when the one you have expires is as simple as posting a new login request to authn/login-with-expiry with your credentials and reading the Set-Cookie header which will contain the new access token. Then you can use that token in your subsequent postman requests until it expires. |
| Comment by Erin Nettifee [ 21/Dec/22 ] |
|
Steve Ellis it's OK, I appreciate your response. I think also it would help to know how that could potentially work with an SSO environment, if that could be understood. I know at Duke, all of our FOLIO environments are using our Shibboleth for login, so my netid password is not my FOLIO password. I did a little poking around when I saw this jira, and it looks like Postman has a cookie manager feature - https://learning.postman.com/docs/sending-requests/cookies/ - but I haven't experimented with it. |
| Comment by Zak Burke [ 12/Jan/23 ] |
|
For UI applications, https://github.com/folio-org/ui-invoice/pull/657 demonstrates an especially nice backwards-compatible implementation that others should consider copying. Nice work, Yury Saukou! |
| Comment by Kara Hart [ 16/Feb/23 ] |
|
I'm concerned about some Google Colabs I have set up to query API's. For example, I have a script set up to loop through a list of barcodes and queries each for it's circulation checkouts and if it's a long list, my RT is likely to expire and my script will fail in the middle. I don't yet have the coding skills myself to get around this. Advice on these types of issues for the novice API users would be great. |
| Comment by Julian Ladisch [ 09/May/23 ] |
|
Kara Hart : As soon as API tokens are available you should switch to them because they don't expire:
Until then you need to look at the access token expiration. Note: In scripts there is no need to make use of the refresh token. You can simply login in again with username and password. After processing one barcode you might look at the access token expiration and if it is less than your maximum processing time (eg. 60 seconds) simply get a new access token. Or you simply process the list of barcodes in batches (eg. 1000 barcodes) and after each batch you fetch a new access token. |
| Comment by Khalilah Gambrell [ 28/Jun/23 ] |
|
Hey Steve Ellis and Zak Burke, does the epic impact consortia development? |
| Comment by Steve Ellis [ 28/Jun/23 ] |
|
Khalilah Gambrell Zak Burke and Dennis Bridges - I think its the other way around: the consortia development will impact the RTR work in that integrating the changes from the ECS work to the core platform modules that have the RTR changes will take more time because there is likely overlap between the code. The ECS work has not been done based on the RTR branches but rather off of master. That said, I think the current shared understanding is that the design of ECS is not in conflict with the design of RTR. There's nothing in principle about ECS that makes it incompatible with RTR. I'll tag Olamide Kolawole and Julian Ladisch who I believe share this understanding. Please correct me if needed. |
| Comment by Dennis Bridges [ 30/Jun/23 ] |
|
Sounds like we will just need to pay close attention when this code is merged and retest both features. |
| Comment by Mike Taylor [ 25/Jul/23 ] |
|
Instead of having every application re-implement getLegacyTokenHeader(okapi), we should have extended stripes-core so every app can call tstripes.legacyTokenHeader(). |