feat(auth): add external BAT verification endpoints #1575
No reviewers
Labels
No labels
DB & Storage
Deployment
Error Handling & Logging
Maintenance
Payment Backend
backport
backport v0.13.x
backport v0.14.x
backport v0.15.x
bindings
blocked
bug
cdk-sql
ci
cli
deps
documentation
duplicate
enhancement
good first issue
help wanted
invalid
keep-open
ldk-node-ui
migrations
mint
mutation-testing
needs rebase
needs review
new nut
nut change
question
ready
rust-version
rustfmt
stacked hold
stale
testing
wallet
weekly-report
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
cashubtc/cdk!1575
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "4xvgal/feat--ext_bat"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Description
This enables external apps to verify and consume BATs issued by the mint.
Mint can act as Blinded token issuer and verifier for third-party interactions. Similar to Kagi's Privacy Pass Privacy Pass, external API servers can now authenticate users via the Mint without compromising user privacy, using the Mint to validate and spend the tokens presented by users.
Notes to the reviewers
The two new endpoints work together to support external authentication flows:
checkstate: A non-destructive way for a service to ensure a token is good before providing a service.spend: The final step to "burn" the token, preventing double-spending.Renamed internal doc references from
BATtoblind auth tokento satisfy thetyposlinter while maintaining professional terminology.Suggested CHANGELOG Updates
ADDED
POST /v1/auth/blind/checkstate: Endpoint for external verification of blind auth tokens.POST /v1/auth/blind/spend: Endpoint for external spending of blind auth tokens.Support for third-party authentication flows using the Mint as a blinded token verifier.
Checklist
just final-checkbefore committingWe're planning to use this feature in openpleb, to create blinded sessions instead of user-linked sessions
To add custom auth endpoints like this we would need to add them to the spec first to keep cdk inline with the cashu protocol. I have wondered before if a burn endpoint would be useful, but there has not been a push to add it to spec.
You could achieve this use case by not modifying spec and using some other token that is a custom unit as a BAT is just a cashu token with the reserved AUTH unit and a denomination of one. This is what I do for athenut.
Yes, that is true.
However, if I understand it correctly, If both the mint and the 3rd party service want to be "blind authed", that would mean authing with clear auth at oidc, then obtaining bat tokens, then using bat tokens to obtain cashu "auth" tokens for the 3rd party service.
It may be a special usecase for open pleb, in that we want to use both the mint, and the 3rd party service behind blind auth
I didn't realize that part of the endpoint also needed to be specified in the spec😅
If it's only meant for internal service use, adding an endpoint and using a custom unit would indeed achieve that.
However, if mint has a trusted OIDC and can process ODIC authentication anonymously via BAT through mint, mint can be used as an authentication server.
How shoud i go about adding this to spec?
btw this pr needs more feature like Keyset rotation
I think automatic keyset rotation for blind auth keysets might even be something to look into separately. It is not strictly necessary, and it has even some downsides when it comes to privacy, as frequent rotation of the keysets will "flush" the anon set.
But I still think it can make in some instances to have the option to enable auto rotation based on a time frame.
The main problem with having a static keyset for auth tokens, is that a malicious user could mint and store tokens over a prolonged period, and then try to dos the mint, without the mint knowing who it is.
The mint could then still take reactive measures by manually rotating the keyset, but having a proactive option might be nice
Yes, I think that is a separate issue, but it is one we have discussed for regular units and should discuses more for both regular and auth keysets. It could be done both times based and/or when a certain number of proofs are issued from a keyset. We should open an issue to discuses.
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.