View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009556 | Taler | specification | public | 2025-02-17 17:14 | 2025-08-31 17:09 |
| Reporter | Florian Dold | Assigned To | Christian Grothoff | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | high | Severity | feature | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | 1.0 | ||||
| Target Version | 1.0 stretch goals | Fixed in Version | 1.0 stretch goals | ||
| Summary | 0009556: address merchant auth token weirdness | ||||
| Description | * The /token endpoint currently takes only a **Bearer** token as auth and returns another Bearer token. Instead, the /token endpoint should accept credentials via basic auth (and a Bearer token only when refreshing a token). * For human-picked passwords (that are not auth tokens!), we should not require the secret-token: prefix. That prefix should only be necessary for *actual* tokens, not for login credentials. * The response body isn't consistent with the bank (auth_token vs token). | ||||
| Tags | security, ux | ||||
| related to | 0009572 | closed | sebasjm | automatic logout (est 4h - due date 5/6) |
| related to | 0009620 | closed | schanzen | Restrict public instance access and replace token-based authentication with username and password |
| related to | 0009646 | closed | schanzen | Merchant authentication/token API not (fully documented) |
| related to | 0009651 | implementing | schanzen | When changing the instance password we may want to revoke old access tokens |
| child of | 0009647 | closed | schanzen | Scope in tokens / authorizations needs rework |
| "Instead, the /token endpoint should accept credentials via basic auth (and a Bearer token only when refreshing a token)." plus "For human-picked passwords (that are not auth tokens!), we should not..." Needs further clarification: Is the (/private/token) endpoint ONLY supposed to accept "human-picked" passwords (or refresh tokens)? Are there any other type of credentials? What kind of credential is the configured access token going to become? My working assumption is also that this mainly related to the slightly messy taler-merchant-httpd.c:1883ff code, is that right? (If yes, this will require some rework regarding a lot of security-critical logic.) | |
| The answers (until now) are: The instance has a password, which can be set, for example, with taler-merchant-passwd. This password can and must be used for /private/token requests to get an access token. The access token can be used on all the other (private) APIs. Open question: What about the /auth endpoint (https://docs.taler.net/core/api-merchant.html#post-[-instances-$INSTANCE]-private-auth). It seems to have special case handling. It would be treated like any other API, I think, but somebody thought something else here it seems... | |
| I just now realized that this change will require new testing cmds to retrieve the access tokens and probably most tests needs to be modified in order to reflect the change. | |
| Started working on this here https://git.gnunet.org/merchant.git/log/?h=dev/schanzen/issue_9556 | |
| We also may have to/want to invalidate all tokens issued before a new password is set! | |
| This change touches pretty much everything that uses merchant, including and inparticular the taler-typescript-core stuff. So while the implementation in the draft is pretty much good to go almost, my guess would be that this requires a lot more work across repos and integration tests. Things todo: - Rename JSON keys: token => password: token => access_token - Fix SPA to use access tokens instead of passwords - Fix Wallet to use access tokens instead of passwords (?) - Discard tokens on pw change 0009651 - Scope rework 0009647 - Update documentation, in particular https://docs.taler.net/core/api-merchant.html#authentication to reflect changes When all is good I will rebase and squash the branch into a single commit. | |
| Update on things todo: schanzen 2025-03-23 23:34 administrator 0009556:0024292 Last edited: 2025-03-23 23:39 View 6 revisions This change touches pretty much everything that uses merchant, including and inparticular the taler-typescript-core stuff. So while the implementation in the draft is pretty much good to go almost, my guess would be that this requires a lot more work across repos and integration tests. Things todo: - (DONE, for now we return both) Rename JSON keys: token => password: token => access_token - (DONE, see branch in taler-typescript-core)Fix SPA to use access tokens instead of passwords - (UNKNOWN) Fix Wallet to use access tokens instead of passwords (?) - (No protocol breakage) Discard tokens on pw change 0009651 - Scope rework 0009647 - (TODO, integrate new and old API) Update documentation, in particular https://docs.taler.net/core/api-merchant.html#authentication to reflect changes | |
| All above tasks should be done, including 0009647 in the same branch as liste above. 0009651 should be moved post 1.1. Assigning for review/feedback before merge. | |
| ff08d11d..8211f83c completes the merge, fixing the last FIXMEs that are critically relevant to this bug. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-02-17 17:14 | Florian Dold | New Issue | |
| 2025-02-17 17:14 | Florian Dold | Status | new => assigned |
| 2025-02-17 17:14 | Florian Dold | Assigned To | => Christian Grothoff |
| 2025-02-17 19:13 | Christian Grothoff | Assigned To | Christian Grothoff => |
| 2025-02-17 19:13 | Christian Grothoff | Status | assigned => confirmed |
| 2025-02-17 19:13 | Christian Grothoff | Category | mechant backend => specification |
| 2025-03-21 14:00 | schanzen | Relationship added | related to 0009646 |
| 2025-03-21 14:00 | schanzen | Assigned To | => schanzen |
| 2025-03-21 14:00 | schanzen | Status | confirmed => assigned |
| 2025-03-22 10:17 | schanzen | Note Added: 0024279 | |
| 2025-03-22 17:07 | schanzen | Note Added: 0024282 | |
| 2025-03-22 20:30 | schanzen | Note Added: 0024283 | |
| 2025-03-22 20:39 | schanzen | Note Added: 0024284 | |
| 2025-03-22 21:12 | schanzen | Note Added: 0024285 | |
| 2025-03-23 18:42 | schanzen | Relationship added | related to 0009647 |
| 2025-03-23 18:43 | schanzen | Relationship added | related to 0009651 |
| 2025-03-23 22:34 | schanzen | Note Added: 0024292 | |
| 2025-03-23 22:36 | schanzen | Note Edited: 0024292 | |
| 2025-03-23 22:36 | schanzen | Note Edited: 0024292 | |
| 2025-03-23 22:37 | schanzen | Note Edited: 0024292 | |
| 2025-03-23 22:38 | schanzen | Note Edited: 0024292 | |
| 2025-03-23 22:39 | schanzen | Note Edited: 0024292 | |
| 2025-04-17 20:36 | Christian Grothoff | Tag Attached: security | |
| 2025-04-17 20:36 | Christian Grothoff | Tag Attached: ux | |
| 2025-04-23 22:37 | Christian Grothoff | Relationship added | related to 0009572 |
| 2025-04-23 22:37 | Christian Grothoff | Relationship added | related to 0009620 |
| 2025-05-08 13:35 | Christian Grothoff | Relationship replaced | child of 0009647 |
| 2025-06-16 20:18 | schanzen | Note Added: 0025261 | |
| 2025-06-19 12:04 | schanzen | Assigned To | schanzen => Christian Grothoff |
| 2025-06-19 12:05 | schanzen | Note Added: 0025282 | |
| 2025-06-20 20:53 | Christian Grothoff | Product Version | => 1.0 |
| 2025-06-20 20:54 | Christian Grothoff | Priority | low => high |
| 2025-06-21 19:13 | Christian Grothoff | Note Added: 0025292 | |
| 2025-06-21 19:13 | Christian Grothoff | Status | assigned => resolved |
| 2025-06-21 19:13 | Christian Grothoff | Resolution | open => fixed |
| 2025-06-21 19:13 | Christian Grothoff | Fixed in Version | => 1.0 stretch goals |
| 2025-06-21 19:13 | Christian Grothoff | Target Version | 1.1 => 1.0 stretch goals |
| 2025-08-31 17:09 | Christian Grothoff | Status | resolved => closed |