The current POST /oauth/token endpoint accepts username, password, client_id and client_secret (optional). As client_id is supposed to be public, I think this endpoint is very susceptible to phishing. Am I right? and if so, will there be any plan to enforce client_secret?
Hi @matterdox.
Whether the OAuth token endpoint (/oauth/token) requires a client_secret or not is determined by the Token Endpoint Authentication Method available in the application settings:
You can categorize client applications in two types based on whether they can keep a client_secret secure or not: public and confidential. Confidential clients are apps that run on the server, and public clients are app that run on the user’s device (SPAs, desktop and mobile applications fall into this category).
The token authentication method should be set to “None” for public clients, as they can not provide a client secret.
The password exchange (where you provide username/password in exchange of a token) that you mention is one of the available “grant types” of the token endpoint (see Call Your API Using Resource Owner Password Flow). It is considered a “last-resource” option for legacy applications, and it’s not enabled by default. To avoid password brute-force and phishing attacks, as you mentioned, it’s specially discouraged that this grant type is enabled for public application.
For other grant types, like the authorization code or the refresh token, it is expected that public applications can make requests to the token endpoint without providing a client secret.
Thank you @nicolas_sabena. I appreciate the fact that public clients should use password grant type as last resource. I would like to know if there’s any plan to retire that capability like what happened to oauth/ro endpoint in the past.
There are no plans to retire the capability. The resource owner password grant type is disabled by default when you create a new application, but we still provide the capability to turn it on if you need it/want it.
The /oauth/ro was deprecated because it deviated from the OAuth2 standard and it had other problems, and the proper replacement for its regular purpose is the /oauth/token endpoint with the ROPG flow.
I wonder if you guys could help me with a similar question:
We have an iOS client application as a Unity project and we don’t want to direct users through a browser of any kind for login, we made our own login form as a part of the app.
We’ve been able to implement the password grant type, but as you mention, it should be used as a last resort, because it keeps the client_secret on the device and this could be decompiled.
We want to update to a different grant type, the NATIVE/PKCE type as that is appropriate for mobile apps.
Currently every sample and API doc says “To authorize the user, your app must send the user to the authorization URL’”
Our app can’t open a browser, even an in-app browser. We don’t want social login, we only authenticate with Auth0 directly.
How can I keep my client_secret out of the client application without forcing my app to open a browser to login?
Thanks so much @matterdox and @nicolas_sabena , This thread has great info.
Hi @jesse2.
If you want a native login form in the app, with no browser experience, the only option is the Resource Owner Password Grant (ROPG) option. I.e. the application collects the user credential and exchange them directly for a token result at the /oauth/token endpoint.
What changes in your case is that native applications are “public clients” (they can’t, like you say, keep a secret) so, when properly configured, the client secret should not be present in the /oauth/token password exchange.
In particular, you’ll need to set the Token Endpoint Authentication Method (in the application settings) as “None”, which is the value set when you select an application of type “Native”. When doing this, the client secret is no longer needed (and thus you don’t need to bundle it in the application).
This, obviously, is the big security tradeoff of the ROPG: any attacker could create a fake application pretending to be yours, collect the credentials and successfully get a token (because the app can’t authenticate itself with a secret). This is a security risk that you’ll need to weight when deciding which authentication method to use.
The code exchange flow with PKCE is the recommended one for native apps, but it is interactive (requires a browser).
Hope that clarifies things a bit.
I see, thanks for the thorough answer!
We are using Unity3D as the engine for our iOS app. Are there any Unity Auth0 plugins in the works? I haven’t seen any on the Unity Asset store and I’ve heard this request mentioned in these forums before a few years ago.
I hope you are working on a Unity Plugin because right now the only OAuth SAAS product providing a Unity solution is Firebase. So if you were to make a Unity Plugin I’m sure you would bring over more game/apps devs to use Auth0 as a better alternative.
Cheers,
Jesse
Hi again @jesse2.
I would encourage you to leave this feedback at Auth0: Secure access for everyone. But not just anyone., explaining your use case as good as possible (types of authentication to be used, expected users, and so on). This reaches our Product team directly, and the more requests they get about a feature, the better the chances for it to be implemented.
1 Like
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.