CIAM by example in four recipes: Prevent fraudulent activity

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.

Recipe

Ingredients: 

• An Auth0 Tenant  
• A sample application integrated to Auth0 (you can use one of our quickstarts)

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. 

2. 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:

3. 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.
 

4. 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:
 

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.

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.

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. 
 

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. 
 

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 okta.com/agreements.