keratin/authn-rb

Ruby client library for Keratin AuthN

authn-rb's Issues

refactor key fetching to rely on configured issuer

Currently, JWKs are fetched from the JWT iss after verifying that the iss is equivalent to the configuration. This should be refactored so that keys are fetched directly from the configured issuer and made available to the token verifier by kid.

The expected benefit is a clearer verification process that does not depend on transitive trust

Working with multiple frontend domains

The audience is setup as a static configuration within this library which makes it currently impossible to allow a single backend to service multiple front-end domains.

From the README.md example it shows this configuration

Keratin::AuthN.config.tap do |config|
  # The base URL of your Keratin AuthN service
  config.issuer = 'https://authn.myapp.com'

  # The domain of your application
  config.audience = 'myapp.com'

  # HTTP basic auth for using AuthN's private endpoints
  config.username = 'secret'
  config.password = 'secret'
end

and within id_token_verifier.rb it's grabbing the audience out of the configuration for verification.

def token_for_us?
  jwt[:aud] == Keratin::AuthN.config.audience
end

However, if we have multiple frontend servers hitting the same backend API we will only be able to service one of them.

• frontend1.domain.com -> api.domain.com
• frontend2.domain.com -> api.domain.com

I can set the configuration to one or the other but not both. It would be nice if we could pass a parameter (maybe optional) into subject_from as an audience override. That way we can take the referrer header from the request and pass it through. That should allow for the audience verification but allow it to work a bit more dynamically.

allow configuring a separate URL for private endpoints

Configuration should allow a separate URL for issuing requests to private endpoints.

This is intended to solve a tricky bit of setup in deployments where communication between services goes over a private network. Currently, this setup requires configuring authn-server and the backend with the private URL as issuer, while configuring the frontend with the public URL.

• config.issuer: must match the iss claim in authn-server tokens
• config.authn_url: provides the base url for private communication with authn-server (defaults to config.issuer)

Better information for failed logins

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?