Configure an Application

An application (client in OAuth language) that should use Authway to sign-in an end-user or to make system-to-system calls must be configured first. The configuration can be quite daunting, but Authway makes it easy to get started with the most important settings when creating a new application. For now, this guide will only contain the most important aspects of configuring different type of clients and it expects the reader to have read at least the Getting started documentation.

Before configuring a application, you need to decide what kind of application you have created (or shall create). The common ones are:

  • Single Page Application (SPA) - Javascript
  • Web Application - Server side
  • Native Application - Mobile/Desktop
  • Machine/Robot (or system-to-system)

New Client.png New Client.png

All clients must have a client id and we recommend that you decide on a naming convention to follow. We typically use descriptive names with a namespace prefix where each prefix is separated with a dot (".").

Machine/Robot

The Machine/Robot template should be chosen when you have a scenario where a system (client) makes a call to a (resource) server. Authway supports both the classic system-to-system (client credentials) scenario, but also extends that scenario with support for External system. If you want to configure an External system you should read this instead.

For a more classic system-to-system scenario you typically only need to supply a client id and a name. Then on the details of the system you must create a secret (see below about client secrets).

Single Page Application (SPA) - Javascript

Even for a SPA it will be more secure to create a backend for frontend, so that sign-in can be performed as for a Web Application - Server side. The reason for this is that otherwise the access token will reside in the end-users browser and there are no really good way to protect a token in the browser. On the contrary the development around protection of browser cookies have now reached a maturity level that makes them a more secure option and then storing the access token only in the backend. The backend for frontend will typically work as a proxy to the real backend API and exchange the cookie to the access token when passing the call to the API. This will also remove the need to use CORS.

For a SPA you will typically have to configure a client id, client name and URLs for both CORS and redirections. Never create a secret for a SPA client, because if that secret should be used it must be send to the client browser and then it is not a secret anymore.

The CORS URL should be your domain name (incl port if not standard ports are used) without any slash ("/") in the end. The redirect URL must be the exact URL that your client send in the redirect_uri parameter.

On the “Basics” tab you can edit if PKCE is required or not depending on the support in your client implementation.

Web Application - Server side

Web Application should be chosen for all type of web applications that have some kind of backend that can trigger the sign-in flow. This is the most secure type of application for the web. For this scenario you will need to supply a client id, name and redirect URL. The redirect URL must be the exact URL that your client send in the redirect_uri parameter. Then on the details of the system you must create a secret (see below about client secrets).

On the “Basics” tab you can edit if PKCE is required or not depending on the support in your client implementation. If you want to allow the client to request refresh tokens this setting is also configured on the same tab.

Native Application - Mobile/Desktop

Native applications will more or less be configured like a Web Application with client id, name and redirect URL. In this case the redirect URL will not be on the http protocol, but rather something else that you interrupt in the client and continue the flow yourself in the application (instead of in a backend). As always with redirect URL:s it must be the exact URL that your client send in the redirect_uri parameter.

If you have the possibility to protect a client secret in a secure way we recommend that you create a client secret and use it. If you can’t, then there is no meaning in creating a client secret. In the “Basics” tab you can edit if a client secret is required or not.

Client Secrets

A secret can be created and administered on the “Secrets” tab of the client. When a new secret is created, it is displayed directly in the user interface and then it is important that it is copied and stored securely for the client. Authway will not be able to show the value of the secret again (in the same way that passwords cannot be displayed). This means that if the secret is lost, a new secret must be created. When a new secret is created, the old secret should be deleted or given an expiration date. The latter should be used if you want to change your secret in a controlled manner without getting any interruption.