# Clerk Changelog β€” Page 31 # IdP-initiated SSO & SAML is Generally Available URL: https://clerk.com/changelog/2024-04-01.md Date: 2024-04-01 Category: SAML Description: SAML Enterprise Connections are now GA and we've added IdP Initiated SSO ## SAML Enterprise Connections are now Generally Available You may have heard this was coming when we shared our notice in February that [SAML Enterprise Connections were exiting Beta](/changelog/2024-02-26). Well... today is the day. Thank you to all of the customers who participated in the Beta and helped harden this functionality πŸŽ‰. But like Steve Jobs often said, there's one more thing... ## IdP Initiated SSO is here Along with the GA, we're also releasing IdP-initiated SSO. This means your customers can now use their IdP of choice (Google Workspace, Microsoft AD, Okta, etc) to initiate sign ins, instead of having to start at your app's Sign In views. While this can be a major quality of life upgrade for your users who already use their IdP's for their other applications, it's important to weigh the [risks of IdP-intiated SSO](/docs/authentication/saml/authentication-flows#risks-of-id-p-initiated-flow) for your application. If you think your users would be interested in this, have a peek at our [IdP-initiated flow docs](/docs/authentication/saml/authentication-flows#id-p-initiated-flow). ### A few more things... Apologies. I said *one more thing* but I guess I meant, *a few more things*. I got caught up in the moment πŸ™‡. In addition to the GA and the IdP-initiated feature release, we also made some quality-of-life improvements to the Dashboard when configuring Enterprise Connections. The new updates make it less error prone and more intuitive to provision the different providers, and improve the overall developer experience. Alongside the GA we also released a few specific tutorials that cover setting up SAML Enterprise Connections for [Azure](/docs/authentication/enterprise-connections/saml/azure), [Google Workspace](/docs/authentication/enterprise-connections/saml/google), and [Okta](/docs/authentication/enterprise-connections/saml/okta). If you haven't taken a look at [Enterprise Connections](https://dashboard.clerk.com/last-active?path=user-authentication/enterprise-connections) in a bit, we encourage you to take another look! --- # Community SDK support for Astro URL: https://clerk.com/changelog/2024-03-28.md Date: 2024-03-28 Category: Community Description: You can now secure your Astro website with Clerk! > \[!IMPORTANT] > We've released our official SDK for Astro! Please refer to [the official Astro SDK changelog](/changelog/2024-07-18-clerk-astro). ## Install the package To get up and running with Clerk and Astro, start by installing the `astro-clerk-auth` and `@astrojs/node` packages: ```bash npm i astro-clerk-auth @astrojs/node ``` ## Add environment variables Before you start using the Clerk integration, you'll first need to set the following environment variables: ```bash {{ title: '.env' }} PUBLIC_ASTRO_APP_CLERK_PUBLISHABLE_KEY= CLERK_SECRET_KEY= PUBLIC_ASTRO_APP_CLERK_SIGN_IN_URL=/sign-in PUBLIC_ASTRO_APP_CLERK_SIGN_UP_URL=/sign-up ``` ## Extend the types Update the `env.d.ts` file inside your Astro project: ```tsx {{ title: 'env.d.ts' }} /// /// ``` ## Add the Clerk integration Open `astro.config.mjs` file and add the `clerk()` integration, and set the `output` to `server`: ```tsx {{ title: 'astro.config.mjs' }} import { defineConfig } from 'astro/config' import node from '@astrojs/node' import clerk from 'astro-clerk-auth' export default defineConfig({ integrations: [clerk()], output: 'server', adapter: node({ mode: 'standalone', }), }) ``` ## Use the middleware This example showcases how to use the `clerkMiddleware` and the `createRouteMatcher` in Astro: ```tsx {{ title: 'src/middleware.ts' }} import { clerkMiddleware, createRouteMatcher } from 'astro-clerk-auth/server' const isProtectedPage = createRouteMatcher(['/user(.*)']) export const onRequest = clerkMiddleware((auth, context, next) => { if (isProtectedPage(context.request) && !auth().userId) { return auth().redirectToSignIn() } return next() }) ``` ## Use the components The package exports the Clerk prebuilt UI components as Astro components and can be used anywhere inside the website: ```astro {{ title: 'src/pages/index.astro' }} --- import { SignedIn, SignedOut } from 'astro-clerk-auth/components/control' import { UserButton, SignIn } from 'astro-clerk-auth/components/interactive' --- ``` Congratulations, you have secured your Astro website with Clerk! To learn more, check out the repo on [GitHub](https://github.com/panteliselef/astro-with-clerk-auth/tree/main/packages/astro-clerk-auth). --- # Introducing Clerk Core 2 Beta URL: https://clerk.com/changelog/2024-02-29-core-2.md Date: 2024-02-29 Category: SDK Description: Our latest beta release ships with an improved design and UX for built-in components, new middleware for Next.js, a CLI tool to help you upgrade, and a lot of bug fixes, DX improvements, and deprecation removals. We've been working extremely hard to deliver (to you and your users) an improved overall experience with Clerk. In service of that, we've done some tidying up and are also rolling out some of our most highly requested SDK features. ## Refreshed UI Components Clerk SDKs included in the Core 2 release ship with improved design and UX on all of our [UI components](/docs/components/overview). Our new designs are the right starting point for any app. We continually strive to deliver a best-in-class collection of drop-in UI components that you can trust will get the job done for your users, so you can focus on building. ![Clerk's monochrome components like Sign In, Sign Up, and OTP displayed in a grid (rotated by roughly 45 degrees).](./ui-components.png) As always, if your app has custom needs, you can leverage our [appearance prop](/docs/components/customization/overview#appearance-prop), or use our [hooks](/docs/references/react/overview) to fully customize your app's authentication experience. ## New default middleware for Next.js We've heard your feedback, and we've re-implemented our middleware helpers for Next.js. In Core 2, our middleware now defaults to not protecting any routes (previously it was the opposite). Going forward, you specify which routes you'd like to protect. You felt it made more sense to selectively configure your route protection, and we agree. ![Code snippet to showcase Clerk's new Next.js middleware. For the full code snippet shown here continue reading.](./middleware.png) Additionally, the middleware bundle generated during build is now just 38kb instead of 150kb. This significantly reduces bundle size for better performance. The new middleware is called `clerkMiddleware`, and you can read all about it in the [docs](/docs/references/nextjs/clerk-middleware) and [upgrade guide](/docs/upgrade-guides/core-2/nextjs#new-middleware-architecture). Here's an example of how you'd protect all routes under `/dashboard`: ```ts // middleware.ts import { clerkMiddleware, createRouteMatcher } from '@clerk/nextjs/server' const isProtectedRoute = createRouteMatcher(['/dashboard(.*)']) export default clerkMiddleware((auth, request) => { if (isProtectedRoute(request)) auth().protect() }) export const config = { matcher: ['/((?!.+\\.[\\w]+$|_next).*)', '/', '/(api|trpc)(.*)'], } ``` ## No more white flash for your users Previously, we went to great lengths behind the scenes to synchronize your app's auth state client-side. This approach (unaffectionately called *Interstitial* internally at Clerk) often led to a sub-optimal experience where end users were shown a brief white flash while we sorted through the exchange. ![Login screen of a dark webapp featuring Clerk's new UI components (in dark mode). The top says "Welcome, Dave" and below is a filled out password input field.](./handshake.png) Over the last few months, we've fully re-imagined our underlying session syncing logic (now affectionately called 🀝 *Handshake* internally) to no longer require client-side Javascript. The end result? 2x-5x faster execution (depending on the environment, your device, and the network) and lower latency for your end-users. **No more 401s. No more white flash. No more infinite redirects. A considerably snappier experience.** ## A whole lot of house cleaning As Clerk has matured, so have our SDKs – and leading into v4 we were carrying around a considerable amount of technical debt. This release, Core 2, drops quite a bit of that debt, by way of simplifying internal logic and dropping previously deprecated functionality. As an example, SDKs included in Core 2 will require you to use at least Node.js 18.17.0, React 18, and Next.js 13.0.4 or later. This allowed us to remove polyfills, compatibility layers, and complex logic that made it easier to introduce bugs. Read the [Core 2 migration guide](/docs/upgrade-guides/core-2/overview) to get all the details. ## A CLI tool to help you upgrade We know dealing with any major release for a piece of your underlying infrastructure, like auth, can be challenging. You just want to get back to building the core functionality of your app – we get it. ![Illustration of a CLI with a big text in the middle saysing "Upgrade CLI"](./cli.png) To aid you in this upgrade, we've built a CLI tool called [`@clerk/upgrade`](https://www.npmjs.com/package/@clerk/upgrade) that scans your codebase and guides you step-by-step in upgrading to Core 2. No upgrade is ever perfect, but we're committed to getting you on to the *latest and greatest*, and back to shipping πŸš€ ## Get started with Core 2 Beta Want to get started with your upgrade process? Head over to our [Core 2 migration guide](/docs/upgrade-guides/core-2/overview), or you can start fresh with one of our [quickstart guides](/docs/quickstarts/overview). If you need help, please contact [support](mailto:support@clerk.com) or join the Clerk Community on [Discord](https://clerk.com/discord). > \[!NOTE] > If you need to reference the previous documentation, the [Core 1 docs](/docs/core-1) are still available. This release is still a beta and we do not recommend deploying it to production, but we do expect a stable release soon. Your [feedback](https://github.com/orgs/clerk/discussions/2900) during the beta phase is enormously valuable for ensuring a smooth, stable rollout. Happy coding ✌️ --- # Data Privacy Framework (DPF) certification URL: https://clerk.com/changelog/2024-02-29.md Date: 2024-02-29 Category: Compliance Description: The DPF bridges the gap between US businesses and GDPR compliance. If you're one of the many businesses that have contacted us about GDPR compliance, you may be pleased with our latest announcement... **Clerk is now self-certified under the [Data Privacy Framework (DPF)](https://dataprivacyframework.gov).** What does that mean? Well, I thought you'd never ask... The [DPF website describes](https://www.dataprivacyframework.gov/program-articles/Benefits-of-the-Data-Privacy-Framework-\(DPF\)-Program) it as: > Participating organizations are deemed to provide β€œadequate” data protection (i.e., privacy protection), a requirement (subject to limited derogations) for the transfer of personal data outside of the European Union under the EU General Data Protection Regulation (GDPR), outside of the United Kingdom under the UK Data Protection Act 2018 and UK General Data Protection Regulation (UK GDPR), and outside of Switzerland under the Swiss Federal Act on Data Protection (FADP) If that's too many acronyms for you, you're not alone. Compliance is complicated. In plainer terms, certification under the DPF is a way for a US business like Clerk to transfer and store an EU citizen's personal data in a way that is in accordance with GDPR. At Clerk, we're on a mission to make compliance more accessible for you and your customers. And while the governing regulations are continually shifting under our feet; by self-certifying under the DPF, we're following the path of some of many other leading US-based SaaS businesses (like [Stripe](https://stripe.com/legal/data-privacy-framework), [GitHub](https://docs.github.com/en/site-policy/privacy-policies/github-general-privacy-statement#data-privacy-framework-dpfs), and [Auth0](https://www.okta.com/privacy-policy/#vii-international-data-transfers-10)). We look at this as an important milestone in our compliance story, and we expect to continue to make more strides in this area as Clerk continues to grow. If you're the type, have a peek at our updated [Privacy Policy](/legal/privacy) and the associated [Data Privacy Framework Notice](/legal/dpf). ## Another privacy related note... In the past, it had been popular to display a user's full name and profile picture while signing in as a means to help drive better conversion. However, this practice is no longer recommended due to the rise of privacy regulations like GDPR and CCPA. Going forward we've made a change to our API to limit the amount of data we return before a user is signed in. While limiting this data will be default going forward, pre-existing instances have the ability to opt-in to this recommended security measure by heading to our [Attack Protection](https://dashboard.clerk.com/last-active?path=user-authentication/attack-protection) page in the Clerk Dashboard. --- # Clerk Go SDK v2 (Beta) URL: https://clerk.com/changelog/2024-02-28.md Date: 2024-02-28 Category: Beta Description: A beta release of our Golang SDK featuring improved API architecture and package structure Want to know an interesting fact? Clerk's backends are written in Golang and the backend that powers our [Dashboard](https://dashboard.clerk.com) experience is a heavy consumer of our open-source Clerk Go SDK. By dogfooding our own SDKs day-to-day, we're able to more readily identify the places where they fall short or don't keep pace with our core product. Today, we're proud to release the beta version of [Clerk Go SDK v2](https://github.com/clerk/clerk-sdk-go/tree/v2) that we feel is not only more feature complete and better structured - but offers a better overall developer experience for building your apps (and ours too πŸ˜‰). We're going to take a bit more time in beta before the proper release but we wanted to share it with you now. We'd love for you to try the beta and share your [feedback](https://github.com/clerk/clerk-sdk-go/issues). You can also read more about in more detail below: - [Go SDK Docs](/docs/references/go/overview) - [pkg.go.dev Docs](https://pkg.go.dev/github.com/clerk/clerk-sdk-go/v2) - [v2 Upgrade guide](https://github.com/clerk/clerk-sdk-go/blob/v2/UPGRADING.md) - [Clerk's Backend API](/docs/reference/backend-api) --- # Notice: SAML exiting Beta on Apr 01, 2024 URL: https://clerk.com/changelog/2024-02-26.md Date: 2024-02-26 Category: Notice Description: As of Apr 1, 2024, SAML Enterprise Connections will be exiting Beta and become Generally Available For customers who have had to live with that little `Beta` tag in the Dashboard for too long, we're getting ready to make an exciting announcement. On April 1st, Clerk's SAML offering will be leaving `Beta` and will be entering `GA` (General Availabilty). To make sure we give customers a heads up before making this change, we're posting this initial notice 5 weeks ahead of time, in addition to emailing all customers with active SAML connections. Below is an FAQ meant to answer some of your questions that may arise, but please reach out to [support@clerk.com](mailto:support@clerk.com) if you have any specific questions... ## FAQ ### How come SAML Enterprise Connections are exiting Beta? We've been working hard with a collection of early customers to ensure that our SAML functionality is professional grade. By hardening our solution slowly over time alongside customers, we finally feel our SAML feature is ready to offer as a paid Clerk offering. ### My app uses SAML Enterprise Connections. When it goes GA, do I need to do anything for it to still work? No. Your application will continue to work as it has previously. However we've recently added some new SAML-related functionality, such as IdP initiated flows that you may want to take a peek at. ### How will this affect my monthly costs? During the beta period, we did not charge for SAML connections. **Starting April 1st, 2024 customers with active SAML Connections on their Production Clerk apps will be charged $50 per month / per connection**. You will not be charged for connections in your Clerk Development environment. To view your existing SAML connections, head to [Enterprise Connections](https://dashboard.clerk.com/last-active?path=user-authentication/enterprise-connections) in the Clerk Dashboard. Please contact [sales@clerk.dev](mailto:sales@clerk.dev) if you're interested in discussing bulk discounts or have other pricing related questions.