Feat(app, iam): Implements Twitter OAuth as a Provider #87
Conversation
shavinac
force-pushed
the
twitter-stamp
branch
2 times, most recently
from
95a843b to
645996d
Compare
App: - twitter oauth redirect appears as a popup - callback variables (passed as query params in redirect back from twitter) are passed between windows - updates other card tests to remove unnecessary test data IAM Server: - add procedures/twitterOauth.ts to handle server-side OAuth 2.0 flow - implement providers/twitter.ts to verify a user's username given an oauth access code and session key we must implement OAuth flow server-side because Twitter API currently does not allow the bearer token request from a browser (CORS issue). this means the twitter stamp is a multi-step process: 1. app requests the authorization url from iam, prompts user to click through 2. when user clicks through to twitter, and approves the oauth request, twitter redirects user back to app 3. app collects access code and state (session key) from query parameters on the redirect 4. app passes in access code and session key with the actual verify request to iam. iam exchanges access code for an auth bearer token to verify user's twitter info, and verify flow proceeds as normal [#28]
…to install - caused by the `microtime` dependency used by `broadcast-channel` package, used in @dpopp/app - `microtime` does not build for M1 Mac architecture, and also does not have an available pre-built for M1 Mac - one fix is to force use of a later version of node-gyp (v9.0.0)
|
Running into issues running this locally. I might be missing something. I did the following:
|
What |
I added the following to the /app .env file NEXT_PUBLIC_DPOPP_TWITTER_CALLBACK=http://localhost:3000/ |
those look right. which |
NEXT_PUBLIC_DPOPP_IAM_URL=http://localhost:80/api/ |
This PR adds the Twitter oauth authentication flow into the app and iam.
In order to keep this as close to the other implementations as possible, we pass the front-end as the callback url, and keep the IAM *relatively stateless.
* The sdk from Twitter stores state of the verification process in private structs on the sdk instance itself which prevents us from keeping this process entirely stateless.
We must retain sdk instances between connections, so in order to prevent memory leaks, we have a solution whereby each instance is deleted after 60s to give the user a short amount of time to hit
authorise- if they don't authorise in time, then the system will be unable to complete the verification and the process will fail.Connections/sessions are linked via a
statevariable that is generated by the IAM and passed through to Twitter and eventually theappas a queryString in a new window, which is then passed back to the original window via aBroadcastChannel.--
Closes: #28