andrewfritz86 · August 28, 2015 16:29 · Aug 28, 2015 · Aug 28, 2015 · Aug 28, 2015 · Aug 28, 2015
diff --git a/oauth.md b/oauth.md
@@ -3,7 +3,7 @@ https://developer.github.com/v3/oauth/#web-application-flow
 
 
 
-####Lesson Breakdown
+####Oauth
 
 What is Oauth? High-level concept.
 
@@ -30,9 +30,3 @@ http://www.twobotechnologies.com/blog/2014/02/importance-of-state-in-oauth2.html
 Imagine a scenario in which someone snatches your public client id, and makes a request to the authorization server. we can check that the initial request came from our server by using a random number (state) that was generated in our own server
 
 
-Breakdown of our in-class code-along app
-Create and register app on github
-Hide client and secret id in bash profile
-Link user to oauth route through github
-Allow redirect route to ‘exchange’ code for auth token
-Use newly granted auth token to access resources 
diff --git a/oauth.md b/oauth.md
@@ -14,16 +14,18 @@ you can think of oauth as like a spare key that a user gives an outside applicat
 
 ####Oauth flowchart overview
 
-client id
-the unique ID of the application. How the authorization server recognizes the application making a request for resources on behalf of someone else. This is publicly available information.
-client secret
-a hidden “password” for the application, also granted by the authorization server. This should always remain private. More on this below.
-authorization code
-Upon a successful authentication of the user, the authorization server sends this code back to the client app as an acknowledgement of a successful authorization. Once received, the client app sends this BACK to the authorization server in order to receive an authorization token.
-authorization token
-Received in exchange for an authorization code. When sent along with a get request, this allows an authorized application to access resources on behalf of a user.
-state
-A string randomly generated by our server that we send over in our get request. We expect the same string back in our oauth redirect path, just to make sure that any request to the oauth redirect path came from the real authorization server. Prevents cross-site request forgery (XSRF).  Related to authentication token in rails.
+- client id
+ - the unique ID of the application. How the authorization server recognizes the application making a request for resources on behalf of someone else. This is publicly available information.
+
+
+- client secret
+  - a hidden “password” for the application, also granted by the authorization server. This should always remain private. More on this below.
+- authorization code
+  - Upon a successful authentication of the user, the authorization server sends this code back to the client app as an acknowledgement of a successful authorization. Once received, the client app sends this BACK to the authorization server in order to receive an authorization token.
+- authorization token
+  - Received in exchange for an authorization code. When sent along with a get request, this allows an authorized application to access resources on behalf of a user.
+- state
+  - A string randomly generated by our server that we send over in our get request. We expect the same string back in our oauth redirect path, just to make sure that any request to the oauth redirect path came from the real authorization server. Prevents cross-site request forgery (XSRF).  Related to authentication token in rails.
 http://www.twobotechnologies.com/blog/2014/02/importance-of-state-in-oauth2.html
 Imagine a scenario in which someone snatches your public client id, and makes a request to the authorization server. we can check that the initial request came from our server by using a random number (state) that was generated in our own server
 

diff --git a/oauth → oauth.md b/oauth → oauth.md
@@ -3,16 +3,17 @@ https://developer.github.com/v3/oauth/#web-application-flow
 
 
 
-Lesson Breakdown
+####Lesson Breakdown
+
 What is Oauth? High-level concept.
+
 provides clients access to a server’s resource on behalf of the owner of those resources
 lets users log in and ‘authenticate’ themselves without compromising their credentials 
 you can think of oauth as like a spare key that a user gives an outside application in that it the user can revoke the outside app’s access.
 
 
-Oauth flowchart overview
-explanation of components (user,client app, authorization server, resource ap)
-explanation of 
+####Oauth flowchart overview
+
 client id
 the unique ID of the application. How the authorization server recognizes the application making a request for resources on behalf of someone else. This is publicly available information.
 client secret

diff --git a/oauth b/oauth
@@ -0,0 +1,35 @@
+GitHub oAuth docs
+https://developer.github.com/v3/oauth/#web-application-flow
+
+
+
+Lesson Breakdown
+What is Oauth? High-level concept.
+provides clients access to a server’s resource on behalf of the owner of those resources
+lets users log in and ‘authenticate’ themselves without compromising their credentials 
+you can think of oauth as like a spare key that a user gives an outside application in that it the user can revoke the outside app’s access.
+
+
+Oauth flowchart overview
+explanation of components (user,client app, authorization server, resource ap)
+explanation of 
+client id
+the unique ID of the application. How the authorization server recognizes the application making a request for resources on behalf of someone else. This is publicly available information.
+client secret
+a hidden “password” for the application, also granted by the authorization server. This should always remain private. More on this below.
+authorization code
+Upon a successful authentication of the user, the authorization server sends this code back to the client app as an acknowledgement of a successful authorization. Once received, the client app sends this BACK to the authorization server in order to receive an authorization token.
+authorization token
+Received in exchange for an authorization code. When sent along with a get request, this allows an authorized application to access resources on behalf of a user.
+state
+A string randomly generated by our server that we send over in our get request. We expect the same string back in our oauth redirect path, just to make sure that any request to the oauth redirect path came from the real authorization server. Prevents cross-site request forgery (XSRF).  Related to authentication token in rails.
+http://www.twobotechnologies.com/blog/2014/02/importance-of-state-in-oauth2.html
+Imagine a scenario in which someone snatches your public client id, and makes a request to the authorization server. we can check that the initial request came from our server by using a random number (state) that was generated in our own server
+
+
+Breakdown of our in-class code-along app
+Create and register app on github
+Hide client and secret id in bash profile
+Link user to oauth route through github
+Allow redirect route to ‘exchange’ code for auth token
+Use newly granted auth token to access resources