Projects and approval

A project identifies the product that will consume Identity. Create a named owner and request each environment separately. Approval of a management project does not automatically register an OIDC client with the owned Go issuer.

Prepare a request

Decide whether the application is a confidential web backend or a public native app. Record its owner, purpose, exact callback URLs, requested scopes, environment, and the local Institution mapping it will use. Keep staging and production credentials separate. A web callback uses HTTPS outside disposable loopback development. Native callbacks must match the reviewed platform profile exactly. Wildcards and anonymous dynamic registration are not supported by the reviewed management flow.

Project owners can inspect GET /v1/projects/{project_id}/registration-context and GET /v1/projects/{project_id}/environments with an authorized management token. GET /v1/registration-context reports the configured environment and issuer. A missing or inconsistent deployment binding returns 503. These responses describe the management deployment currently serving the request, so verify they match your intended issuer before proposing or approving a client.

Owned project-client review

An approved project is the context for a separately reviewed permission catalog and exact owned-client policy. The project owner proposes each immutable revision, and a different current project approver reviews it. The project detail page shows the exact client version, URI/audience policy, catalog permissions and registration digest. Client approval remains approved_pending_readback; the reviewed private registration writer must later prove the exact Go installation before it becomes usable. See register a client.

Person access is another decision. Independently reviewed sponsor and administrator authority must bind the exact beneficiary and Access version, and neither reviewer may be the beneficiary. Product acknowledgement is required in addition to those reviews. A project, catalog or client approval does not itself grant a person access.

Inspect current authority

Open the project admin page to inspect its lifecycle acknowledgement and reviewed client authority observations. The same bounded read is available through GET /v1/projects/{project_id}/authority-status, using a backend-held Management access token. It is scoped to the current project owner or authorized project approver and exposes no credentials or private signed artifacts.

Check each fact separately. A recorded source acknowledgement is historical; a source grant can expire; an activation request is an intent. None proves that Go activated the registration or that a person can sign in. An unavailable status view means the facts could not be confirmed. Restore the Management connection and reread the status before making an access decision.

Legacy environment review sequence

1. An authorized owner proposes an environment at POST /v1/projects/{project_id}/environments with a unique Idempotency-Key, a reason, exact callbacks, and scopes. A confidential web proposal body has this shape:

{"name":"staging","client_type":"confidential-web","redirect_uris":["https://app.example.test/callback"],"scopes":["openid","profile"],"reason":"Initial staging integration review"}

The API also accepts development, production, public, and the fixed native Mail client types, subject to deployment policy. Web scopes here are openid, profile, and email; openid is required. The Go issuer’s refresh-token offline_access behavior does not yet make it an approved management registration scope. 2. A different live project approver checks the proposal and approves it through the environment approval route. 3. The worker reconciles external delivery. A pending or approved record does not prove the client is usable. Confirm the effective state and exact issuer binding. 4. For a confidential client, the authorized owner uses the one-time credential reveal flow. Store the secret in a server-side secret manager. Rotation is a separate reviewed action.

The current worker delivery path is part of the legacy migration boundary. The owned issuer now exercises two distinct synthetic confidential registrations in its mounted browser acceptance. That test does not convert a legacy environment approval into a reviewed owned-client registration. Use the separate owned policy review and later signed readback gates.

Verify before traffic

Check OIDC discovery at the approved issuer, exact redirect matching, PKCE S256, token audience, and the product’s lifecycle service identity. Do not use a staging client or issuer for production. See register a client for the profile details.