big-kahuna-burger / f0 Goto Github PK

1. Changing from m2m/web into native/spa => not allowed
2. Changing from native/spa into m2m/web => allowed, to be followed up with issuing a secret for a client and (maybe?) adding client_credentials to grant_types.

Token Endpoint Method is nonsecretive when token_endpoint_auth_method is one of (private_key_jwt, none, tls_client_auth, self_signed_tls_client_auth)
Corresponding default grant types: implicit (?), authorization_code, refresh_token

Token Endpoint Method is a secretive when token_endpoint_auth_method is not in above set.
Corresponding default grant types: implicit (?), authorization_code, refresh_token, client_credentials

Right now, there is only single identity connection.
This DB.
So Account,PasswordHash,Identity models are all in single schema.
See the schema layout and disjunct the schema into base schema plus password bound connection/s schemas parts.
Query appropriately.
Ideally N are needed, so something like making/destroying parts of schema for password bound connections on the fly needs to happen with DB server.

A nicer looking light theme.
Right now I just use dark in development, but it should be switchable and also have ability to follow system applied colour scheme.

A Management API token should have permissions built in and enforced at v1/manage router, returning 403 then token has insufficient scope.

Additional context
Consider declarative api like fastify-guard, built in is the preferred way of implementation.

• Implement adding jwks to oidcClient on load by library

• storing of n jwks per client when auth method is private_key_jwt
  (RSA 2-4K as PEM/JWK formatted, or X509 cert as PEM/JWK formatted)
  Translate everything into JWK and show diff format on demand.

• Endpoint to accept PEM or JWK for clientId

• Render Credentials when private_key_jwt

• Credential Actions full cycle

Implement custom connections to other third party OIDCs that expose metadata

• Based on a OidcClient -> ClientConnection -> Connection relation, there will be 0 to N Connections enabled for a client

Given this fact:

• Implement dynamic connections loading in the login interaction and dynamic plugin mounting the relevant connection configurations, start with Google as first alt example that can be enabled/disabled
• Implement error when it's 0 saying "Client disabled" or something

Implement a connection Tester on connections/iD component

All manage/v1 are lacking param validations

Finish this UI, wire up in OIDC Api side the effects later

Drop react-scripts in favour of vite.

Implement Social Connections strategies starting with Google and Github

Implement custom custom connection to other IDPs using SAML protocol and expose SAML IDP federation metadata.

1. Connection parameter

There is no standard auth parameter for connection property, but rather it needs a support trough a extraParams prop with oidc-provider library.
See docs

2. Given a client_id during GET interaction/:uid call, the login screen needs to be dynamic based on following:

• Load all possible connections for this client and (it's just a DB/internal strategy for now, until social / external IDP/SAML gets implemented)
• If at least one of those connections has a disabled signup, then the login screen has a disabled signup.
• If all of those connections have enabled signup, then oldest one is selected as registration target based on the creation timestamp.

3. For a specified connection (connection parameter implemented and client has passed a specific known connection name (id?) in the prop):

• Load that connection, see if it's enabled for a client, similar to (2.). In case it's disabled - give RP error with description specified connection disabled for a client

Maybe not that useful...