wtcross

LiveView security when using 3rd party APIs

I am seeking guidance on security concerns when using 3rd party APIs within a LiveView. Ory Kratos is an API-first identity and user management system. I am using it as part of a project that also involves Phoenix Framework.

Kratos offers the following self-service flows via an API:

This means it’s up to the developer to build the UI if you don’t want to use their reference NodeJS/React application or other reference apps that exist in other languages. I much prefer to make it much more native to my Phoenix application and leverage LiveViews, for example. There are three scenarios documented by Ory for how to implement each of these flows:

The differences in these different flows are mostly around how redirects, csrf tokens, and cookies are or are not used.

If I were implementing this using plugs and regular controllers then the first option, browser flow for server-side apps, would be a great choice. However, I want to use LiveView. My goal is for all interaction with the Kratos API to happen on the server side with an internal-only (private) Kratos deployment. Paired with LiveView’s security model and stateful nature I was thinking the browser flow for client-side apps is actually the safest bet. My question is, what’s stopping me from using the API flows?

The API flows are understandably documented to not be used in web-based applications. LiveView seems unique, though, and I’m looking for guidance from the community on what security guarantees LiveView offers when making third party API calls to a service like Kratos. CSRF, XSS, session hijacking, and other attack vectors are all of concern.

3 comments

#security #liveview

0 584 3

2023-09-09 18:46:34 UTC

First Post!

wtcross

My initial goal was to build user management, authentication, and authorization myself as part of the Phoenix app. In the end this is a side project and I don’t want to spend all the time doing that and possibly not get something right.

For now I have been using the hosted offering by Ory…called Ory Network. This hosted offering basically ties together all the Ory projects (including kratos for identity management and auth). It also has all the UI bits you would need and @znorris has created a great plug, kratos_plug to handle the authentication part. For everything else I just send users over to Ory Network. The kratos_plug will work with a self-hosted Kratos as well.

Having a LiveView enabled integration with these APIs would make the user experience better even with Ory Network. It would also make self-hosting way more attractive.

Post #1

Last Post!

wtcross

That all makes sense and is where I started when implementing via a regular controller and no LiveView. If I use the browser server-side flow it requires redirects, which kinda defeats the purpose of LiveView. Am I wrong about that? I was under the impression that it would kill the LiveView process.

I was thinking that I could use the browser client-side flow, but within the LiveView so that no redirects are needed. This way a single LiveView process can persist throughout the full Kratos self-service flow.

Taking it a step further. As far as the API flow goes, I was referring to the actual API flow intended for native devices. My thinking was that if the LiveView persists for the full duration of the flow, associated with a kratos flow id, that we could use the native client API instead of browser based ones. Maybe I’m over simplifying the security model of CSRF protection for LiveView connections.

Post #3