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_ID | The Plugin ID environment variable should be set when the Plugin is submitted to the marketplace to ensure correct CORS headers. You can find the Plugin ID in the URL of your marketplace submission. |
| 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