I’m building a Javascript library (or widget) that can be used in other websites.
Let’s say it allows the users of those websites to do some math calculations. So, the end-user is not my user. They are my customers’ users.
The customer websites must purchase the widget in order to use it in their website.
Question:
how can I protect the library? How can I authenticate my client-side customers?
Limits:
Of course, we don’t want the end-user to do any logins. That should not be their concern.
Also, I don’t want un-authorized websites (that has not purchased the lib) be able to use it.
Non-practical Solution:
One simple solution would be creating an API key for each customer. The JS widget sends it back to my server for authentication and will work only if the API key is valid. But then anyone can use that API key since it’s on the client-side JS code.
Any solutions/ideas?
Can Auth0 be used for this purpose?
If the useful part the library does is all in the client-side then you’re out of luck as a determined attacker will render useless any attempt you perform that depends strictly on client-side logic. You can obfuscate the code, but if all the operations are done through client-side logic then after you have provided the library to one person it’s effectively out there in the open for anyone to reuse/disassemble.
With regards to Auth0, the service mostly focuses on end-user and service to service authentication/authorization; you excluded the end-user part and service to service does not apply as like you said a client-side script cannot securely maintain a key/secret.
Thanks jmangelo.
What if I put a small part of the lib on serverside?
e.g. everything is done on client-side but the final answer comes from a server.
Thanks jmangelo.
What if I put a small part of the lib on serverside?
e.g. everything is done on client-side but the final answer comes from a server.
You would be in a slightly better position, but given the library is used by other parties you server could not require end-user based authentication in a simple way because like you said the end-users are not yours. You could instead require an API key and charge by API call; that way the person to which the API key is issued would have to ensure it does not leak as they are paying by call so it leaks they would still have to pay the calls.
Great but how would they “ensure it does not leak”?
They cannot protect their API key since it’s on client-side.
Would a combination of API key and something fixed (like their website domain) work?
Is there a way to use Auth0 for such thing? something like redirecting to a specific page on their domain for each API key.
In other words, somehow tie the API key to a specific domain and enforce it somehow.
Great but how would they “ensure it does not leak”?
They cannot protect their API key since it’s on client-side.
Would a combination of API key and something fixed (like their website domain) work?
Is there a way to use Auth0 for such thing? something like redirecting to a specific page on their domain for each API key.
In other words, somehow tie the API key to a specific domain and enforce it somehow.
If they used on their client-side they could not ensure it would not leak; I didn’t say it solved all the problems. You would just be pushing the problem to someone else as in they would have to call your API from server-side and then surface the results to their client-side. There’s no easy way around that and validating domains would also not likely get you any benefit.
I’m thinking of using “post-login redirection URL” for this purpose.
Let’s say, my client is example.com and their client_id and secret is visible in their client_side code. However, the page would always redirect to example.com/service.
So, if othersite.com wants to use the same credentials, they will always be redirected to example.com/service which is branded to example.com.
What do you think?