I’ll try to summarize some of the reasons I decided to build rodauth-oauth
, which were also the reasons I didn’t go with just picking doorkeeper
.
doorkeeper
is rails-only, meaning, if your application is a rails
monolith, then integrating doorkeeper
will be easy. However, if you’ll want to “break the monolith” along the way, decouple services, you’ll find this a big impediment.
rodauth-oauth
can be deployed as a roda
plugin, a rack
middleware, a rails
plugin (via rodauth-rails
), an “authorization server” microservice, which makes it a very flexible tool as your product grows.
doorkeeper dev group aggregates other gems for handling JWT, OpenID, grant assertions, but they don’t seem to be actively maintained: they’re mostly incompatible with each other, doorkeper-openid-connect is looking for new maintainers, and their documentation isn’t that helpful.
rodauth-oauth
ships and tests all other features built on top of it, guaranteeing that their integration works across versions.
rodauth-oauth
ships more features out-of-the-box: as stated above, doorkeeper
requires you to install other 3rd-party-gems to have OpenID or plain JWT access tokens. However, other features, such as using JWT signed authorize requests, supporting encrypted JWT tokens, resource server mode or the SAML assertion grant type, aren’t (at the time of this answer) implemented by doorkeeper
.
Although doorkeeper
supports some security features such as the PKCE flow or hashing token columns, these have to be explicitly turned on (see how to use PKCE or token secrets there).
rodauth-oauth
wiki has a section dedicated to the security defaults and features it provides.
Because it’s based on rodauth
, adding missing functionality or extending behaviour to rodauth-oauth
is very easy, because the internals of each feature are approachable and contained in a single file.
Extending doorkeeper
involves deeper understanding and extension of rails
and its layers, making such features a bit “all over the place”.
It will really come down to your requirements. “jwt” has a bigger community (at the time of this answer, 5x more contributors); “json-jwt” has been getting more updates and releases; “json-jwt” supports way more signing algorithms; “jwt” has no dependencies (“json-jwt” loads “activesupport”); “json-jwt” monkey-patches core classes; “json-jwt” already includes JWE; etc etc etc…
YMMV here.
As always, it’s best to read the manual in order to know what you’re buying. Nevertheless, here’s the gist of it:
plugin :rodauth do
enable :oauth #, :oidc, ...
# already by default:
use_oauth_implicit_grant_type? false
# https://gitlab.com/honeyryderchuck/rodauth-oauth/-/wikis/PKCE
oauth_require_pkce true
# https://gitlab.com/honeyryderchuck/rodauth-oauth/-/wikis/Token-Hashing
oauth_tokens_token_hash_column :token_hash
oauth_tokens_refresh_token_hash_column :refresh_token_hash
# https://gitlab.com/honeyryderchuck/rodauth-oauth/-/wikis/Form-Post
oauth_response_mode "form_post"
end
If you’re using JWT tokens (if you’re using the :oidc
feature, you are), do consider your signing algorithms and pkey lengths. However, this discussion goes beyond this library.
The TL;DR: You can do that by building the “single button form” yourself.