Application types and redirect URIs

Choose between the four application types, and learn how AuthFI matches a redirect URI and decides who can sign in to an application.

An application is anything that signs people in, or signs in as itself. You register each one in Integrations > Applications in the AuthFI console. The kind you choose there sets the application's type, which decides whether it holds a client secret and which OAuth grant type it uses.

This page explains the types, and the rules that apply to every application: how a redirect URI is matched, who can sign in, and which groups the application sees. To register your first application, follow Add sign-in to an app.

The four application types

The type follows from where your code runs. Code on a server can keep a secret. Code in a browser or on a person's device cannot, because anyone can read it there.

In the console, the kinds are offered when you choose Register on Integrations > Applications and select OIDC / OAuth 2.0. A web application or a single-page app then asks for a Name and its Redirect URIs, one per line. A machine-to-machine application asks for a Name only.

The first three types sign people in with the authorization code flow. The person signs in on your project's sign-in page, and your application receives a one-time code that it exchanges for tokens.

An m2m application has no person to sign in. It signs in as itself with the client_credentials grant type. Only an m2m application can use that grant type. An application without a client secret is rejected with invalid_client, and a web application with unauthorized_client. See Get an access token for a backend service.

Client ID and client secret

Every application has a client ID, the public identifier it sends with each request. AuthFI generates the client ID. You do not choose it.

A web or m2m application also has a client secret, which proves that a request comes from your application. The console shows the client secret once, on the last step of registration, and asks you to tick I have copied the client secret before you leave the step.

If you lose the client secret, rotate it. On the application's page, open the Credential section and choose Rotate the secret, or choose Rotate the client secret in the More actions menu. The new client secret is shown once, and the old one stops working at once.

An application with a client secret sends it to the token endpoint as HTTP Basic authentication, or as client_secret in the request body. An application without one sends its client_id only.

PKCE

PKCE (RFC 7636) ties a sign-in to the application that started it. The application creates a random value, the verifier, and sends only its SHA-256 hash, the challenge, when it sends the person to sign in. To exchange the code for tokens, it must present the verifier.

PKCE is required for an application with no client secret, because it is the only proof that the code is being exchanged by the application that asked for it. An application with a client secret can use PKCE too.

S256 is the only method. plain is rejected.

How a redirect URI is matched

A redirect URI is the URL in your application that AuthFI sends the person back to after they sign in. You enter an application's redirect URIs in the Redirect URIs field when you register it, one per line. To change them later, open the Credential section of the application's page and choose Edit registration. Your application names one of them in redirect_uri on each authorization request.

The redirect_uri you send must be exactly one of the registered URIs: the same scheme, host, port, path and query. A wildcard does not match, so register each URI in full.

There is one exception, for applications under development and native applications (RFC 8252). If you register a loopback URI with no port, AuthFI accepts any port on it. A native application can then listen on whichever port is free.

When redirect_uri does not match, AuthFI answers with a 400 error on your project's issuer, the project's own URL. The browser is never sent to a URI that is not registered.

Who can sign in to an application

An application is open to everyone in the project until you assign it to a group. From the first assignment, only members of the groups assigned to it can sign in to it. Anyone else is denied with access_denied and the message you are not assigned to this application.

You assign groups on the application's page, with Assign a group. The groups are listed in the Who can open it section.

AuthFI checks the assignment when the person is sent to sign in, and again every time it issues a token. When you remove someone from a group, the change takes effect at their next token.

For the model behind assignments, see Roles, groups and grants.

Which groups an application sees

The groups claim in a token does not list every group a person is in. It lists the groups that are assigned to the application, or shared with it. An application never learns of groups that have nothing to do with it.

Next steps