Best Practices for authenticating my SDK

I’m trying to figure out best practices for authenticating requests coming from my SDK that is integrated in apps that I do not control.

Current setup: I have a backend that uses Auth0 to authenticate incoming requests using JWTs. I also have built an SDK that sends the requests to my backend API, which developers can integrate to their apps. I do not need any user information, so I am just using the client credential grant flow (from my understanding I should be using this because my client is essentially the SDK instance, not the user). I am creating a M2M Application in Auth0 when a developer wants to use my SDK, and then I give them the client_id/secret so they can pass those values into the SDK during initialization. The SDK then stores these and uses them for getting auth tokens from Auth0. Is this the correct setup?

Also, I have been thinking about best ways to limit the number of M2M tokens that are requested from Auth0. Let’s say there are 2 apps using my SDK, App A and App B, and each app has 100 downloads. Should each instance of the SDK (200 instances) be making requests to Auth0 and getting a unique token? So essentially 200 unique tokens that map either to App A or App B? Or should I keep a record in my backend of the client_id, hashed client_secret, the token, and token expiration so that when the SDK requests a token it actually requests my API for a token (not Auth0), and my backend returns either that stored token (if not expired) or requests a new token from Auth0. Would that be a security risk if essentially all instances of App A have the same token and all instances of App B have the same token? I’m new to OAuth authorization and really appreciate some help! If there’s any clarification I need to give on the setup as well, I’m more than happy to provide that. Thank you!

Hi @n8rose1

Welcome to the Auth0 security!

Regarding your setup, yes, that would be the correct approach. It is intended to have a M2M application which is authorized to handle such transactions between your application (SDK) and Auth0’s Management API. That way, unauthorized applications will not be able to request a token directly from Auth0. Basically, your API would be acting as a secure middleman between these transactions.

Otherwise, if you do not mind me asking, what would be the reason of building your own SDK? By using an official Auth0 SDK, the token management would be able to handle it for them.

Sharing the same token information (secret and id) to multiple applications would present multiple risks, such as unauthorized users or applications being able to use them. My personal advise would be to consider the first approach where each instance of the SDK would provide unique tokens which you would be able to track using a record. However, this can rise the risk of hitting rate limits for the Management API. It can be quite difficult to provide a suitable reccomandation without knowing the implementation details of the SDK. For that matter, I would highly recommend to review the following documentation:

As you have mentioned, if you can provide more details about the implementation, how it is being used or sharing the code via a DM, that would be great!

If you have any other questions on the matter, let me know!

Kind Regards,
Nik

Thank you @nik.baleca !

The SDK will be to interact with my backend services (requesting resources, uploading resources, etc). It’s not an SDK to interact with Auth0, but to interact with my own servers. It uses an Auth0 SDK for authentication under the hood, and then sends that M2M token received from Auth0 in all requests to my backend.

I guess what I’m most confused about is whether I should have my SDK request M2M tokens from Auth0 directly or to request tokens from my backend API (which will then request tokens from Auth0). I would share unique token information (secret and id) for each application so that I can reduce risk and track use as you were saying. What I don’t understand is if I should store the M2M token for that secret and id in my backend and reuse that token until it expires. So when the SDK makes a request for a new token, it would request my backend for a token. The backend would then check if the token it has stored for that id and secret is expired. If not, it sends that token to the SDK. If it is, it requests a new token from Auth0, stores it, and sends that new token. Basically, 2 different apps would authenticate my SDK using different id and secret. But then each mobile device running App A would receive the same M2M token, and each device running App B would receive the same M2M token, but the tokens for App A and App B are different.

Are there any security concerns with this? Or is this ok because the SDK per app is essentially one client (even if downloaded on multiple devices)?

Got it! Thank you for providing some extra info on the matter.

To answer shortly to your question, yes, it is ok to do so.

Regarding tokens, it usually is recommended to store and reuse them until they expire instead of “making unnecessary round trips” by defining a token storage. After better understanding your use case and implementation, you could store the M2M tokens until they expire and refresh them since your backend will handle those tokens and the apps would be required authentication.

If I can help with anything else, let me know!

Kind Regards,
Nik