diff options
author | Bryan Newbold <bnewbold@robocracy.org> | 2018-12-29 00:09:36 -0800 |
---|---|---|
committer | Bryan Newbold <bnewbold@robocracy.org> | 2018-12-29 00:09:36 -0800 |
commit | 8a6ab2ed76d725e6e8d47e51572f009407ed5ca2 (patch) | |
tree | cebe353d88a83cf01523aa204873806dd0100db7 /notes | |
parent | 99b5cc75a224eaeb4c4f1f5eae676bd35a17abc4 (diff) | |
download | fatcat-8a6ab2ed76d725e6e8d47e51572f009407ed5ca2.tar.gz fatcat-8a6ab2ed76d725e6e8d47e51572f009407ed5ca2.zip |
notes and TODO (WIP)
Diffstat (limited to 'notes')
-rw-r--r-- | notes/auth_thoughts.txt | 37 |
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 |