This week, I had to implement an OAuth flow. The motivation for doing is really to avoid having to re-implement all the necessary pages and functionality for your user authentication, registration, forgetting passwords ,etc.
I made the recommendation to the team that we simply just leverage off the great work that google has done and have our sign-in page perform an OAuth authorization to fetch the token and we can validate authorized requests moving forward.
The team agreed and the responsibility lays on me to provide them with the knowledge and comfort to adopt this strategy, but I had to explain to them how OAuth works and how it relates to the redirect urls and configurations.
My attempt to answer “How OAuth works?”.
- The user indicates that he/she wants to use their google login account to access the system (in this case, the pet-adoption system) => This is equivalent to the user clicking on the “sign on using google button”
- The system upon getting this intent from the user, will ask for permission to the auth provider (google in this case).
- The auth provider generates a request token and secret and gives it to the system. (the secret is not used by the user, but it is used by the system to sign each requests to the auth provider. I won’t cover this topic here to minimize complexity)
- The system then redirects the user to the auth provider along with the request token that the user needs to approve. => This is equivalent to the google login page that is shown when you click “sign on using google button”
- The user can then authorize the request by picking/signing into their google account.
- Upon receiving that permission, the auth provider marks that request token as authorized.
- The system (pet-adoption system) then attempts to exchange the request token for an access token.
- Since the request token is authorized, the auth provider will return to the pet-adoption system a legit access token and secret.
Of course this can be illustrated using this diagram here: (credit: www.websequencediagrams.com)
