Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a way to retrieve verifying secret at runtime using connection information #690

Open
rbino opened this issue Feb 2, 2022 · 6 comments

Comments

@rbino
Copy link
Contributor

rbino commented Feb 2, 2022

Hi,
I'm using Guardian to perform authentication on some APIs. Those APIs are only responsible of verifying JWTs, so they just have access to the public key as those tokens are emitted and signed by a third party.

To support multitenancy, I have some code similar to this in my application (the :current_tenant in the conn gets populated by another upstream plug which in turn populates it based on the slug in the path):

defmodule MyAppWeb.VerifyHeader do
  alias Guardian.Plug.VerifyHeader, as: GuardianVerifyHeader
  alias JOSE.JWK

  def init(opts) do
    GuardianVerifyHeader.init(opts)
  end

  def call(conn, opts) do
    secret = get_secret(conn)

    merged_opts =
      opts
      |> Keyword.merge(secret: secret)

    GuardianVerifyHeader.call(conn, merged_opts)
  end

  defp get_secret(conn) do
    public_key = conn.assigns[:current_tenant].public_key
    case JWK.from_pem(public_key) do
      %JWK{} = secret ->
        secret        
      _ ->
        nil
    end
  end
end

and then I use MyApp.VerifyHeader instead of Guardian.Plug.VerifyHeader.

Now, all of this works for my specific usecase, but I feel that it would be nice to have something similar to the Guardian.Token.Jwt.SecretFetcher at the Plug level, so you could retrieve different secrets at runtime based on information contained in the Plug.

I assume this could be implemented as a behaviour where you have to implement the fetch_verifying_secret function, or you could pass an MFA to Guardian.Plug.VerifyHeader. I'd be interested on submitting a PR if you think this feature could be useful (in that case let me know which of the approaches you'd prefer).

Copy link

This issue has been automatically marked as "stale:discard". If this issue still relevant, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment.

@rbino
Copy link
Contributor Author

rbino commented Jun 21, 2024

Bump

Copy link

This issue has been automatically marked as "stale:discard". If this issue still relevant, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment.

@rbino
Copy link
Contributor Author

rbino commented Jul 22, 2024

Bump. As indicated in the original issue, I'm willing to provide a PR for this, I'd just like to discuss/validate the approach before starting to work on it

Copy link

This issue has been automatically marked as "stale:discard". If this issue still relevant, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment.

@yordis
Copy link
Member

yordis commented Sep 4, 2024

I assume this could be implemented as a behaviour where you have to implement the fetch_verifying_secret function, or you could pass an MFA to Guardian.Plug.VerifyHeader. I'd be interested on submitting a PR if you think this feature could be useful (in that case let me know which of the approaches you'd prefer).

I think you are going for the right direction, please send a PR since it will be easier for me to give you precise feedback

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants