The main use case of Arkose was for fraud prevention. But we also used secure connections between servers using keys. Arkose provides secret and private keys. When we hit a request, we pass those keys, and they verify the request. We send a blob to our server for a secure connection. That's how we implemented it.

I like that they provide different types of challenges, which we implemented locally and with an HTML file for the web browser team. They also provide a secure way to communicate tokens before sending them to our web service. We send details in our request to the Arkose endpoint URL. 

I also like that they challenge crawling in CAPTCHA for mobile. This is good compared to the traditional way because most applications do not use Arkose. It's good when you have a multi-platform or device-supported application. But maybe I'm wrong; this is just my opinion.

Arkose need to provide something for testing. Maybe some test accounts or testing features. For example, I need to check our Arkose token fully, but sometimes it doesn't appear. Even if we are setting it in our web browser, our code is unable to use it. They should improve the testing properties in their SDK or library. It's not coming consistently, even though they say they are always passing it. Maybe Arkose can update that.

In my last project, I used Arkose for around two months. We implemented it in our applications before sign-in and sign-up due to security concerns. Similar to how we use CAPTCHA in web browsers, we use it in our mobile application.

In the last project, most people used it. We used it for Android, iOS, and the web browser, and the development team used it for development-related things.

So, there were around over a hundred users. 

The company decided to use Arkose rather than something else for security reasons. We don't want unwanted requests from bots or other malicious actors. It's a multi-user, multi-platform application. 

If too many users ping the same URL using Forcemail or something similar, the server will be down. We wanted an extra layer of security, so we used Arkose.

It's not hard to implement. It's easy.

Another developer handled the backend, so I never looked into that. But I interacted with it once regarding security. When we updated a new release with new keys, we weren't securely passing the blob-related data. We connected with DevOps to fix that.

The pricing depends on how many users you have.

I would recommend to use it if someone is interested in using Arkose for the first time. You provide authentication when a user types their username and password on your website or mobile app. But, you also provide an extra layer of security with Arkose by using an extra token. We can use it on websites, at least.

For mobile, people use authentication with Google or phone numbers. It's authenticated by OTP. Google and Apple already provide default sign-ins, so there's no need for Arkose on mobile unless you use custom email IDs and passwords without SSO. You can use it on websites to create custom fields for registration and login.

The documentation is also good. Maybe there is room for improvement on the backend side. But for usability and implementation, it would be a ten. I didn't face any issues when I implemented it in our applications.