LiveView security when using 3rd party APIs

wtcross

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 667 3

2023-09-09 18:46:34 UTC

Showing Posts 1 to 3

Show Best Posts
Show All (oldest first)
Show All (newest first)

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

znorris

As you posted, these server-side flows, Kratos server-side self-service flows will allow us to safely integrate our UI with their backend. I’ve implemented these Kratos endpoints in Ruby for a different project. I found it to be straight forward once I wrote an HTML form rendering function. Something to take their self-service response (shown below) and return an HTML form.

{
  "id": "33f6079a-ef14-4084-af13-34a91e53cd6c",
  "type": "browser",
  "expires_at": "2021-07-09T10:08:08.856735Z",
  "issued_at": "2021-07-09T09:08:08.856735Z",
  "request_url": "http://playground.projects.oryapis.com/self-service/login/browser",
  "ui": {
    "action": "https://playground.projects.oryapis.com/self-service/login?flow=33f6079a-ef14-4084-af13-34a91e53cd6c",
    "method": "POST",
    "nodes": [
      {
        "type": "input",
        "group": "default",
        "attributes": {
          "name": "csrf_token",
          "type": "hidden",
          "value": "XmG3qwTYSV0oWIyNGTugvtNOKMxWPYHd7dNX7BYK5lL79P0iUdq5jVmRUKwwm8RLcAGN7eF7iYraAiTSOdamuQ==",
          "required": true,
          "disabled": false
        },
        "messages": [],
        "meta": {}
      },
      {
        "type": "input",
        "group": "password",
        "attributes": {
          "name": "identifier",
          "type": "text",
          "value": "",
          "required": true,
          "disabled": false
        },
        "messages": [],
        "meta": {
          "label": {
            "id": 1070004,
            "text": "ID",
            "type": "info"
          }
        }
      },
      {
        "type": "input",
        "group": "password",
        "attributes": {
          "name": "password",
          "type": "password",
          "required": true,
          "disabled": false
        },
        "messages": [],
        "meta": {
          "label": {
            "id": 1070001,
            "text": "Password",
            "type": "info"
          }
        }
      },
      {
        "type": "input",
        "group": "password",
        "attributes": {
          "name": "method",
          "type": "submit",
          "value": "password",
          "disabled": false
        },
        "messages": [],
        "meta": {
          "label": {
            "id": 1010001,
            "text": "Sign in",
            "type": "info",
            "context": {}
          }
        }
      }
    ],
    "messages": [
      {
        "id": 4010002,
        "text": "Couldn't find a strategy to log you in with. Did you fill out the form?",
        "type": "error"
      }
    ]
  },
  "created_at": "2021-07-09T09:08:08.857959Z",
  "updated_at": "2021-07-09T09:08:08.857959Z",
  "forced": false
}

There are different flows for different application architectures to ensure security matches the use-case. These server-side flows will have you including a CSRF token Kratos generated. To answer your earlier question, “what’s stopping me from using the API flows?” Nothing! In fact you should use them but just be sure to use the server-side browser flows.

Post #2

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

— All posts loaded —