# 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](/quickstart/sign-in). ## 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. | Type | Kind in the console | For | Holds a client secret | Signs in with | | -------- | ----------------------------- | ----------------------------------------- | --------------------- | ------------------------------------------ | | `web` | Web application | A web app with a server | Yes | Authorization code, with its client secret | | `spa` | Single-page app | An application that runs in the browser | No | Authorization code with PKCE | | `native` | Android app, iOS or macOS app | A mobile or desktop application | No | Authorization code with PKCE | | `m2m` | Machine-to-machine | A backend service calling another service | Yes | Client credentials | 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](/applications/machine-to-machine). ## 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. | Parameter | Accepted value | | ----------------------- | ----------------------------------------------- | | `code_challenge_method` | `S256`. If you leave it out, `S256` is assumed. | `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. | Registered | Accepted | | ------------------------------- | ---------------------------------------------- | | `http://127.0.0.1` | `http://127.0.0.1:53124/callback`, on any port | | `http://localhost` | `http://localhost:3000/callback`, on any port | | `https://app.acme.com/callback` | That URI only | 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](/concepts/access). ## 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 Sign a person in with the authorization code flow and PKCE, step by step. Keep a person signed in, sign them out, and require multi-factor authentication. Use the client credentials grant type from a machine-to-machine application. Every parameter and response of every endpoint an application calls.