From 5b5d2c40903a704ddbbea0024d7644c95c3966e9 Mon Sep 17 00:00:00 2001 From: Soumya Ray Date: Sat, 27 May 2017 22:36:07 +0800 Subject: [PATCH] Update OAuth assignment --- descriptions/090_oauth_protocol.md | 32 ++++++++++-------------------- 1 file changed, 11 insertions(+), 21 deletions(-) diff --git a/descriptions/090_oauth_protocol.md b/descriptions/090_oauth_protocol.md index fa25194..d1d3f98 100644 --- a/descriptions/090_oauth_protocol.md +++ b/descriptions/090_oauth_protocol.md @@ -9,37 +9,27 @@ This week we will implement single sign-on (SSO) to allow users to login using t - find all references to `:accounts` table in other migrations and also call them `:base_accounts` - Model Inheritance - `BaseAccount` model - - move all the code from your `Account` model into a new model called `BaseAccount` + - Move all the code from your earlier `Account` model into a new model called `BaseAccount` - BaseAccount should inherit from `Sequel::Model` - `Account` model - - move the methods `password` and `password=` back into your `Account` model - - `Account` should inherit from `BaseAccount` + - Make your earlier `Account` model inherit from `BaseAccount` + - only keep the methods like `password` and `password=` that relate to registered accounts from your original `Account` model - `SsoAccount` model - create a new, empty `SsoAccount` model - `SsoAccount` should inherit from `BaseAccount` - - Services Refactoring - - Identify service objects that use the `Account` model - - note: you should not be calling any models in your controllers! - - choose whether each service should use `BaseAccount`, `Account`, or `SsoAccount` - - create a new service object and controller route to retrieve (or create) `SsoAccount` accounts + - Service and Controller Refactoring + - Identify service objects and controllers that use the old `Account` model + - choose whether to use use `BaseAccount`, `Account`, or `SsoAccount` + - create a new service object and controller route to authenticate (and create) `SsoAccount` accounts 2. App & API: Distributed Single Sign-On - There are four steps to OAuth based SSO - (one time only) register your app with Github as an OAuth developer application - user clicks on link to Github with `CLIENT_ID` - - Github authorizes app and redirects user back to a callback URL with a `code` + - Github authorizes app and redirects browser back to a callback URL with a `code` - POST request to Github with `GH_CLIENT_ID`, `GH_SECRET`, `code` to get an `access_token` - GET request to Github with `access_token` to retrieve Github account information (login, email) - - Choose from three options (see class handout) of how to distribute these tasks between your App and your API - - option 1: App handles everything and asks API to find/create Github account - - option 2: App and API share responsibilities + - Choose from the options we saw in class of how to distribute these tasks between your App and your API + - ~~option 1: App handles everything and asks API to find/create Github account~~ + - option 2: App completes authorization and sends access_token to API, API uses access_token to retrieve user data from Github - option 3: API handles everything and returns Github account to App - Make sure at the end that your API stores a new `SsoAccount` if one does not exist for an SSO login - -3. OPTIONAL: hardened and granular authorization - - Replace `username` from API routes with `id` of user - - this makes it harder for anyone who has stolen a token to call API (they won't know the `id`) - - effectively means that an attacker would have to know something (`id`) and have something (`auth_token`) - - Add privileges to `auth_token` - - Have a new field in token hash called `privileges`, with values such as `'read'`, `'read write'`, etc. - - Check 'write' privileges if API route changes data (e.g., all POST resource routes) - - This allows us to create tokens for read only access if needed