CIAM by example in four recipes: Prevent fraudulent activity

This recipe is part of the series Learn CIAM by example: Four recipes to improve your app’s security and UX. You can learn more about the series by downloading our four recipes in a cookbook format.

In this recipe, you learn how to use CIAM to prevent fraudulent sign-ups and account takeovers.

Fraudulent activity on the web can happen on any application or channel you can think of.

New technologies — from data lakes to cloud ETLs and AI — are drastically increasing the volume of consumer data stored and processed by companies. While this leads to highly personalized services (and customer delight), it also raises concerns for people about how you keep their data  safe and private when they sign up and use your services.

When it comes to Identity, fraudulent app activities typically happen through two vectors: fraudulent sign-ups and account takeovers

In fraudulent sign-ups, malicious actors sign up to your apps using fake accounts for personal gain — i.e., access to limited tickets, products, or free services — increasing your company costs and damaging your brand reputation. According to the State of Secure Identity report, fraudulent activity peaked in the first half of the year at 10 million fraudulent registration attempts in one day. Fake accounts cost businesses more than just a marketing drag, with downstream effects on the supply chain, resource investment, and support when things go wrong.

In account takeovers, hackers steal consumer accounts — often using credentials obtained from previous data breaches or carrying over phishing campaigns  — for financial benefits. The FTC recently reported that in 2021, US consumers lost $392 million to fraud while shopping online, and IBM reports that brands lost about $4.45 million to data breaches in 2023.

Even if you don't have your own security operations center (SOC) to keep your systems safe, you can still make smart investments in technology to mitigate fraud and carry your brand into the future and even the metaverse. (Yes, people will still want to order pizza in the metaverse).

Why fraudulent Identity activities are so hard to track

Fraudulent Identity activities are hard to track because attacks are becoming cheaper and more sophisticated, just like the technology that's trending today.

Cybercriminals are rapidly adopting low-code/no-code services to launch profitable attacks faster, regardless of their technical skills. This trend increases the frequency of attacks and amplifies their impact on businesses year over year. According to IBM, organizations need at least 200 days to recover from a security breach.

Legislators are still working on defining what digital safety means for consumers and brands, on your apps and websites and r the entire web.

Phase 1: Know who your users are and sign them in

With the rise in malicious Identity threats like phishing and social engineering, consumers expect brands to balance business outcomes and data privacy regarding the customer experience (CX), and technology and legislation are changing to support consumer safety on the web.

To accommodate the ongoing flux, brands can communicate through their platform’s UX and user interface (UI).Let users know when it benefits them to sign up and how your brand delivers value through their self-identification and your cybersecurity practices.

This post will cover basic Auth0 by Okta features with a full working demo so you can bootstrap balancing security with UX.

If you haven’t done so already, sign up for a free account and set up your tenant to cover the use cases that make the most sense for you and your organization.



So, you’ve never secured an app using Customer Identity and Access Management (CIAM)? We’ve got you. 

Apps and APIs can use CIAM for Identity tasks — like sign-ups, social login, authentication, authorization, and logouts. It's all delivered through open-source SDKs, APIs, and protocols, just like other services you might use (think Datadog for observability, Twilio for SMS, or Stripe for payments). 

Here's how a login works with CIAM:

  1. A user tries to access a function requiring a session.
  2. Your app uses the Auth SDK to check for a valid session. If none exists, the user is redirected to the CIAM system for authentication.
  3. The user logs in.
  4. The CIAM system handles authentication, authorization, and auditing, then redirects the user back to your app.
  5. Your app uses the Auth SDK to access user details from the session and enable the requested functionality.

CIAM gives you the ability to tweak the login process — i.e. UX, social login, biometric auth, bot protection — to ensure only the right people have access to your app without implementing user friction.

Add CIAM to your application

This may be the most intimidating part of the entire project (starting is hard!), even if you have a little bit of coding know-how. So, we’re here to walk you through the steps you need to take to deploy your new application with Auth0.

  1.  In the Auth0 Dashboard,  you can create a login or sign-up for almost any application, machine, or API you can think of. 
Create login


  1. Once you’ve deployed your sample application, you’ll need to configure your app with a secret to use the Auth SDK. In your IDE, search for the .env.local file and edit it with the appropriate information:


Environment variables (.env.local)

Auth0 Dashboard


This should be a generated string, but, for testing, you can put whatever you’d like. 


For production, you can create a generated string here:


The url of your Auth0 tenant domain, your Auth0 application's Client ID, and Client Secret can all be found in one place. 


Navigate to Applications > Applications > Your Application, and capture the following information:

d4J gbwzxYQGq5bK6hjee9uDtZgJdrHnolIDQdlNBsZcSaJ8JzMfPDYBMogIawGaUnRX4dQYlTyyv1OoZuDRebW0gJmplN jze ie7zI MrbSUc wCBQOx aopjn1fUco35LNLISvLrsRN1xe4oWRig




Once you've downloaded the project, you will notice that the deployment is locally hosted, i.e. http://localhost:3000


As you test, you may have your own server information that you may want to reference.


  1. So far, we’ve registered your app.

To complete your configuration, you need to inform Auth0 where to redirect a user after a successful login and logout (callback URL).

This step has tripped up many a developer (copy-paste gets the best of us), but it's an easy step if you know exactly what to type for the callback. In this case, it is http://localhost:3000/api/auth/callback.

UkXtSQb0 XRLecutCNzVMI NfRQ10GlozQrGpZvwaf2H1n8I14S2fsERMjvigKcKCfmxvhkfTRsicKvuLbCXejCIHCt5OZxCPFV7IOYUzaVT5FCp O5oM5MOr6kddS5gcgaKAGopzBoULQp7AxmUcOw


  1. And now, the fun part 🤠 

You can run npm run dev in your favorite IDE, and your application is deployed with the login works.

Now that your application is integrated with CIAM, we can start turning security knobs and switches on to prevent fraudulent activity!

Phase 2: Prevent fraudulent sign-ups from bots

Marketers are on the front lines of marketing fraud. Immersive experiences that consumers get excited about will only be possible if you use your CIAM solution to help enforce security and keep bots out. 

However, adding security can introduce friction that prevents your customers from using your product! 

Here's an example of the friction:

c7NMy6Cv5QzOcVONxjXQJFCNUauRuSWlNJEcIPI2cwCHVstkmeWFw6OTACP3cLtH lWSmIaaFtJ0BinrP7yCyr7swQR2 vqc doYB4jskpTGW45EOPFeEBXvKjqWpTu8i3oWh5GgOMKY7rL7M7K0ObI

Standalone Captchas slow bots down but frustrate customers :( 

Having control over the timing of these safeguards is paramount to UX.

When your application uses Auth0 by Okta, you can easily control when consumers see a CAPTCHA, and implementation takes only two steps: 1.) Turn the bot protection on, and 2.) Select the risk level that will serve as the threshold for bot prevention.


3ou3Rif9QuLEemqMgzpG4g4R  x9F8Zi1K9CLupBiySmHk06YJID21sbX64hOjOkRpDIeE6Ng FYfCnFQ32xTSe0odjaHT8msOYxYr2vxos6MPbDbjn8ANKprfDwwcMdAyjRQT7ytDgpde3lGYeT0C4


1: Turn bot prevention on

UoPCrIYJ5z4tTWuoU3l1pRUiQECj8Bwzti6mDHTjFoHF9pEyfKrvXVrEJ1BR8t3eMW4uO OLH4n8Jj17dRkITBLgZiwCEr3Kbrnss9RppTNqhA9j0hpNiWpM svQdlYfIOc3wUHWCqtIGMTj5k2zEvw

2: Select the risk level


The risk level works as the secret sauce for bot prevention, enabling you to strike the perfect balance between preventing fraudulent sign-up/takeovers while not introducing friction to legit users

And, if you're not sure what risk level to select, keep an eye on the Security Center. It provides advanced, real-time monitoring, available to enterprise customers, to help you see how bot prevention is performing in your app.


mjZAa53KiVe6k FkWgC5KZv9HcwVQLyLBmwxVmOBPZQfB8kXweJcNNuhvcEgSJRU  1nRChl83nMf6oi5doFMMAYwurMIP3gh6ETrtZPMPYBEQQXYllHC0MHh6iCIN4n TZzg0NbVEorY9CQMBob7o0

Security Center: Bot detection monitoring 


Phase 3: Prevent account takeovers from breached credentials

Consumers trust brands that take the time to ensure they’re notified about new or unfamiliar activity on their accounts. To differentiate phishing that mimics generic messaging from real messages, consumers rely on organizations to tailor this messaging to them, not their junk folder.

Auth0 by Okta offers one-click integrations to notify users and your admins when anomalous activity involving their accounts and credentials occurs on your platform. 

L8sFfSw JhN9n30Of1ZFFavtnPFzk62IZxzAm2vrKzFbUFXVf1ztDWnLdnm JD3SDxUoOMFaeveBeOsG IiVQjah2F268IEaByfh9xqGfwIqHPGSGCongfyVJgqrCuAiJ5RYkC1wP9PdV779O3d35kg


These on-off switch features save time and investment in developing the templates and infrastructure necessary to alert users to suspicious activity. Also, teams can focus on making notifications personal to the user so they’re more likely to engage when something doesn't seem right. 

With various attack vectors being combined through cheap and easy means by bad actors on the web, Auth0 by Okta addresses them all out-of-the-box, with low technical investment and fast time-to-market.

Phase 4: Migrate away from passwords

There’s a new W3C and FIDO specification on the block, written to minimize login friction and create phishing-resistant platforms. The standard is for a new type of factor, known as a passkey, which is already used by many service providers, including Apple and Google. 

gQDg5pNySU7EwSNtBYm9zEKB5o3T6EBU1oBq3F0B1rY72WmneIQx7hKF8PcwKcyIVowdeTP9Ma2422v8JTeNvdnl0cItY1CQQX4DbZ B0tN gTW96M4jzMmKUuil550fnBDjZrzrSLyYnvC6bP Gp U


Instead of your users making a facsimile of their biometrics every time they want to onboard, they can authorize a login using their existing face or fingerprint biometric on their device, in any transaction, on any platform they choose. New Universal Login supports the use of passkeys, which means users can skip passwords altogether. 

In the next post, we will dive into passkeys with the recipe: Add passwordless auth with passkeys. To get all the recipes in a comprehensive guide, download our cookbook

These materials and any recommendations within are not legal, privacy, security, compliance, or business advice. These materials are intended for general informational purposes only and may not reflect the most current security, privacy, and legal developments nor all relevant issues. You are responsible for obtaining legal, security, privacy, compliance, or business advice from your own lawyer or other professional advisor and should not rely on the recommendations herein. Okta is not liable to you for any loss or damages that may result from your implementation of any recommendations in these materials. Okta makes no representations, warranties, or other assurances regarding the content of these materials.  Information regarding Okta's contractual assurances to its customers can be found at