App registration: identity is not permission
An app registration gives a software application an identity so it can sign users in and request access to protected APIs. Think of it as the application's identity card, not a permission slip.
For Phenix Lite, that distinction is practical: identifying the mobile app and authenticating a user are necessary, but neither proves that the app may read that user's financial account.
1. What an app registration defines
Registration, authentication, and authorization answer different questions:
- Registration: which application is this, and how is it configured?
- Authentication: which user or service is making the request?
- Authorization: may that caller perform this operation on this resource now?
A registration typically defines:
| Setting | Purpose |
|---|---|
| Client ID | Identifies the application. It is not a secret. |
| Client type | Distinguishes a public mobile or browser client from a confidential backend capable of protecting credentials. |
| Redirect URI | An exact approved destination for returning an authorization response after sign-in. |
| Allowed authentication flows | Defines how the application obtains tokens, such as Authorization Code with PKCE. |
| Requested API permissions | Describes the capabilities the application wants. Requesting them does not grant them. |
| Ownership and management scope | Determines who can manage the registration in its organization and registration workspace. |
In Ireti, these responsibilities have separate owners:
- Ireti IAM, backed by Keycloak, owns OAuth clients, authentication, and credentials.
- Ireti Platform owns platform permission grants, consent state, and current authorization decisions.
- The product API owns business data and enforces resource-specific restrictions.
The App Registration interface coordinates those responsibilities. It is not another identity authority or a separate source of platform permission truth.
2. Delegated access and application access
Delegated: the application acts for a user
Consider Phenix Lite reading the signed-in user's own balance. Both the application's approved capability and the user's own rights must permit the operation within the intended resource scope. The product must also verify the relationship between the user, financial customer, and account.
For native sign-in, the mobile client uses Authorization Code with S256 PKCE, opening the system browser and returning through its registered callback. A mobile application is a public client: it must not contain a client secret.
PKCE protects the authorization-code exchange. It does not grant API access or make the mobile app a confidential client.
Application: the service acts as itself
A backend job can authenticate without an interactive user. It acts as a service principal, the application's technical identity in the authorization model, with explicitly approved application permissions.
A confidential service commonly uses Client Credentials. Its credentials stay on the server. It does not inherit the personal rights of the administrator who registered it or approved its access.
| Delegated access | Application access | |
|---|---|---|
| Authorized identity | Application and user together | The application's service principal |
| Typical consumer | Mobile or browser application | Backend service or scheduled job |
| Typical flow | Authorization Code with PKCE | Client Credentials |
| Credentials | No client secret embedded in the mobile or browser app | Credentials protected on the server |
| Permission boundary | Approved app capability plus user rights and product restrictions | Explicit service permissions plus product restrictions |
An access token identifies a caller within an intended audience; its existence is not sufficient evidence of current permission. APIs validate the token and enforce the applicable authorization rules.
3. Requesting a permission is not approving it
In Ireti's current permission flow:
Select and save means request access. Grant administrator consent means approve access.
Removing a permission and saving revokes it. Adding it again requests access again and requires fresh consent. A registration can therefore be valid while its API requests remain forbidden.
Administrator consent to an API permission is also distinct from identity consent shown during sign-in. Allowing an app to receive identity information does not authorize it to read a financial account.
The registration workspace, where developers manage the client, can differ from the resource workspace containing the protected data. Permission must explicitly target the intended resource scope; registration ownership is not resource access.
4. Phenix Lite: from sign-in to reading a balance
The native development proof uses a backend-for-frontend, or BFF: a private backend specialized for the mobile application's own-balance operation.
There are two separate authorization boundaries:
- Mobile to BFF: may this client act for this user?
- BFF to Financial API: may this backend service perform the financial operation?
The BFF must not use its own privileges to bypass a denied mobile request. The mobile app never receives the backend's credentials, and the caller cannot select an arbitrary financial account.
APISIX provides the reviewed routes and enforcement boundary; it does not own permission truth. Ireti Platform supplies current authorization decisions, while the product owns customer-account bindings and business restrictions.
Revocation must affect the next request
A signed token can remain cryptographically valid after an administrator revokes permission. Checking only its signature and expiry would miss that change.
In the Phenix Lite development proof, the BFF checks current delegated permission on every read. Removing the permission denies the next read in the existing session, without waiting for token expiry. The mobile app clears any previously displayed balance on denial or read failure.
See From native sign-in to revocable financial access for the bounded Android proof and its acceptance evidence. This example is not a claim of a production rollout or a complete migration of the legacy application.
5. What registration does not do
Creating an OAuth client does not automatically:
- Publish an application in the marketplace.
- Activate it for an organization.
- Create a subscription, entitlement, or seat assignment.
- Grant API permissions.
- Create a financial customer or account.
- Give every signed-in user access to product data.
Likewise, a workspace URL is a selector, not authorization evidence. Managing a registration does not bypass the permissions, entitlements, or seats needed to use an application workspace.
Use separate identities for independently deployed components and environments. Register only the required flows, exact callbacks, and intended audiences, then approve the smallest necessary resource permissions.
Registration identifies the software. Authentication verifies identities. Consent approves requested capabilities. Authorization decides what each request may actually do.