Auth0 Home Blog Docs

What is the #1 concept you wish you understood better in auth?

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?

3 Likes

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).]

3 Likes

@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 :slight_smile:

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.

3 Likes

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.

1 Like

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:

  • Setting up rules seems straight forward to me, now… but a few days ago I was tearing my hair out.
  • Same for logout?returnTo - setting up the Allowed Callback URLs in Tenant settings (not Dash > Applications) also responsible for my receding hairline.
  • Requiring email verification is still vexing me - and this seems to be a common pain point that remains un(satisfactorily)documented. I have a rule but #clunky.

Hope it helps

1 Like

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!

1 Like

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.

2 Likes

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!

1 Like

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.

1 Like

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

  • No need to replicate passwords, Auth0 ID or other data that we cannot reasonably access or control. Our CICD architecture will obviously just have to work around these limitations
  • No need to make this real-time, we’ll just kick this off when we need to refresh User Content in a given PreProduction tenant
  • No need to synchronise configuration (Applications, Connections, Rules, Hooks, Emails etc) as part of this solution, given the rate of change here is low and we can do this by hand without too much overhead

QUESTIONS

  1. Does Auth0 have any established best practice for us to try and reduce the distance between our Prod and PreProd tenants for companies building and maintaining a CI pipeline?
  2. Does Auth0 have any existing tools that will assist us to achieve this?
  3. There are definitely Auth0 customers that are trying to achieve similar goals to this. Can you point us to any examples, or any libraries they have developed?
1 Like

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!

1 Like

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: https://auth0.com/docs/authorization Keep an eye out for a notification in your Dashboard!

1 Like

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

1 Like

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? https://auth0.com/docs/architecture-scenarios/spa-api/part-2#define-permissions.
    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, https://auth0.com/docs/architecture-scenarios/spa-api/part-3, 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?

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.

1 Like

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!