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 comments explaining certain options, omissions, and defaults.
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, hence why this is turned off by default (you can overrun this by setting
Go to this page to learn how to use it.
Eavesdropping 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.
Both the Resource Owner Password Grant flow as well as the Credentials Grant Flow aren’t supported. Yet, The reason is that both of them are very insecure (the former “leaks” user credentials to the client application, the latter bypassed the user permission to access its resources), and aren’t as much of a common case as the two implemented counterparts, therefore less interesting to implement. I won’t be against anyone contributing an implementation though, provided that they’re off-by-default just like “Implicit Grant”.
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
rodauth-oauth tries to reduce friction to turn on the feature by having it on, the user only needing to associate the db columns to the grants table.
Usage of client secrets will still be allowed though, so if you want PKCE-only token generation, you’ll have to set
oauth_require_pkce to true.
Wherever possible, settings default to lower-denominator-but-still secure default:
Of course, you can always set them to be more insecure, but then you’re on your own.
(Sadly, access/refresh token columns aren’t hash-by-default, and you have to set the
oauth_tokens_refresh_token_hash_column settings. This can change in a future version, though).