I have an ASP.NET Core Web API that I want to protect when calling from a mobile app. It’s not user-centric, meaning a user does not need to be logged in. The primary concern is disallowing access from clients/apps that are not my own. What’s the best approach here? Machine to Machine? Is there a way to not expire the access token for this scenario? Or maybe there is a better approach?
Thank you!
Looks like what I really want, an API Key, doesn’t exist in Auth0 currently. So I guess I have to go with the next best route. Any suggestions? Having the client get a new access token each time seems too expensive on time. I need this API to get a response back as quick as possible.
Bump, bumpity, bump bump bump
Hi @rev23dev,
Thanks for your patience.
When you have a chance to look at this architecture scenario. You can ignore the roles stuff if your data doesn’t differ by user.
Thanks,
Dan
Thanks @dan.woda, it’s not even that the data doesn’t differ by user… there is no user concept at all in this API.
Imagine I have an API that’s sole responsibility is to post to /ping and receive back “pong”. Its generic, can be accessed without a user being logged on and all I want to do is ensure unauthorized apps don’t access it.
Will the mobile app only be available to trusted users, even if not logged in (essentially, can it be trusted with a client secret)? Or is this a publicly available application?
Hi Dan, this particular API will be called from a publicly available application.
There is no good approach to this… If your app is public (i.e. it runs on a user’s device as opposed to running on a secured environment) then it cannot securely authenticate (you cannot safely store any secret that could be used to provide proof of identity against the API or an authorization server).
Hmm… that’s disappointing :-\
What’s the next best thing given the scenario with the expectation I can’t do it securely? M2M? Or just force a login? It would be nice if Auth0 had the API key concept-- I think that’s the ideal scenario because I do want to potentially open it up to third parties at some point.
I’m definitely not an expert here so take with a hefty grain of salt.
An API key still suffers the same problem. The client is not secure, so the API key can be compromised and is then available for anyone to use. You can do this with M2M / Client Credentials, but there’s not much to be gained. The only semi-secure way to do this would involve creating a client in Auth0 for every instance of your mobile app, and build some way to frequently and regularly rotate the client secret on every mobile app.
Mutual TLS is probably what you want instead.
To be clear, this is not an Auth0 problem or a lacking feature. A public client necessarily can’t securely authenticate to a public service. Anyone with the inclination and time can decompile your app and obtain whatever API key, secret or certificate that you use to authenticate to your API.
That’s why you usually have the concept of user authorization. In the OAuth2 model, the user “authorizes” the application to access the user’s resources (the API is thought as owned by the user), The authorization server (Auth0) handles ther user authentication and confirmation (consent) necessary to issue the token.
Yes, I understand the API key wouldn’t make this more secure; it would only succeed in simplifying this process 
Thank you for your responses. I will just put this behind authorization for the time being I suppose.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.