Better information for failed logins

[xcskier56]

Hey @cainlevy, I'm curious, are you open to extending this project so that the caller of subject_from can get better information than the id token verification worked/failed?

One way I have implemented this is, is by raising errors in the verifier and then catching that error in the application controller and then returning the error's message to the client. I have found this very helpful when working on projects so that you can know why the login failed.

Thoughts?

[cainlevy]

Maybe with a subject_from! variant? That would remain backwards compatible and match Ruby conventions nicely.

I'm curious what your use case is. What decisions would you make with error data?

[xcskier56]

Basically I have used something like this in the past to help understand authentication issues: (please don't mind some psuedo code)

module Keratin::AuthN
  class IdTokenVerificationFailure < StandardError; end

  class IDTokenVerifier
    def verified?
      EXPECTATIONS.all? do |expectation|
        if send(expectation)
          true
        else
          if config.raise_on_jwt_failure
            raise IdTokenVerificationFailure.new "JWT failure: #{expectation}"
          end
          Keratin::AuthN.debug{ "JWT failure: #{expectation}" }
          false
        end
      end
    end
  end
end

class ApplicationControler < ActionController::API
  rescue_from Keratin::AuthN::IdTokenVerificationFailure, with: :login_failed

  def login_failed e
    render json: { error: 'Login Failed', cause: e.message }
  end
end

This allows the frontend to receive the JWT authentication error message which can really help when working with complex systems. For example, we had one case recently where the frontend kept receiving iat not valid and traced it to the network environment stopping NTP requests so the servers' clocks were off.

[cainlevy]

Sounds like it was useful for forensics, but not necessarily for application logic. Is that right?

Can you say more about why this was easier to diagnose from the frontend rather than rely on the Keratin::AuthN.debug server logging?