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.