My 2c avoids oauth2 libraries. Of course, opinions may be different, but for me they provide very impenetrable abstractions, so you get into the understanding of oauth behind the back door. At least for me, after spending an hour to read two pages that will tell you everything you need to know, and carefully avoiding everyone else, they will take you to where you want to be.
Simply put, the steps are: -
On subsequent visits ...
- If you have a google user id in your session, you can get the update token from your database and use it to generate access tokens as needed.
- If you donβt have a google username in your session, follow the steps above. This time, Google will not ask the user for authorization (since it is already allowed), and the update token will be empty (since you already have one file).
All you need to know is on the oauth playground page. If you click on the buttons, you will see that they follow the steps described above.
Then you need to deal with possible error situations like
- user denies permission
- user removes permission.
- google expired update token (it happens a lot), so you need to restart
- timeouts
Two pages you should read: - https://developers.google.com/accounts/docs/OAuth2WebServer and the oauth playground at https://developers.google.com/oauthplayground/
Believe me, if you know how to generate the URL, save the update token (this is just a string) and parse the JSON response, then all you need is on these pages. Besides...
all documentation skips the need to store the user ID in your session so that you know who it is when you access your application. If you work in AppEngine, you may be confused by the code of the sample application, which uses a separate entrance to register applications. Ignore it. You will use oauth to authenticate the user so that the appengine application is not used and is somewhat confusing.
In fact, it is much simpler than some of the documentation would make you believe, and, as I said, imho leaky libraries do not help.
source share