Faq

Does it work with Rails?

Why does “rodauth-oauth” exist? We already have “doorkeeper”!

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.

1. Rails-Only

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.

2. Incompatible plugins

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.

3. Features

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.

4. Security

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.

5. Easy to extend

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”.

Should I use “jwt” or “json-jwt”?

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.

What’s the best configuration from a security standpoint?

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 HMAC algorithms and pkey lengths. However, this discussion goes beyond this library.

I know my clients, how can I skip the authorization form step?

Related issue here.

The TL;DR: You can do that by building the “single button form” yourself.

Home

Rodauth OAuth

Faq