Regular Web Applications

You'll need to define a Regular Web Application if you want to integrate Auth0 with traditional web applications (using technologies like ASP.NET, Java, Ruby on Rails, or Node.js) running on a server.

Navigate to the dashboard and click on the Applications menu option on the left. Clicking the + Create Application button.

The Create Application window opens. Set a descriptive name for your application and select Regular Web Applications.

Create Application window

After you set the name and application type, click Create.

A new Regular Web application will be created and you will be redirected to this application's view that has the four tabs described below.

Quick Start

The Quick Start tab shows all the available examples for Regular Web applications.

Addons

Add-ons are extensions associated with applications. They are typically third-party APIs used by the application(s) for which Auth0 generates Access Tokens. For more details refer to: Addons.

Connections

Connections are sources of users. They are categorized into Database, Social and Enterprise and can be shared among different applications. For more details refer to: Connections. For a detailed list on the supported Identity Providers refer to: Identity Providers Supported by Auth0.

Settings

  • Application Type: The type of application you are implementing. If you're working with a traditional web app that has the ability to refresh its pages, use a Regular Web Applications.
  • Token Endpoint Authentication Method: Defines the requested authentication method for the token endpoint. Possible values are None (public client without a client secret), Post (client uses HTTP POST parameters) or Basic (client uses HTTP Basic).

You can provide up to 100 URLs in the Allowed Callback URLs, Allowed Web Origins, Allowed Logout URLs, Allowed Origins (CORS) fields.

  • Allowed Callback URLs: Set of URLs to which Auth0 is allowed to redirect the users after they authenticate. You can specify multiple valid URLs by comma-separating them (typically to handle different environments like QA or testing). For production environments, verify that the URLs do not point to localhost. You can use the star symbol as a wildcard for subdomains (*.google.com). Make sure to specify the protocol, http:// or https://, otherwise the callback may fail in some cases.

  • Allowed Web Origins: List of URLs from where an authorization request, using web_message as the response mode, can originate from. You can specify multiple valid URLs by comma-separating them. For production environments, verify that the URLs do not point to localhost.

  • Allowed Logout URLs: After a user logs out from Auth0 you can redirect them with the returnTo query parameter. The URL that you use in returnTo must be listed here. You can specify multiple valid URLs by comma-separating them. For production environments, verify that the URLs do not point to localhost. You can use the star symbol as a wildcard for subdomains (*.google.com). Notice that querystrings and hash information are not taken into account when validating these URLs. Read more about this at: Logout.

  • Allowed Origins (CORS): Set of URLs that will be allowed to make requests from JavaScript to Auth0 API (typically used with CORS). This prevents same-origin policy errors when using Auth0 from within a web browser. By default, all your callback URLs will be allowed. This field allows you to enter other origins if you need to. You can specify multiple valid URLs by comma-separating them. For production environments, verify that the URLs do not point to localhost. You can use the star symbol as a wildcard for subdomains (*.google.com). Notice that paths, querystrings and hash information are not taken into account when validating these URLs (and may, in fact, cause the match to fail).

  • JWT Expiration (seconds): The amount of time (in seconds) before the Auth0 ID Token expires. The default value is 36000, which maps to 10 hours.

  • Use Auth0 instead of the IdP to do Single Sign On: If enabled, this setting prevents Auth0 from redirecting authenticated users with valid sessions to the identity provider (such as Facebook, ADFS, and so on).

Application Settings Page

Advanced Settings

The Advanced Settings section allows you to:

  • Manage or add Application Metadata, Mobile, OAuth, and WS-Federation settings
  • Obtain certificates and token endpoint information
  • Set the grant type(s) for the Application

Advanced Application Settings Page

Application Metadata

Application metadata are custom string keys and values (each of which has a character maximum of 255), set on a per application basis. Metadata is exposed in the Application object as client_metadata, and in Rules as context.clientMetadata

You can create up to 10 sets of metadata.

OAuth

Set the OAuth-related settings on this tab:

  • By default, all apps/APIs can make a delegation request, but if you want to explicitly grant permissions to selected apps/APIs, you can do so in Allowed APPs/APIs.

  • Set the algorithm used (HS256 or RS256) for signing your JSON Web Tokens.

  • Toggle the switch to indicate if your application is OIDC Conformant or not.

  • Toggle the Trust Token Endpoint IP Header setting; if this is enabled, the auth0-forwarded-for is set as trusted and used as a source of end user IP information for protection against brute-force attacks on the token endpoint.