Update token authorization: no more JWT

descriptions/055_secure_sessions.md

@@ -22,7 +22,7 @@ See the latest version of our demo code:
 3. Create a registration workflow that verifies user emails
   - Allow users to create accounts with only username and email
   - Verify the email address by sending an email
-    - Use Pony + Sendgrid to send the verification email with a link back to our site
+    - Use Pony + SendGrid to send the verification email with a link back to our site
     - Use your secure messaging library to create an encrypted token to embed the new account information in the link
   - Once users return using their verification link, ask for password + password confirmation
   - Create users who have finished the entire process (use a service object)

descriptions/060_token_authorization.md

@@ -0,0 +1,35 @@
+# Token Based Authentication
+
+This week we will introduce authorization to our system, using authorization tokens. See the latest version of our demo project:
+- [Web API: authorized_access](https://github.com/ISS-Security/configshare-api/tree/5_auth_token)
+- [Web App: authorized_access](https://github.com/ISS-Security/configshare-app/tree/3_auth_token)
+
+1. Create a secure library to handle authorization tokens
+  - Create an `AuthToken` LIBRARY:
+    - We will need to reuse some security code from our `SecureDB` library
+      - Refactor `SecureDB` to extract a `Securable` module that handles all the crypto logic
+      - Both `SecureDB` and `AuthToken` should extend `Securable`
+    - Make sure you have some methods to `create` tokens and extract `payload` from tokens
+    - Make sure `AuthToken` throws errors for expired tokens and invalid tokens
+    - I suggest making a unit test to make sure `AuthToken` handles all happy, sad, and bad cases
+
+2. Web API: Issue and require auth tokens
+  - Send back an auth token (encrypted account information) along with raw account information whenever an account is authenticated
+  - Whenever a route requires accessing an account's resources, check the auth token
+    - Create helper methods that verify identify of account identity of token with resource owner
+      - Check token in `HTTP_AUTHENTICATION` header of HTTP request as `'Bearer <TOKEN>'`
+    - Return error 401 for any suspicious cases:
+      - if token is expired
+      - if identify of owner in auth token does not match route
+      - if resource does not belong to account in auth token
+
+3. Web App: Store and use auth tokens
+  - Store auth tokens safely as session information (secure it using `SecureSession`)
+  - Return API's auth token on every request
+    - Send auth token to API in every request as `HTTP_AUTHENTICATION` header: `'Bearer <TOKEN>'`
+    - Allow users to see their own token in their account page
+
+4. API+App: Add features in App to view all resources
+    - Users can see their account information
+    - Users can see all resources they own
+    - Users can see all resources they are shared with others

descriptions/080_token_authorization.md

@@ -3,8 +3,8 @@
 This week will implement the beginnings of authorization, and we will use tokens once again. Note that all the critical authorization decisions will be done on the API side. Thus, the API must create and send an encrypted token that must be returned by client applications on every request.
 
 For example code, take a look at the following branches of the API and App:
-- [API: authorized_access](https://github.com/ISS-Security/configshare/tree/5-authorized_access)
-- [App: authorized_access](https://github.com/ISS-Security/configshare-app/tree/4-authorized_access)
+- [API: authorized_access](https://github.com/ISS-Security/configshare-api/tree/5_auth_token)
+- [App: authorized_access](https://github.com/ISS-Security/configshare-app/tree/3_auth_token)
 
 1. API: Send and Require an Authentication Token from Client Apps
   - Create `JWE` or such library class to encrypt/decrypt JWT tokens for API