OAuth 2 release note

docs/release_notes/v-1.4.md

@@ -40,6 +40,24 @@ You must ensure copies of platform and connector images are available in your cu
 
 [Custom Docker connectors](../operator-guides/using-custom-connectors/) in your workspace that specify an image using a fully qualified domain name (for example, `example.com/airbyte/your-custom-source`) ignore your configured custom image registry and pull images from the domain specified by that connector.
 
+### Simplified OAuth flow for connectors
+
+We've simplified how Self-Managed Airbyte instances use OAuth to connect to data sources. You no longer need to implement your own web service to handle OAuth flows, removing the need for an entire piece of web infrastructure so you can start moving data faster and more easily.
+
+#### Version 1.3 and earlier
+
+In the past, you implemented your own web service to handle the OAuth flow, passing your client ID and client secret, setting a redirect URL, handling the redirect response, and obtaining an access token and refresh token. You then input that access token and refresh token into Airbyte while setting up a connection.
+
+#### Version 1.4 and later
+
+Airbyte handles the parts of the OAuth flow that once required a separate web server. Existing connections set up using the old flow continue to work. However, when you set up new connections, you use this simplified flow.
+
+1. Create your OAuth application for a given data source.
+2. Input your Client ID and Client Secret in Airbyte while setting up a connection.
+3. Click the authenticate button. 
+
+Airgapped instances support this new flow. The redirect is handled by your web browser and not the Airbyte server.
+
 ## 🐛 Bug fixes
 
 - **Reduced resource consumption**: Instances of Airbyte running multiple connections at a time now consume fewer resources, thanks to optimizations to the `airbyte-worker` pod.