Breaking Changes for a major version

This is a list of things that can be subject to change on a future major version upgrade, and can therefore break existing applications. A migration path will have to be prepared for each of them, or at least a warning.

• General
  • ditch top-level oauth feature, rename oauth_base to oauth, promote features to top-level.
  • create oauth_authorization_server and oauth_resource_server plugins.
  • prefix all optional routes with load_ (or suffix with _routes) ex: r.load_oauth_applications). It would have been useful to have oauth_applications returning the dataset, and we can't use it because name's already attributed.
    • alternatively, try to built-in this feature in rodauth.
  • supported grants set via explicit features set-up (instead of use_<grant>_grant_type? options).
• Security
  • refresh token protection policy becomes "rotation" by default (OAuth 2.1);
  • refresh token expiration time will be independent of the access token expiration time;
  • tokens won't be able to have clear text access and refresh tokens (and client secrets) by default;
    • legacy clear text tokens will be migratable;
  • (to explore) there will be a separate tokens strategy with a separate table and db-level AC policies, similar to how rodauth handles passwords by default; tokens aren't exactly passwords, but the idea here is to explore how to hide lookups, so potential attackers can't associate stolen tokens with the scopes or owners;
  • PKCE setup will be strict by default (OAuth 2.1);
  • remove oauth_tokens table; tokens become a column from oauth_grants;
  • oauth_token_subject should be set per grant type;
• Renaming
  • s/invalid_oauth_response_status/oauth_invalid_response_status/g;
  • s/already_in_use_response_status/oauth_already_in_use_response_status/g;
  • oauth_ prefix in error message options;
  • s/oauth_jwt_token_issuer/oauth_jwt_issuer/g;
  • s/oauth_application_jws_jwk_column/oauth_applications_jws_jwk_column/g;
• OAuth Application
  • remove oauth_application_default_scope option;
  • oauth application selects their own default set of scopes, which get loaded on grant set-up/forms;
    • tokens can have a subset of the application scopes;
• JWT
  • create oauth_jwt_base, with JWT infrastructure (encode/decode, etc)
  • create oauth_jwt_access_tokens; when enabled, access tokens are JWT;
    • should allow having "hybrid" OIDC integration with db access tokens and JWT ID Tokens;
    • think about what to do with refresh tokens (they're not JWT yet either);
  • remove oauth_jwt_audience and oauth_jwt_issuer (to be per-application);
  • (to explore) jwt verification claim: aud verification involves db comms (unless oauth_jwt_audience is set). Maybe find a way to work around that.
  • Make oauth_jwt_keys, oauth_jwt_public_keys, etc the only way to configure keys (discontinue the singular and legacy options);
• OpenID
  • separate auth_method "oauth scopes" from "openid scopes";