In several pages and posts, I’ve noticed that it is always “highly recommended” to use an Auth0 hosted page as a means of logging in to a client. Why is that?
What’s wrong with using Lock on a webclient and setting the oidcConformant flag to true? This will use the password-grant (/oauth/token), but why is it only for “highly trusted” clients? Can I not trust our users with their own username and password?
I’m not using “Post” or “Basic” authentication, I’m using “Bearer,” so I am not storing the client secret on the webclient.
I wouldn’t call our client a “highly trusted” client either. The client is being run in a web browser, and the website is on public dns. But I don’t store any sensitive information in the client code. Any sensitive information (client secret, private keys, etc) are only in the server, and it is never sent to the client either.
By the way, I’m setting oidcConformant to true because it seems that everything else is getting deprecated over time. I’d rather start with the new way of doing things.
In one post, amaan.cheval says, “We highly recommend against allowing users to enter their credentials on the client (your app) itself instead of on the Authorization Server (on Auth0)… Our recommended approach is to use Auth0’s Hosted Pages - you can customized the Hosted Login Page as you please visually and on your client…”
The main problem with hosted pages is that the user experience is kind of broken because of the Auth0 URL. We really wanted the login form to be on the home page for ease of use. From what I have gathered from the api docs and forum posts, it seems that an embedded login has risks, but I don’t understand what those risks are.
To give some context, here’s our situation:
We’re building a single page webclient, and we need our users to be able to log in through our client with their username and password. We have an api set up in AWS in order to serve the webclient, but we need to restrict access to api calls by users who are unauthorized to view certain content.
Since I wanted to use the new oidc conformant way of doing things, I had to figure out how to get the access token to be in JWT format. I got that to work by setting oidcConformant to true.
When it comes to software security you’ll most likely encounter levels of security instead of a pure secure vs insecure decision. This means that the amount of security required highly depends on the use case, characteristics and assumptions the entire system (including the client application) can make.
The side-effect for us (Auth0 as a company and Auth0 employees in specific) is that we need to be careful with what we recommend, because what’s an acceptable solution for one use case due to certain restrictions, may not be to another. This means we recommend the solution that provides the best security characteristics in general; hence the reason you see the recommendation for the Auth0 hosted login page.
We also understand that the use of the hosted login page may cause some confusion for end-users depending on the way the client applications are implemented and I can inform you that we are actively working in having suitable options that can be used in general and not just in specific cases for people wanting to use login forms embedded on the client application themselves. However, at this time I can’t provide a definitive ETA.
In a more direct answer to your initial question; the current problem with using Lock with OIDC conformant/audience parameters is that this is currently still not yet formally documented and you can observe some changes in behavior until the time it is documented.
In relation to the issue with trusted clients, again it’s a general thing that may or may not be a concern depending on the situation. In general if a public client (one that does not authenticate/holds a secret) can exchange username/password credentials directly for a token then a malicious application can try to mimic it and try to phish for user credentials; hence the general recommendation for highly trusted clients.
For SPA’s, given they can’t securely hold secrets the option with best security characteristics at the moment would be for them to delegate the authentication process to the hosted login page, which as mentioned, can be customized, but there’s still the URL situation. Having said that, a SPA can use other options if you are satisfied with the characteristics provided by said option. For example, for /oauth/token beside having to let a public client exchange credentials by tokens directly it would mean there’s no notion of session as this is a non-redirect flow.
Personally, if you think of the hosted page as your central point for authentication stuff, including having user signing up through it, then the end-user is unlikely to consider anything strange with the process of redirection for authentication (users are already pretty used to that due to the abundance of social logins).