Make passkeys the default authentication option

[tcannonfodder]

Continuing the conversation from: https://ruby.social/@Kowfm/110607669102788691

Given the significant increase in security & overall developer experience (less sharp edges & app-specific code to manage!), passkeys should be the default authentication option for Camping apps.

Off the top of my head, I see the following phases:

Choose a Rack authentication framework

There are a few options available; all of which use the same WebAuthn library under the hood (https://github.com/cedarcode/webauthn-ruby):

• https://github.com/ruby-passkeys/warden-webauthn
• https://github.com/jeremyevans/rodauth
• Making a Camping-specific rack authentication framework that uses webauthn-ruby

Implement the Camping-specific controllers

The rack authentication frameworks above will help with the authentication side of things, but they'll still need to be hooked into a Camping app overall.

Currently, we're working on a lightweight devise extension, which might be a good reference point: https://github.com/ruby-passkeys/devise-passkeys

Add the hooks for the model layer

Passkeys need to be persisted in a database; so there will need to be the appropriate hooks to store them in the DB.

[karloscarweber]

Alright Let's do it!

I think I want to write a Camping specific Auth plugin. Camping plugins are called Gear.

Camping is meant to be minimal and micro, but easily extendable, with a "place" for predictable behaviour. Cookies, Sessions, Authentication, Controllers, Models, Views, etc... One of these predictable pieces we want to make is Authentication.

Because Camping now has a somewhat composable, multi "app" architecture, It's possible to include a gem that Offers the complete Authentication lifecycle, including views, that just works with minimal, or no custom configuration. Example:

require 'camping'

# Sets up a camping app named Donuts
Camping.goes :Donuts

# Sets up the camping gear, SleepingBag, that Adds authentication helpers, routes, 
# views, etc... to your Camping app.
Camping::Gear::SleepingBag.in(Donuts)

In the above Example SleepingBag is the camping gear's name. Hopefully scoping Camping gear to Camping::Gear will be a predictable convention.

Subsystem Requirements

There are Camping API requirements that this effort brings to light:

• A persistence layer, aka database.
• Injectable Front End styles/scripts.
• Standard current_user and associated APIs, methods, and helpers.
• Predictable User naming conventions.

I think that the development plan should be to make a naive, but working implementation of a webauth/passkey focused Gem/Gear, then work backwards to design and implement the subsystem requirements for Camping. Adding the features to Camping iteratively will make Actually using the Gem easier and easier, as it will require less and less to plug it in.

To make Passkeys the default behaviour requires making it really really easy to use and get right. So this approach to the sub systems in response to a use case is really exciting to me.

Step by Step Plan

• Set up a new namespace for the Gear.
• Implement a simple app that requires logins to use as the Test application.
• Iterate on the Gear to add the authentication capabilities.
• Iterate on the subsystems of Camping to give much easier hooks for the Gear.
• Write lots and lots of wild tests to make sure it just works.

[tcannonfodder]

Excellent plan! We're always here to help; let me know if you've got any questions or need a review!

Once we get the devise-passkeys gem into beta I might be able to help out as well, but no ETA there