Security Considerations

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.

Implicit Grant flow off-by-default

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 use_oauth_implicit_grant_type? to true).

Response Mode as form_post

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.

Resource Owner password and Credentials grant flow unsupported

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 lax-enabled (as long as you set the columns)

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.

Secure defaults

Wherever possible, settings default to lower-denominator-but-still secure default:

  • JWT signing algorithm defaults to "H256" instead of "none";
  • PKCE challenge method is defaults to "S256" instead of "plain";
  • Accepted Redirect URIs default to https- only;

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_token_hash_column and oauth_tokens_refresh_token_hash_column settings. This can change in a future version, though).