my thoughts to jwt

docu/Concepts/Snippets/Authorization/concept.md

@@ -0,0 +1,28 @@
+# Authorization and Private Keys
+## Keys
+For creating transactions ed25519 keys are used for signing. 
+As long the user is the only controlling the private key he is the only one
+how can sign transactions on his behalf. 
+It is a core concept of all crypto currencies and important for the concept,
+that the user has full control over his data. 
+
+Usually crypto currencies like bitcoin or iota save the keys on local system,
+maybe additional protected with a password which is used to encrypt the keys.
+
+## Gradido
+Gradido should be easy to use, so we must offer a solution for everyone not that fit
+with computer, as easy to use like paypal.
+For that role we have the Login-Server.
+It stores the private keys of the user encrypted with there email and password. 
+Additional it stores the passphrase which can be used to generate the private key,
+encryted with server admin public key. So only the server admin can access the keys
+with his private key. [not done yet]
+It is needed for passwort reset if a user has forgetten his password. 
+
+But for the entire concept Login-Server isn't the only way to store the private keys.
+For users which has more experience with computer and especially with crypto currencies
+it should be a way to keep there private keys by themselfs. 
+
+For example a Desktop- or Handy-App which store the keys locally maybe additional encrypted. 
+Maybe it is possible to use Stronghold from iota for that. 
+With that the user don't need to use the Login-Server. 

docu/Concepts/Snippets/Authorization/jwt.md

@@ -0,0 +1,20 @@
+# How JWT could be used for authorization with and without Login-Server
+## What we need
+The only encrypted data in db are the private key.
+Every other data could be accessed without login, depending on frontend and backend code.
+So we need only a way to prove the backend that we have access to the private key. 
+
+## JWT
+JWT is perfect for that. 
+We can use JWT to store the public key of the user as UUID for finding his data in db,
+signing it with the private key. So even if the backend is running in multiple instances,
+on every request is it possible to check the JWT token, that the signature is signed with
+the private key, belonging to the public key. 
+The only thing the backend cannot do with that is signing a transaction.
+That can only be done by the Login-Server or a Desktop or Handy-App storing the private key locally.
+With that we have universal way for authorization against the backend. 
+We could additional store if we like to sign transactions local or with Login-Server and the Login-Server url.
+
+
+
+

docu/Concepts/Snippets/Authorization/session_id.md

@@ -0,0 +1,16 @@
+# Session Id Authorization
+## Login-Server
+With every login, the Login-Server creates a session with a random id,
+storing it in memory. For Login email and password are needed. 
+From email and an additional app-secret (**crypto.app_secret** in Login-Server config) a sha512 hash will be genereted, named **hash512_salt**.
+With sodium function *crypto_pwhash* with **hash512_salt** and user password a secret encryption key will be calculated.
+*crypto_pwhash* uses argon2 algorithmus to have a CPU hard calculation. Currently it is configured for < 0.5s.
+So it is harder to use brute-force attacks to guess the password. Even if someone gets hands on the data saved in db.
+
+With sodium function *crypto_shorthash* a hash will be calculated from the secret encryption key and server crypto key (**crypto.server_key** in Login-Server config, hex encoded, 16 Bytes, 32 Character hex encoded)
+and compared against saved hash in db. If they identical user has successfull logged in. 
+The secret encryption key will be stored in memory together with the user session and client ip from which login call came.
+The session_id will be returned. 
+The session will be hold in memory for 15 minutes default, can be changed in Login-Server config field **session.timeout**
+
+