rodauth-oauth ships with defaults as secure as possible. In fact, security is a design goal, and something that should be done right from the get-go, for every feature shipped. This is a section of recommendations for your rodauth-oauth configuration.
The OAuth 2.0 authorization framework RFC refere implicit grant as one of 4 described authorization flows, and its usage is quite widespread. However, as per the Threat Model and Security Considerations, there are a few reasons why you wouldn’t want to expose this option unless you are aware of its implications). So do not enable th oauth_implicit_grant unless you have a good reason to.
form_postEavesdropping of authorization codes is one of the attack vectors described in the RFC. Although the default authorization code strategy is considered the most secure strategy, delivering it via a GET request param poses its own set of risks; p.ex. a client application might not do a proper chain of redirections and leave the redirect URI with the authorization code in a referrer to a 3rd party, among other examples described in the URI. The safest way to avoid this is to perform the delivery of the authorization code via a POST request to the redirect URI, which is what the form_post response mode is for. Consider therefore making it the only way to communicate grant codes to the 3rd party applications:
plugin :rodauth do
enable :oauth_authorization_code_grant
oauth_response_mode "form_post"
The Resource Owner Password Grant flow isn’t implemented. The reason is that it’s insecure (“leaks” user credentials to the client application), and isn’t as much of a common case as the implemented counterparts, therefore less interesting to implement. I won’t be against anyone contributing an implementation though.
PKCE is an important security feature, specially if your clients are mobile applications, but its benefits aren’t only exclusively for the mobile app case. Hence why, when the oauth_pkce feature is enabled, using PKCE codes is, by default, the only way to authenticate usage of the token endpoint.
If you want to support other authentication methods such as "client_secret_basic" as well, you have to set oaauth_require_pkce to false.
rodauth-oauth defaults aim at being “secure by default”. Some examples:
"none" is not a supported client authentication method by default (you have to set it explicitly);"none" is not a supported response type by default (you have to set it explicitly);"none" is not a supported algorithm for JWT bearer;"S256" instead of "plain";https- only;All of these defaults can be changed.
(access/refresh token columns are hashed by default when stored, and you have to set the oauth_tokens_token_hash_column and oauth_tokens_refresh_token_hash_column options to nil to explicitly disable that behaviour.