Example CloudFlare Worker to proxy OAuth 2.0 login requests and communication tokens with a Framer plugin.
See our Implementing OAuth guide on how to set this up.
The following environment variables need to be added via the CloudFlare console or CLI.
| Name | Details |
|---|---|
| CLIENT_ID | App ID created in the providers developer console |
| CLIENT_SECRET | App secret key created in the providers developer console. Do not expose in source code or send back to the client! |
| PLUGIN_URI | Root path of where your plugin is hosted |
| REDIRECT_URI | Callback path that provider will redirect to after logging in |
| AUTHORIZE_ENDPOINT | Provider endpoint path for showing the log in screen |
| TOKEN_ENDPOINT | Provider endpoint path for fetching and refreshing access tokens |
| SCOPE | Provider permissions separated by a space |
To test locally, create a .dev.vars file with your own CLIENT_ID and CLIENT_SECRET.
# Install the dependencies.
npm install
# Run the worker locally.
npm run devPlugins use a different flow compared to a typical web app. This involves polling for tokens instead of passing them via window.opener.postMessage.
This is a high level overview of the authorization flow:
- The plugin makes a request to
/authorizeendpoint retrieve an authorization URL and read key. - The plugin then opens a new window using the authorization URL.
- When the window opens, in the background the plugin starts polling
/pollendpoint with the read key, waiting for tokens. - The user logs into the provider in the new window.
- Once the user logs in, the provider redirects to the
/redirectendpoint with an access code. - The backend uses the access code and client secret to fetch tokens from the provider.
- The backend then makes the tokens available via the
/pollendpoint and read key - The plugin picks up the tokens via the
/pollendpoint and stores them in local storage