Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/davidedaniel/oauth


https://github.com/davidedaniel/oauth

Last synced: 20 days ago
JSON representation

Awesome Lists containing this project

README 

        
#OAuth 2 with GitHub



Oauth docs 



GitHub Oauth docs 

- What is OAuth?



  - OAuth is an (open) authorization standard that allows a 'client application' to access resources on an outside server on behalf of the owner of said resources. In simpler terms, OAuth allows an application to use information kept on the servers of another application, but only with the permission of the user that owns those resources. This is become increasingly frequent with web applications. A good example is using your facebook credentials to log in to another application, and all of the sudden the profile picture for that other application is your facebook picture.



  - The OAuth process consists of a series of 'handshakes' between the client application and the Oauth server. These handshakes ensure that the application asking for resources is registered with the OAuth server, that the application actually does have a user's permission to access said resources, and that those resources will ultimately only be released to the client application.



  - OAuth also allows users to simply 'authenticate' themselves with credentials stored in an outside application's server/database. Users can log in to a 'client application' and the 'client application' never sees nor stores their credentials.



- What actors make up the OAuth process?



| Actor | Role |

|:-- |:-- |:-- |:-- |

|**User**| The user using the client application requesting resources. The owner of the resources that the client application is after.|

|**Client Application**| The application requesting to access resources belonging to a user and being stored on a separate API.|

|**OAuth Server** | The authorization server that verifies a user's identity and allows a user to choose what resources it will allow the client application access to. |

|**Resource Server**| The API where the resources the client App is looking for are.|



- What components are exchanged?



| Component | Role |

|:-- |:-- |:-- |:-- |

|**client_id**|The unique ID of the client application that an authorization server uses to recognize the client application. This is considered publicly available.|

|**client_secret**|A secret 'password' given to the client application by the authorization server. This MUST remain secret. Read more about this and the relationship with the authorization code below.  |

|**authorization code**|Upon the succesful authentication of a User, the Oauth server will send an authorization code back to the client application. This is ultimately exchanged for an authorization token along with the client secret. |

|**authorization_token**|The ultimate goal of all the handshakes: the key the client application uses to access the outside resources it's been after.|

|**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. Read more  here|

|**callback URL**|A route on the client application's server that the Oauth server will send the user back to upon authentication.|



- Why do we need a client secret?



  The callback route is customizable (what if you wanted a different callback route depending on what kind of permissions you were asking for, etc). Upon a successful user authentication, oauth will redirect the client to whatever call back route it’s told to, and it will send a code along.

    Anyone who makes a request using the client id (publicly available) can also modify the headers of the request to specify a custom callback route. Under this scenario, someone with nefarious intentions could simply make a GET request with a stolen client_id and redirect the response to a route of their choosing (presumably on another server somewhere).

    This response would still send along a code, as part of the handshake. However, to complete authentication, the client app must POST back not only this code, but ALSO it’s client_secret (which is theoretically only stored on the server and not able to be intercepted).

    Because only the client app has access to both the authorization code and the client secret, it’s the only app that can actually receive the authorization token, and access resources on the API in question on behalf of the user.



- What is the 'state' thing all about?



  Imagine a scenario in which someone snatches your applications' 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.



- What is the best flavor of ice cream?



  A contentious issue. Likely Mint Chocolate Chip.