Open ryanckulp opened 5 months ago
Below are live session notes from a student in attendance:
OAuth
Common errors in OAuth 1 solved by OAuth 2
OAuth 2 changes
Historical context
Sensitive vs. non-sensitive scopes
Naming - why is it important?
Javascript origins - not typical OAuth (a Google thing)
from a live coding session at Camp, Cohort 3.
what is OAuth2?
when Users want to connect your app (App 1) with another app (App 2), you need access to their data in App 2. if App 2 has an API, you need the User to grant you permission to their data with some form of API key.
the most common way to provide this API key was for App 2 to let users visit a "Developer" area in their account settings where they could generate and copy/paste a key into 3rd party tools, such as App 1 (your product). but this has several challenges.
OAuth(2) addresses all these issues and more. Oauth is an authorization + authentication strategy that makes it a) easy for Users to connect applications and b) more secure + robust from a connection management and logging perspective.
How Oauth2 works
below is a simple flow of data between your application and the application on which you build an OAuth "client," which then enables your Users to share the other application's data with yours.
in this example we're building an app called "VideoGoals," which allows a YouTube creator to connect their channel and set goals for their content, such as likes or view counts on a per video basis.
Steps to building OAuth connections
Setting up an Oauth2 client
in this example we visit cloud.google.com, create a project, enable the "YouTube Data v3" api, and select the scope
https://www.googleapis.com/auth/youtube
.on the OAuth consent screen we set our redirect URI to simply
http://localhost:3000
, then are granted a "client ID" and "client secret" which we'll need later.a quick search for "Google OAuth2 authorize URL" reveals this snippet:
simply swap out the
scope
,redirect_uri
, andclient_id
from what you configured inside the Google Cloud UI, and visit this URL in your web browser.this completes Step 1 of the diagram above, without writing any code.
it's worth noting that Google's cloud platform and OAuth2 client generator is much more complex than most. to check out simpler examples of OAuth clients, finding and setting scopes, and managing oauth consent screens, check out Gumroad and HubSpot's docs:
one of the most common issue with setting up OAuth clients is simply not paying attention to detail. it's very easy to have a small typo in your authorize URL that will prevent you from testing anything. an example is setting multiple scopes (permissions). some OAuth2 implementations require space delimited, others encoded (
%20
), others with commas, and so on like below:Creating access tokens
after visiting a (working) authorization URL and following through the prompts (login + accept scopes), the User will be redirected to your "redirect URI," which in our examples above is simply
localhost:3000
. note that you do not need to have an actual server running, or any backend code configured at this point.upon redirection your web browser will look something like this:
we want to extract the
code=
parameter, which in this example issdfjasaskdfjsadkfsadf
.next, send a
POST
request to the "token" endpoint of your target Oauth2 client. for Google products it looks like this:the parsed JSON will look like this, and contain a valid access token with which to make API requests against that User's data on the target application.
Making API requests
the Oauth2 standard is for access tokens to be included in API requests via a header called "authorization" and prefixed with "Bearer", like so:
Refreshing access tokens
yet another OAuth2 standard is for access tokens to expire after some amount of time. as you can see in the "data" response above, Google tokens expire in 3600 seconds (1 hour). to request data from a User's account after the expiration, simply refresh the token like so:
refreshing access tokens is done with the "refresh token" from earlier, when you exchanged the code for an access token. always save refresh tokens, because without them your access tokens will eventually be useless.
note that refresh tokens typically don't change, only access tokens. this is a debate amongst some engineers who claim that expiring access tokens is essentially a useless security feature, since refresh tokens act as permanent access tokens.
Next steps
see the code sample in this PR for an automated approach to swapping redirect URI "code" values for working access tokens.