Context
Hosted Authsome currently treats OAuth provider client configuration as admin-owned shared state: an ADMIN must configure client_id and client_secret before a USER can connect to that OAuth app. That rule makes sense for static OAuth apps because the OAuth app credentials are deployment-level configuration.
DCR providers are different. For notion_dcr, the provider supports Dynamic Client Registration, so Authsome can register a client during the login flow without any preconfigured admin-owned OAuth app credentials.
Observed behavior
On api.authsome.ai, a USER account cannot complete notion_dcr login when no provider client record exists yet. If an ADMIN logs into notion_dcr first, the generated DCR client is persisted, and USER accounts can then log in successfully.
This effectively makes DCR depend on prior ADMIN initialization, even though DCR is supposed to avoid preconfigured client credentials.
Design question
How should Authsome model provider-client ownership for DCR flows?
One possible policy:
- Static OAuth client config (
pkce, device_code) remains ADMIN-owned.
- DCR-generated client records are system/protocol-generated and may be initialized by the first USER login when no client exists yet.
- USERs may not manually submit
client_id, client_secret, base_url, or replace an existing shared provider client.
- Replacing, revoking, or rotating an existing DCR client remains ADMIN-owned because it affects shared deployment state.
Things to decide
- Should a DCR-generated
ProviderClientRecord remain server-scoped, or should DCR clients be scoped differently?
- If USER-triggered DCR initialization is allowed, should the record include metadata such as
source: dcr, registered_by_principal_id, or registered_by_identity?
- Should the UI expose DCR providers differently from static OAuth providers so USERs are not blocked by missing admin configuration?
- Does this policy apply to all DCR providers or only bundled trusted DCR providers such as
notion_dcr?
Related implementation area
src/authsome/server/credential_service.py::save_inputssrc/authsome/server/credential_service.py::resume_login_flowsrc/authsome/auth/flows/dcr_pkce.pysrc/authsome/auth/bundled_providers/notion_dcr.json
Context
Hosted Authsome currently treats OAuth provider client configuration as admin-owned shared state: an ADMIN must configure
client_idandclient_secretbefore a USER can connect to that OAuth app. That rule makes sense for static OAuth apps because the OAuth app credentials are deployment-level configuration.DCR providers are different. For
notion_dcr, the provider supports Dynamic Client Registration, so Authsome can register a client during the login flow without any preconfigured admin-owned OAuth app credentials.Observed behavior
On
api.authsome.ai, a USER account cannot completenotion_dcrlogin when no provider client record exists yet. If an ADMIN logs intonotion_dcrfirst, the generated DCR client is persisted, and USER accounts can then log in successfully.This effectively makes DCR depend on prior ADMIN initialization, even though DCR is supposed to avoid preconfigured client credentials.
Design question
How should Authsome model provider-client ownership for DCR flows?
One possible policy:
pkce,device_code) remains ADMIN-owned.client_id,client_secret,base_url, or replace an existing shared provider client.Things to decide
ProviderClientRecordremain server-scoped, or should DCR clients be scoped differently?source: dcr,registered_by_principal_id, orregistered_by_identity?notion_dcr?Related implementation area
src/authsome/server/credential_service.py::save_inputssrc/authsome/server/credential_service.py::resume_login_flowsrc/authsome/auth/flows/dcr_pkce.pysrc/authsome/auth/bundled_providers/notion_dcr.json