How to protect routes using oidcc in phoenix?

[Lionstiger]

Hi,

I'm trying to setup a project using this library as auth solution. I have a phoenix project that I used phx_gen_oidcc on.
This works and login functions as expected. I can see the oidcc_claims in the session as well.
I have however not figured out how to implement a pipeline to actually protect a route.

I would like to redirect not logged in users to a login page.

The plugs provided by oidcc_plugs seem to serve that purpose. In the examples they are used in endpoint.ex, which as I understand it, runs on every request. However using them (any combination of Oidcc.Plug.ExtractAuthorization and one of the three verification strategies) does does seems to have any effect( for both logged in and not logged in users).

How would I build a pipeline/plug to use in my router.ex to protect routes, or is this something that oidcc provides out of the box? If this is not something oidcc provides, can you point me to an example that implements this?
It might make sense to supply this in the documentation for phx_gen_oidcc as well, unless I just missed something super obvious.

Thank you for your time.

[maennchen]

Hey @Lionstiger

There's two ways how oidcc plugs help you with your application:

• Header based auth (APIs)
• Login Flow in Application

Judging by you using phx_gen_oidcc, you want to do the latter.

The generator of phx_gen_oidcc puts the OpenID claims into the session:
https://github.com/erlef/phx_gen_oidcc/blob/2b1b75296d5f8d758f2d61894edbf04319d40455/priv/templates/oidcc_controller.exs#L32

You can create your own plug checking if the claims are present in the session and include it in your router or controller for all the protected routes.

defmodule MyAppWeb.Router do
  use Phoenix.Router

  pipeline :browser do
    plug :fetch_session
    plug :accepts, ["html"]
  end

  pipeline :protected do
    plug MyAppWeb.CheckSession
  end

  scope "/public" do
    pipe_through :browser

    get "/", MyAppWeb.Controller, :public
  end

  scope "/protected" do
    pipe_through [:browser, :protected]

    get "/", MyAppWeb.Controller, :protected
  end
end

In MyAppWeb.CheckSession, you would:

• Call get_session/3 to get the claims
• If nil, redirect to your login
• If present, do nothing

Since this is a common use case, it would be great to have this in the documentation. Would you be open to send a documentation PR for oidcc_plugs with this?

[Lionstiger]

Since this is a common use case, it would be great to have this in the documentation. Would you be open to send a documentation PR for oidcc_plugs with this?

I can do that. When I feel like I understand it, I can try documenting the process.
It might make sense to add a flag to phx_gen_oidcc that generates a protected example route/the redirect plug, or something similar as well. I'm still learning elixir but am willing to try/help.

A few questions:

• Can the user manipulate the oidcc_claims session or is the session held 100% on the server side? So if the oidcc claim is present, the user is valid.
• Is the login checked on every request, with the check being part of the plug in endpoint.ex? I assume it is, that's why there's an option to add a cache.
• Does this have an effect on live_views/live_sessions? Do I need to do something extra to make sure the individual websocket connection/message is coming from an authenticated user.

If these questions are too specific or not relevant to the project, please ignore.

[maennchen]

@Lionstiger

I can do that. When I feel like I understand it, I can try documenting the process.

❤️

Can the user manipulate the oidcc_claims session or is the session held 100% on the server side? So if the oidcc claim is present, the user is valid.

That depends on the session strategy. The default strategy is in the cookies of the user agent, but they are signed so that they can't be manipulated.

See: https://hexdocs.pm/plug/Plug.Session.html

Usually a session is considered to be safe from modification from the user agent.

Is the login checked on every request, with the check being part of the plug in endpoint.ex? I assume it is, that's why there's an option to add a cache.

That only applies to the plugs in API use cases where the client will present its token on every request. For an integrated login flow, the plugs will only facilitate the login and then hand over control to the application. If you want to check if the login tokens expired or were revoked, you'd have to implement this yourself.

Does this have an effect on live_views/live_sessions? Do I need to do something extra to make sure the individual websocket connection/message is coming from an authenticated user.

The session should be passed through to your live view. Fly wrote a good article on live view sessions: https://fly.io/phoenix-files/live-session/

[Lionstiger]

Thanks a lot for the detailed answers!

That only applies to the plugs in API use cases where the client will present its token on every request. For an integrated login flow, the plugs will only facilitate the login and then hand over control to the application. If you want to check if the login tokens expired or were revoked, you'd have to implement this yourself.

So in a Login Flow situation, the Oidcc.Plug.IntrospectToken, Oidcc.Plug.LoadUserinfo and Oidcc.Plug.ValidateJwtToken plugs in endpoint.ex do nothing after the initial login process? I assumed the jwt in the cookie would represent the token in this situation.
Especially since Oidcc.Plug.ValidateJwtToken seems like just the thing I want, at least in name.

I would implement the expired/revoked stuff in the proposed MyAppWeb.CheckSession. Is this a feature that you see being part of the library eventually or is this usually handled at downstream?

[maennchen]

So in a Login Flow situation, the Oidcc.Plug.IntrospectToken, Oidcc.Plug.LoadUserinfo and Oidcc.Plug.ValidateJwtToken plugs in endpoint.ex do nothing after the initial login process?

They are not part if the login process. They are only relevant for API token checks.

The generator did not add any if those plugs to your application.

I would implement the expired/revoked stuff in the proposed MyAppWeb.CheckSession. Is this a feature that you see being part of the library eventually or is this usually handled at downstream?

Currently this has to be done manually. Since the session management is usually different per application, this is not something I‘m planning to implement right now.

[Lionstiger]

The generator did not add any if those plugs to your application.

Yes, I added those in an attempt to get routes to work (individually, not just all at once). Will remove them.

Currently this has to be done manually. Since the session management is usually different per application, this is not something I‘m planning to implement right now.

I was more thinking along the lines of "if I have to do it anyway, might as well check if its worth contributing".
I assume there are libraries that help with this, so I'll do some more research before I roll my own.

Thank you again for your detailed answers and time.
When I eventually figure out how to get protected routes to work the way I described, I'll get to documenting it and open a PR(to oidcc_plugs).