I am currently running through the following example: SPA accessing multiple APIs. I want to request multiple tokens silently in order to access those APIs.
Disclaimer/Note: I have slightly modified the code: the auth_config.json doesn’t have an audience anymore since the SPA is calling APIs running on a different server (hence the code would be just for the SPA and not both SPA and API anymore as in the example).
Everything goes relatively fine until I try to get the respective api tokens (I pass in the audience as opposed to have an auth0 client configured from start)
let api1_token = await auth0.getTokenSilently({audience: api1_aud});
let api2_token = await auth0.getTokenSilently({audience: api2_aud});
Which prevents me from testing the whole scenario. Note that both API have enabled Allow Skipping User Consent.
I understand there are some limitations for localhost but then (1) How do I workaround this (if it’s a localhost only thing) so that I can actually test?
(2) So I have enabled skip user consent for my APIs but how do I disable the profile access consent as well ? my SPA is always first party with regards to the APIs. (see image below)
Consent screen always shows for localhost, as localhost can’t be trusted; despite the “allow skip user content” enabled.
I understand there are some limitations for localhost but then (1) How do I workaround this (if it’s a localhost only thing) so that I can actually test?
Note that this option only allows verifiable first-party applications to skip consent at the moment. As localhost is never a verifiable first-party (because any malicious application may run on localhost for a user), Auth0 will always display the consent dialog for applications running on localhost regardless of whether they are marked as first-party applications. During development, you can work around this by modifying your /etc/hosts file to add an entry such as the following:
If you want to develop in an environment closer to a production one, using a proper (local) domain (via /etc/hosts) and TLS/SSL (i.e. Apache default certs should do, if you’re using that) wouldn’t harm to use anyway.
Correct. I was just trying that (mapping a local domain through /etc/hosts but I encountered the auth0-spa-js must run on a secure origin. error.
What would you suggest then as the quickest option to setup a local trusted https... domain ? That is after mapping 127.0.0.1 local-api within the hosts file.
Also I didn’t know about this:
Similarly, you cannot skip consent (even for first-party applications) if localhost appears in any domain in the Allowed Callback URLs setting (found in Dashboard > Applications > Settings). Make sure to update Allowed Callback URLs , and the callback URL you configured in your application, to match the updated domain-mapping.
That would mean my Allowed Callback URLs could not look like this then:
What would you suggest then as the quickest option to setup a local trusted https... domain ? That is after mapping 127.0.0.1 local-api within the hosts file.
Self-signed cert, the ones that come with Apache or Nginx or which web server you’re using, or get a free one from letsencrypt.com for any real domain you own and put that real domain in your /etc/hosts
Regarding callback URLs: is your question referring to the fragment URLs (# part in there)? The fragments are not needed. Just https://local-api:5000/ should be enough for example.
Regarding callback URLs: is your question referring to the fragment URLs (# part in there)? The fragments are not needed. Just https://local-api:5000/ should be enough for example.
Sorry I might not have been clear. I mean if we need to remove any reference to localhost as the documentation you referenced mentioned:
http://localhost:3000, https://local-api:3000
VS
https://local-api:3000
in reference to:
Similarly, you cannot skip consent (even for first-party applications) if localhost appears in any domain in the Allowed Callback URLs setting (found in Dashboard > Applications > Settings). Make sure to update Allowed Callback URLs , and the callback URL you configured in your application, to match the updated domain-mapping.
Technically, you don’t need to remove the localhost URLs, you can even keep unused ones, incl. localhost; though of course from a security perspective, it’s of course recommended that you only put the ones you’re really using.