Wrapping up OAuth 2.0 with the Authorization Code grant type

We're coming to the end of our journey of OAuth 2.0 discovery, and we'll finish off with a deep dive into the Authorization Code grant type, the classic three legged flow. Join us as we learn-by-doing together, all welcome!

Topics:
oauth, oauth2.0, strava, api, bash

Links:

Chapters:
00:00 Welcome & introduction
03:47 Reviewing the different OAuth 2.0 flows we've covered so far
08:50 Focusing in on the theory of the authorization code grant type
14:45 Reading through the Strava API and documentation
19:25 Studying the authorization flow diagram for using the Strava API
26:40 Getting ready to turn the theory into practice
27:06 Understanding the authorization callback domain
28:20 Answering a question about the purpose of the OAuth 2.0 architecture
32:45 Setting the clientid and clientsecret by sourcing an env script from the pass store
33:40 Running the oauthflow-local script to see what happens
35:35 Examining the details of the /oauth/authorize URL that we follow to be asked to authorize a request (with client_id, redirect_uri, scope and response_type query parameters)
39:10 Thinking about Strava API and other scope definitions
42:02 Looking at what we get in the redirect HTTP request when we hit "Authorize" (code and scope query parameters)
44:15 Discussing the safety of scope specification in this flow, and (a bit later) considering unpacking some JWT-based access tokens to check details
46:20 Taking a look at the second call to the /oauth/token endpoint to exchange the authorization code for an access token (the access token received was immediately deauthorized after the stream)
49:00 Examining the details of the script and how it works (ncat ftw!)
53:39 Feeling back to normal with the second call (in function 'exchange_token')
55:45 Summarizing what we've done
56:08 Re-running the flow, this time with a reduced scope
57:10 Authorizing the request, as a human, but de-selecting one of the scopes
57:43 Noticing that we actually get a 401 response because we'd generated a new client secret (invalidating the previous one) a few minutes before, and were still using the old one in the script
59:21 Learning where to find OAuth 2.0 information for SAP BTP resources, via the SAP API Business Hub and SAP Help Portal