OAUTH 2 & FRONT END APPLICATIONS IVAN TSE Pull Request Dashboard It is a frontend application because my personal website is currently on Jekyll and Github Pages So, to host it there, I need it to be completely static. So only index.html and JS. But the thing about this application is I need authenticated access to github api - 60 req/hr - doesn’t show private repro information So my first implementation was this… 

USER CREDENTIALS The user will have to enter their username and password This is the implementation 

I don’t store the password but I set the necessary authorization header to get authenticated calls Quickly I learned this was bad. brittany showed me that it didn’t work with 2FA Users don’t trust my website and they don’t know that behind the scenes, I am honest So, people suggested I use oath 

OAUTH 2 BENEFITS • provide limited access to the resource • not tied to the password • changing password does not revoke access • you can revoke specific clients • Avoids spoofing behavior What is oauth? It’s a protocol to help solve the previous problem. A good analogy is parking your car. Sports car nowadays have two keys You don’t give your main keys to the parking attendant but the one with limited access for example, it only allows 1 mile driving and doesn’t open the trunk So yea, - limited access - not tied to passwords . if we have gone the pw route (and stored them), then user changing pw will revoke all apps that use that pw. - avoids spoofing. if we stored pw, the users learn the behavior of passing passwords around. Bad because hacker and duplicate website. so it’s better if they don’t share pw 

TYPICAL WEB FLOW https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2 There is the client, resource owner, and resource server. the user is the resource owner. Say the user visits our application and now we want to start the oauth dance. So, my first thought was, okay this is simple. the app is my front end app. I just need to implement the dance. So, i started diving into the details of accomplishing that but then I realize 

FIRST IMPLEMENTATION FAILURES In step 4, you also pass your client ID and client secret That you need to pass client credentials in your exchange for an access_token. Client credentials include ID and secret whoa what? a secret. this sounds like something we shouldn’t put on the js end. So I searched around and found gatekeeper 

what it does is it handles the access_token exchange 

So, here, we ask Gatekeeper for the access_token by sending only the code. Gatekeeper will combine that with secret and pass it to the server server will return the access_token which is what the gatekeep returns This is what i currently have on github pull request dashboard I thought this was fine for a while but and I read more about oauth, i realized this was bad as well 

SECOND IMPLEMENTATION FAILURES • Access token SHOULD NOT be exposed to the browser should not be exposed to browser user could have virus on computer and searches your history, the access_token will be in the network tab 

TYPICAL WEB FLOW https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2 If we review this flow again, there is a reason access_token is not returned in step 3. bc that exposes it to the browser and you need to exchange it 

THIRD IMPLEMENTATION: OAUTH 2 PROXY SERVER So, after thinking long and hard about this. I came up with an alternative to gatekeeper a good description of it is that it’s a proxy server. let’s review the flow 

the proxy now sits before the server 1. redirect browser to proxy which redirects to server 2. 3 server actually redirects to client 3. 4 client sends code to proxy to authenicate 4. proxy authtenicates and now stores the access_token in a session Now the client will send requests to the proxy and the proxy will that the request, authenticate it (by adding access token) and ping the server