Hey Andrea, thanks for the warm welcome! I have verified that the audience is defaulted just like the tutorial. Here is a screenshot of the login flow… chrome log. The logs on the auth0 dash are a bit more confusing to me though, it does show a successful login but many more errors are happening for reasons I am not sure of. logs End result being what you see in the first image. If there is any more info I can provide please let me know!
Hi @gonsalvg,
From what I can see from the screenshots you shared, an error occurs while getting the access token.
However, I’m not able to figure out what the problem is.
To get more info, you should:
- take a look at the failing HTTP request from the dev tools of your browser, similarly to how I reported the 401 issue in the article
- expand the Failed Exchange log entry in the Auth0 Dashboard
Both actions should hopefully give us more information about what is going on.
Hey again! In some strange turn of luck I managed to solve the issue somehow by switching the auth0 app type from SPA to “Normal Web Application” and then back again in its settings.
Perfect! Glad to hear that @gonsalvg!
Hey @gonsalvg, happy to hear you solved the issue!
Found error ‘There was an error trying to log you in: ‘Invalid response Content-Type: text/html, from URL: dev-xxxxx.us.auth0.com/.well-known/openid-configuration’’
Hi @tkvision, welcome to Auth0 Community and thanks for reading this blog post.
The error you reported seems to be related to an error page sent by the /.well-known/openid-configuration
endpoint in place of the JSON configuration data.
It may depend on a wrong configuration on the application side or on the Auth0 dashboard side.
You should find more details on the specific error by taking a look at the Log section in your Auth0 dashboard.
If the error message you should find in the logs is not clear enough, please, share it with us. It could also be useful to capture the HTTP request that gets the error. See here for more details on how to capture HTTP requests.
Is it possible to secure a client Blazor WASM SPA without the asp.net core hosting? I mean I want to keep my existing asp.net core API in a separate solution since it is already been consumed by other apps (Android and iOS).
Thank you!
Hey @carlos.guarany,
Sure, you can create and secure your Blazor WASM app without hosting it in your ASP.NET Core application. Your Blazor WASM app is like any other client app.
Check out this document for more information.
Keep in mind, however, that the current limitation for the audience parameter mentioned in the article still applies.
Could you solve this problem? I have the same message. All the parameters are correct and there’s nothing on the Auth0 log to help. Thanks!
Hi @carlos.guarany,
To try to understand what is going on, I need at least the HTTP request sent to the server.
As said to @tkvision, it seems that the app is receiving an error page (in HTML format) instead of the JSON configuration data.
You can make a couple of tests:
- Check if the URL
https://<your-auth0-domain>.auth0.com/.well-known/openid-configuration
is correct by navigating to it with a browser. - Make sure that you are assigning the base URL of your Auth0 domain (
https://<your-auth0-domain>
) to theAuthority
configuration key and not just your Auth0 domain (see this).
If those checks don’t solve, please, provide me with the HTTP request sent to the server. Let me know.
Hi Andrea,
You’re right, it was missing the “https://” for the Authority configuration. Thank you very much!
Now the login page pops up but after inputting login/password, the app crashes with:
There was an error fetching the SSO data. This is expected - and not a problem - if the tenant has Seamless SSO enabled. If the tenant doesn’t have Seamless SSO enabled, this could simply mean that there was a problem with the network. But, if a “Origin” error has been logged before this warning, please add “https://your-auth0-domain” to the “Allowed Web Origins” list in the Auth0 dashboard
I tried that but the error remains. The Auth0 log says “Successful Login” though.
Thanks,
Carlos
Hey @carlos.guarany,
Happy to hear you resolved the previous issue
Regarding this new one, if the Auth0 log says that the login was successful, it could be a problem with the callback URL. I would suggest you make the following checks:
- Make sure that the
Allowed Callback URLs
field on the app settings in the Auth0 Dashboard matches the actual client address, including the protocol (http
orhttps
) - Try to download, configure, and run the complete app from Github to understand if it is an issue with the code or with your Auth0 configuration.
- If the above points don’t help, please, send us the HTTP request and response affected by the error.
This time the configuration is fine and I am running the Github sample app. If the callback is wrong the login screen won’t show. I forgot to mention it worked fine for a couple of times before the first crash. I found some people with the same issues from old posts using different SPAs.
They say they solved by adding this to the lock config:
auth: {
sso: false
}
I am afraid to break something on production since it’s been used for Android and iOS apps.
I need to setup a totally different testing environment for that.
Thanks,
Carlos
Please, let us know how your tests go and if we can help somewhat.
I’m getting the exact same error. My dashboard config appears to be correct and I’m using the example github project too. Haven’t tried my own even. Must be something odd going on here as a number of people are seeing the same issue…
I’ve looked in the logs and I’m getting an “unauthorised” error. I have reset my password for the user account and tried again - still get the same problem. Logs me in, get the usual “allow access - green tick” box and after that the blazor app shows the same error…
Occurred : 3 minutes ago at 2020-10-06 15:53:40.104 UTC
Type : Failed Exchange
Description : Unauthorized
Seems to be a clear sequence of “Success Login” followed by “Failed Exchange”
Would seem that this change has fixed it… Wasn’t mentioned in the original article as far as I could see…
Thanks for sharing it with the rest of community!
Hi @paulkiddybytes, the best way to understanding what’s going on is to capture and analyze the HTTP requests and responses affected by the error. If you can provide us with them, we can try to understand what is happening.
As far as I know, you should not need this setting. I tested the sample app without it.