summaryrefslogtreecommitdiffstats
path: root/notes
diff options
context:
space:
mode:
authorBryan Newbold <bnewbold@robocracy.org>2018-12-29 00:09:36 -0800
committerBryan Newbold <bnewbold@robocracy.org>2018-12-29 00:09:36 -0800
commit8a6ab2ed76d725e6e8d47e51572f009407ed5ca2 (patch)
treecebe353d88a83cf01523aa204873806dd0100db7 /notes
parent99b5cc75a224eaeb4c4f1f5eae676bd35a17abc4 (diff)
downloadfatcat-8a6ab2ed76d725e6e8d47e51572f009407ed5ca2.tar.gz
fatcat-8a6ab2ed76d725e6e8d47e51572f009407ed5ca2.zip
notes and TODO (WIP)
Diffstat (limited to 'notes')
-rw-r--r--notes/auth_thoughts.txt37
1 files changed, 37 insertions, 0 deletions
diff --git a/notes/auth_thoughts.txt b/notes/auth_thoughts.txt
index ba19f4c2..c82b204e 100644
--- a/notes/auth_thoughts.txt
+++ b/notes/auth_thoughts.txt
@@ -59,3 +59,40 @@ support oauth2 against:
- github
? google
+Macaroon details:
+- worth looking at "bakery" projects (python and golang) for example of how to
+ actually implement macaroon authentication/authorization
+- location is fatcat.wiki (and/or qa.fatcat.wiki, or test or localhost or test.fatcat.wiki?)
+- identifier is a UUID in upper-case string format
+- will need some on-disk key storage thing?
+ => how to generate new keys? which one should be used, most recent?
+ conception of revoking keys? simple JSON/TOML, or LMDB?
+- call them "authentication tokens"?
+- params/constraints
+ - editor_id: always, fcid format
+ - created: always, some date format (seconds/iso)
+ - expires: optional, same date format
+
+It's a huge simplification to have webface generate macaroons as well, using a
+root key. webface doesn't need multiple keys because it only creates, doesn't
+verify.
+
+Code structure:
+- auth service/struct is generated at startup; reads environment and on-disk keys
+- verify helper does the thing
+- some sort of auth/edit context
+
+Roles?
+- public: unauthenticated
+- editor: any authenticated, active account
+- bot
+- admin
+
+Caveats:
+- general model is that macaroon is omnipotent and passes all verification,
+ unless caveats are added. eg, adding verification checks doesn't constrain
+ auth, only the caveats constrain auth; verification check *allow* additional
+ auth. each caveat only needs to be allowed by one verifiation.
+- can (and should?) add as many caveat checkers/constrants in code as possible
+
+http://evancordell.com/2015/09/27/macaroons-101-contextual-confinement.html