Client Registration

Client registration defines the trust boundary between OpenASA and your application or service.

Role split

Role	Responsibility
OpenASA	OAuth Provider / auth service
Your app or service	OAuth client / relying party
End user	Account owner who signs in through OpenASA

Required Client Metadata

• client_id
• trusted redirect_uri list
• allowed scopes
• token handling policy on your backend
• local user mapping strategy keyed by stable OpenASA subject

Integration Boundary

If your service wants to rely on OpenASA OAuth capability, the usual split is:

1. Browser redirect or app login is initiated against OpenASA.
2. OpenASA authenticates the user and establishes authorization state.
3. Your service receives OpenASA-issued code, token, session, or user profile.
4. Your service maps the OpenASA user identity into its own local account model.

Recommended Boundary

• Keep user authentication and consent on the OpenASA side.
• Keep your own business authorization and tenant/resource permissions on your side.
• Treat OpenASA sub or stable user id as the external identity key.

Provider-side Agreement Surface

For OAuth capability itself, treat OpenASA as exposing the standard provider-side surfaces defined by the oauth agreement:

• authorize
• token
• userinfo
• jwks
• revoke

Notes

• Register redirect URIs, scopes, and client metadata against OpenASA according to your deployment process.
• Keep callback handling on your own trusted domain.
• Never couple your business authorization model to raw access-token contents alone; always keep a stable local user mapping.