When it comes to the world of identity, authentication, authorization, specs, best practices, etc., what is the top thing (or top 3, if you have a few) that you wish you had a really good understanding of?
E.g., what has stumped you the most? What do you wish you could be vastly more knowledgeable in?
Hi @kim.maida
This is an interesting question for me - Iām here for a precisely different reason. I donāt mind learning a bit about authentication etc. but Iām here so I donāt need to. That said the thing Iād love to learn about are the possibilities and not the implementation.
The thing that had me stumped the most was simply how to get started - fair enough Iām not a top programmer (and youāre not a prep school for wanna-be coders) and I donāt understand the basics of authentication (but isnāt that your raison dāetre - so I donāt have to? ).
At risk of coming off as a whiny noob with zero appreciation for Auth0 (the latter, at least, being far from the truth)ā¦
ā¦ as it stands, I have found Auth0 confusing, it has taken me weeks to figure out how to do some really simple things (simple in hindsight) and most of my clues came from questions that other people asked, yay for the community!
One of things that made it difficult for me to get started is that the documentation seems to be pitched at a level that assumes I want to āunderstandā authentication rather than āachieveā it; that said the documentation is vastly superior to much of what is out there and I looked long and hard before settling with Auth0.
Cheers,
[edit: by way of example, this page is excellent configuration options but I can not confidently implement because, frankly, Iād be guessing. I have not yet seen an example that puts options in context, I assume they belong near the top of āapp.jsā (and would be surprised if they donāt).]
@stevo Excellent answer! Thereās always a benefit to understanding what your SaaS provider does, but that shouldnāt be a prerequisite for their implementation imo. I also liked your statement ābut Iām here so I donāt need toā - definitely quoting you on that in the future 
FYI, I can say that even with a (pretty darn) decent understanding of different authentication layers and methods, auth0 still wonāt trust you to fully configure certain parts of the flow. Their workaround is for you to set up a middleware (which feels like reimplementing authentication for my authentication providerā¦).
To answer @kim.maidaās question - I wish Iād have more confidence in setting up my own auth stack (e.g. an OAuth2 server with passport.js, etc.). Atm I feel (even after having done it a couple of times) that thereās a lot of best practises I might overlook and authentication is simply a field where you canāt really allow those (or any?) kinds of mistakes. Maybe thatās just paranoia : ) A very thorough checklist would definitely help out with that.
Thanks for your answers, @stevo and @ajv! These are great insights for us to take into account.
Auth0 developer relations and content teams are in an interesting position because we want to make authentication simple for developers (as you say, āwe care about the details so you donāt have toā) but at the same time, we want to be able to provide sufficient information and resources for folks who feel like they need to know more of the reasons behind the implementations. Finding and maintaining that balance is always an interesting and ongoing challenge!
In addition, because so much configuration is available based on widely differing use cases, application topologies, and business needs, there is no āone size fits allā solution. However, weād love to work harder to provide more āone size is a good start for mostā resources.
@stevo Would a blog post highlighting more configuration and providing context be a helpful resource? Are there any options that sound particularly interesting to you but that youāre unsure of and would like more information on?
@ajv Best practices is also a great suggestion for us to provide more information and resources.
Hi @kim.maida - I think a blog post highlighting basic configuration but providing context would be useful.
There might be something out there already but between the 1) quick-start tutorials, 2) documents, 3) community, and 4) blog posts (listed in the order that I consumed them) there is a lot of information scattered around, oh and searching in 3 does not find results in 2 etc. (I resorted to googling).
Yep - one size fits all is not really a product you sellā¦ too many technologies and use cases.
As far as use cases go, mine might be unique - I have been developing in MS-Office VBA and (as of last night) I have a pretty cool Auth0 login form embedded in a VBA userform and I basically scrape my embedded browser to control flow, itās a means to an end and about as secure as you can get (in VBA).
Next step will be moving everything to a native app / Electron / React or something else. Then comes the IOS and Android appsā¦
Arriving here, the most important thing for me was to get authentication. Not as easy as expected but Auth0 has opened up a new world of possibilities to me - which is great, exciting and all, but I canāt afford to get distracted by all that just yetā¦ for now I need the most basic solution from which I can build on.
But nothing is basicā¦ working with an embedded IE Browser you can imagine things get frustrating when Arrow Functions are not supported and IE chokes on some keywords that it (in itās sole discretion deemed to be reserved) - thatās when <meta http-equiv="X-UA-Compatible" content="IE=edge"> became useful to know (itās hard to love IE / Edge). Worth considering for worked examplesā¦
A blog post (or getting started document) that takes beginners from start to finish using plain JS for a SPA pulling these scattered resources together seems like a pretty good option. The information might be out there but is hard to find. Some points to cover:
logout?returnTo - setting up the Allowed Callback URLs in Tenant settings (not Dash > Applications) also responsible for my receding hairline.Hope it helps
Hi @stevo, thanks for the detailed response! I can definitely appreciate the challenges with your specific use case, and can also appreciate the challenge around finding the right resources when thereās so much information across many different channels.
While it looks like youāve been able to find most of the answers you were looking for already, weāre always happy to help guide you to the right places in the Community forum. If youāre ever having trouble finding docs or resources and would like some guidance, please feel free to create a topic here and we can point you in the right directions.
Regarding a document to take beginners through setting up a vanilla JS implementation, we are actively working on producing such a resource right now. Itās currently in internal review and will be polished to create a public facing Quick Start with updated guidance and UI. We will announce it here in Community as soon as itās launched.
Thank you for your input on the pain points: I am sharing these with our Docs and Content teams! Please donāt hesitate to let us know of any other areas where we can improve our resources!
For Auth0, Iāve found it surprisingly difficult to find the appropriate way to perform what I thought was a pretty standard use case: having a user base with different permissions depending on what part of our service offering they choose to (pay to) subscribe to, and for the first party application to be able to easily retrieve their permissions to determine which content they are authorized to view.
What is the relationship between an Auth0 API, Application and scopes? An Auth0 API is not the API you actually call to get the desired information, so what is its purpose? It would be useful if the docs had an overview of all the most relevant Auth0 concepts and how they relate to one another. Concrete examples go a long way to aid explanations.
I find it hard to identify the difference between scopes and (from the authorization extension) permissions. What is their relationship? What are they used for? After extensive reading, it seems like maybe permissions are everything a user is allowed to do, whereas scopes are what an application is allowed to do on behalf of a user? If so, why is there no out-of-the-box way for a first party application to retrieve all of a userās permissions in the scope claim? We wound up putting all the userās permissions in a custom claim of the access token, but it feels wrong to have to use a custom claim, and it causes issues with other tools expecting such information to be found in the scope claim.
Apparently you donāt want an access token ātoo bigā, whatever that means? What is ātoo bigā? Why is this an issue? Are we byte-counting the access token? Do we really have to compromise what information (including scopes/permissions) we can return to the application in the access token because of perceived bandwidth issues?
Weāve already made use of all of these concepts in our service, and it works for now, but itās so difficult to know if weāre using them ācorrectlyā, and if weāre precluding a future use case by misusing the concepts today.
Hello @andersthorbeck! Thanks for your detailed response and for that feedback. API, scopes, and permissions are some of the trickiest things to tease apart, and we would do well to provide more clarity on the relationship between these things in our resources and documentation!
Your description here is correct:
permissions are everything a user is allowed to do, whereas scopes are what an application is allowed to do on behalf of a user
The following:
If so, why is there no out-of-the-box way for a first party application to retrieve all of a userās permissions in the scope claim
is because, as you stated previous, scopes are not intended for user permissions. Scopes are intended for delegated authorization at the application level. This article on OAuth 2.0 scopes can help to elaborate on this concept. What you are currently doing by adding the userās permissions in a custom claim is a perfectly viable solution.
Regarding having an out-of-the-box solution to this complexity, within the next few weeks we will begin rolling out Roles-Based Access Control (RBAC) for exactly that purpose! RBAC is built into the core of Auth0 and is not an extension. If youāre currently using the Authorization Extension, you can expect to see a notification about RBAC in your Dashboard soon. We hope this feature enhances the experience and ease of managing roles and permissions with Auth0 and look forward to hearing your feedback.
Iāve found it surprisingly difficult to find the appropriate way to perform what I thought was a pretty standard use case: having a user base with different permissions
I greatly appreciate this feedback, and we will work on putting together more cohesive resources to cover this use case and tie together the different moving parts and the roles they play (APIs, applications, scopes, RBAC). Thank you!
Hello, I have long hesitated before implementing Auth0. And I am starting to feel like I have been cheated twice.
Let me explain : The documentation is VERY misleading. Everything is made to corner users into paying for a custom domain. The problem is that you end up realising it after you have implemented an almost working solution.
I first decided to use embedded Lock v11 and could not understand why it was not working under Safari and Brave. For a couple hours, I scouted internet for answers, only to realize that the new versions of Lock needed a custom domain to work properly when third party cookies are blocked (Safari, Brave and Chrome if user block them).
Auth0 docs pointed at using Universal Login to circumvent this issue. So here I am, deleting code, replacing bits, wasting time to use Universal Login. And now, after trying to understand why my App logs out whenever I hit refresh (under Brave), I am just discovering that it is because of cross origin requests again and that I should either use a custom domain or useā¦Universal Login !
Furthermore, not only your code examples for UL make use of checkSession(), which does not work with Brave & safari unless you buy a custom domain. But the docs also mention that UL would allow developers not to use a custom domain without ever explaining how.
No need to say that after wasting so much time to understand the ins and outs of Auth0, I find it absolutely appalling that your paid user acquisition strategy mostly relies on confusing developpers.
Authentication & authorization are confusing and hard to grasp for newcomers. Adding an extra layer of complexity completely ruins the experience.
While I could certainly bear the cost of using a custom domain, the way I have been dragged into using one certainly put me off Auth0 as a long term solution for my business.
The bottom line is that Auth0 does not offer ANY single tutorial that works under all famous browsers (Safari !) and makes use of the free tier.
We are moving towards a privacy focused web, where third party cookie blocking is something perfectly reasonable, as shown by the latest privacy measures taken by Apple.
I will now go back to the docs to find a way around using a custom domain. I wish the experience had been transparent and straightforward.
It would have been a lot more enticing, had I been told about how a CD would translate in decreasing of rebound rate, for example. But instead, I feel like I have been duped by a lame car sales guy.
Update : According to this doc, it seems that the only way to be enable a user to refresh the page on Safari is to use a custom domain.
Hi @stanislasdrg, thanks for your input! I saw that youāve created another topic here about this concern, thank you for doing so to surface it more broadly. I hope that the responses in that topic are helping to clarify.
Regarding your response to this particular topic, it sounds like one of your concerns / pieces of feedback is to ensure that our documentation is aligned and clear. We will certainly take a closer look at the docs that you linked in the other topic to verify the guidance there is aligned and correct.
Authentication & authorization are confusing and hard to grasp for newcomers. Adding an extra layer of complexity completely ruins the experience.
This is also important feedback that is echoed above by others in this topic. Weāll continue to work to improve our resources for folks who are looking to get up and running quickly!
Hello @stanislasdrg, I wanted to let you know that our Docs team is currently reviewing the docs that you cited in your other topic. Weāre also working on putting together a blog post applicable to this scenario, and I have submitted your feedback here to our Product team as well.
Thanks again for your feedback!
Continuous Integration within Auth0
For us, weāve managed to get a beautiful SSO implementation into Production with shared users spanning our 3 SaaS applications, and simultaneously enabling Social authentication channels for our users. This has been a massive win for us and our customers, and weāre on to the next step: Running down edge cases that we didnāt udnerstand we needed to cater for in our original Solution Architecture.
As weāre a Continuous Integration shop, we really liked the Tenant concept that Auth0 offers, as we have PreProduction tenants that align with our Integration and Staging environments, with us manually maintaining Configuration (Applications, Connections, Rules, Hooks etc) across these tenants/environments.
Now that weāre post-Go Live, the main thing weāve noticed we missed in our CICD research for Auth0 was the ability to pull a snapshot of Users and User Metadata from a Production Tenant into our PreProduction tenants. So here we go:
CURRENT STATE - Weāve successfully gone live with Auth0 and have both Production and PreProduction tenants where we have manually processes that mirror the configuration between these environments.
CHALLENGE - Our CI/CD pipeline has a requirement for all internal systems to have a like-for-like PreProduction environment. Currently our PreProduction tenant matches our Production tenant in configuration (due to our manual process) but diverges in Users and User Metadata ever since launch. This divergence of Users and User Metadata causes problems with our automated testing when introducing change, as well as replication of Production bugs in PreProd when replicating issues specific to individual users.
GOALS - Duplicate the Users and User Metadata from the Production tenant with a target PreProduction Tenant . This is most practical as a point-in-time snapshot that we replicate into the PreProduction tenant, which weāll manually trigger when performing a rebuild of our Staging environment with Production data.
NOT GOALS
QUESTIONS
Hi @lee3, thanks for your input! Since this is a larger conversation with a few questions, Iāve moved it to its own topic so we can respond more thoroughly there. Can you please follow this topic to continue this discussion? Continuous integration within Auth0 Thank you!
Hi @andersthorbeck, I wanted to follow up on this conversation to let you know that weāre rolling out RBAC to Auth0 customers (all tiers) throughout this week. The docs for RBAC have been released, so if you would like to check them out now, you can do so here: Authentication and Authorization Flows Keep an eye out for a notification in your Dashboard!
Hello Kim,
thank you for your kind reply.
I have to reckon that I received great advice in the other topic that I have created, which mitigated my initial opinion of Auth0.
While I am here, I would like to submit two more suggestions for the Angular docs :
1- The authentication flow is organised around a user clicking on Login and Logout within a SPA.
However, most companies have a login / subscribe on a static website, which redirects to the SPA.
As a result, the SPA needs to automatically redirect a user to the login. This flow is more complex to handle. It would be nice to have such an example in Github.
2- Could you make the way of logging out more obvious for a user in the angular docs ?
The Angular code example in Github merely logs a user out of the application, but does not close the Auth0 session, which enables the user to relogin on page refresh when doing the flow described in 1.
Many thanks for your help.
S
Hi @stanislasdrg, Iām glad we were able to help in the other topic!
Regarding your other suggestions:
However, most companies have a login / subscribe on a static website, which redirects to the SPA.
Iām happy to say that our Content team is currently working to craft a blog post covering this scenario: a SPA living on the same domain as a backend, with the backend handling authentication. There will be a blog post and associated repo demonstrating this; @steve.hobbs is working on it with @Vittorio now!
Could you make the way of logging out more obvious for a user in the angular docs?
Thank you for catching that and bringing it to our attention! We will get this clarified. I assume you are referring specifically to the Quick Start section here? There should be a localLogout (similar to the localLogin) and a call to the web auth instanceās logout method. Thanks for letting us know!
Here are things that I still not clear about, after 3 weeks researching auth0
Whatās the relationship between and Application and API
Whatās the difference between scope and permissions
Whatās the point of creating a SPA app in this page? Auth0 Configuration (SPAs + API).
Because I see that another M2M app will be created automatically after creating an API, I have no idea why we have to create this. And then of course, I wonder how these 2 apps would connect to each other?
In the next step, API and SPA Configuration (SPAs + API), the docs tells me to input clientId, but currently I have SPA and M2M app, which clientId should I input there.
I think there should be a better document for troubleshooting, with symptom, and solution. In my case, I installed Authorization extension, and cannot get userās ārolesā, and āpermissionsā, while āgroupsā work fine. I cannot find any docs that could solve my problem, also not understanding the root cause.
What would happen if the name of permission in Authorization extension doesnāt match the scope name in API?
Hello @huyennbl! Youāve cited several very specific questions in your response, so I can address a few of them inline here, as some of the answers are already available. For one question, I created a separate topic.
Whatās the relationship between and Application and API
The relationship between Application and API is summarized in the first sentences of the Overviews of the linked docs on Applications and APIs.
Whatās the difference between scope and permissions
This reply should help to clarify this: Can Users be tied to a Scope? - #2 by kim.maida
Whatās the point of creating a SPA app in this page? [ā¦]
This question is best answered in a separate topic. Iāve created a new topic here: SPA API architecture scenarios clarification Please subscribe to / follow that topic.
I think there should be a better document for troubleshooting, with symptom, and solution. In my case, I installed Authorization extension, and cannot get userās ārolesā, and āpermissionsā, while āgroupsā work fine. I cannot find any docs that could solve my problem, also not understanding the root cause.
(See next answer on RBAC)
What would happen if the name of permission in Authorization extension doesnāt match the scope name in API?
This question is somewhat related to your first question about the difference between scopes and permissions. Please check out the response to the first question for more information on this. In addition, we are currently in the process of rolling out our new Role-Based Access Control (RBAC) feature to all customers (watch for a Dashboard notification). This feature will hopefully help to clarify and ease some of the confusion you may have experienced around using the Authorization extension in the past. You can check out the RBAC docs here.
Re. Angular tutorials : They rely extensively on default routes for App logic.
Usually default routes are used for error handling. It creates some unnecessary overhead.
Hi @stanislasdrg, Iām not sure what the context is of your last comment:
Re. Angular tutorials : They rely extensively on default routes for App logic.
Usually default routes are used for error handling. It creates some unnecessary overhead.
What are you referring to when you say āthey [rely on default routes]ā? This may be a discussion better suited for its own topic. Can you create one with more specifics? Thanks!
Also, as a follow-up to your feedback about the lack of tenant logout in the tutorial, our Developer Experience team is currently working through the Quick Starts to add tenant logout to all tutorials. The Angular tutorial is one of those that is currently on deck for an update. Thanks again for raising that!