We just completed our first “Building a B2B SaaS App with React and Auth0.js” workshop, hosted by Mark Vong (Solutions Engineer at Okta)! The workshop was designed for anyone looking for best practices around:
- Managing business users and their permissions,
- Customizing the authentication experience for everyone,
- And extending the ability for businesses to manage themselves.
Q&A
Here is a summary view of some of the questions that were addressed during the Q&A:
- How do I use Auth0 with frameworks or languages that don’t have supported SDKs?
- If a framework or language isn’t supported in our publicly documented library, our REST APIs are readily available for developers to build around and provide wrapper libraries for. More info here. To double check our code samples: Auth0 Authentication and Authorization Code Samples
- Can I create custom roles and permissions that pertain to the application?
- You can create custom roles. Permissions are keyed to a specific API, and hence automatically pertain to a specific application. Association between an API and an application is entirely dependent on the implementation team. Unless it’s a M2M application, there is no direct connection between a defined API and an application. This connection would have to be represented as logic contained in an action (i.e, this user logged in to an application with client_id ‘xyz’ and therefore must have these set of permissions returned in the JWT(s)). For M2M applications, we can explicitly assign permissions/scopes pulled from APIs.
- What’s the best way to grant our customer success/admins access to a user’s credentials?
- The most secure way to do this is to have a separate application just for administrators – only admins can login to it, and they can perform tasks (as admins) but on behalf of users. We typically encourage our customers to leverage this implementation of a companion application that can be fitted with features as needed. Please note that user impersonation can lead to serious security concerns: When User Impersonation Features In Applications Go Bad | Trustwave
- How would I know if my end users have upstream MFA?
- Some identity providers provide the context that a user has completed an MFA step as part of their login. This is typically in the form of an ‘amr’ claim if going through OIDC. If the IdP provides this context, then Auth0 can capture that and, using an Auth0 Action, decide not to prompt the user for MFA. However, if you configure Auth0 to just always prompt for MFA, the user would be prompted for MFA twice. Once to login to the IdP and once to login to the application.
- What is an Auth0 Application vs my application?
- An Auth0 application is typically used to represent the client that will be acting on behalf of a user requesting permission to access services. An Auth0 application is usually synonymous to your application where your application (a SPA, RWA, Native App) is the UI your end users are interfacing with. However, there is also the Auth0 application type of a M2M app that is representative of a machine that would require access tokens for authorization requests against other services, typically representative of microservices or IoT devices. More info: Applications in Auth0.
- What is the recommended best practice around databases?
- When you create an MVP for your product, you might only have one database (e.g. the Auth0 User Store). Over time, as your product becomes more complex or you integrate with other tools that provide their own databases (e.g. CRMs), you may need to handle multiple databases. In these cases, you would host the user records on the separate databases using a property like userId or email address to tie the records together. You can create a post-login Action with an outbound API call to pull in information about the specific user dynamically, matched by a property like the userId or email address.
- Could you provide some info about the verification of a token once it’s recovered by the frontend and forwarded to the backend e.g. when the address of the backend is different from the one of the frontend if it changes anything?
- There are two tokens provided. The ID token is intended for consumption by the frontend – it has the authentication information and contains information about who the user is. The access token is intended for consumption by the backend – it controls the authorization piece and has Information about what the user is permitted to do within the context of the app. Validation of these tokens should be accomplished with our SDK’s – either on the client side or on the server side. But please be careful… The frontend app (e.g. in a web browser) is a hostile security environment. You should not provide any secrets to a web browser, like in an SPA (single page application). Learn more about validating tokens: Validate Access Tokens
If you have any additional questions, please feel free to add them to this thread!