i'm back 😛 dno if it's good or bad lol. i'm trying to get my head around identity schema & metadata again. previously i was recommended in here to have additional user information in it's own database with my own backend service managing that content. The content would be e.g. profile_picture, country, city, zip code and a bool with gravatar. (what i have right now). what i'm currently doing is requesting my backend service on the side after the user is logged in and getting that data out and it's a nightmare to handle on the side with Kratos since i can't have it in e.g.

{ session } = useSession()

or

session = getServerSession()

I can ofc also read on https://www.ory.sh/docs/kratos/manage-identities/best-practices#keep-your-data-lean that I should NOT store business logic in the Kratos DB. What is the "best" way or even recommended way to get my additional info out? in a former code base I have i made my own

useSession()

/

getServerSession()

functions that wraps Kratos but then also does a request to my own backend. It would give me

session

&

profile

consts where I can access the data, i'm not sure if i like that 😞 I would kinda love to use

Ory Actions

or Webhooks in the on-prem solution. But currently the

Request Authentication

in that is limited to either basic api key auth or

basic_auth

neither are good 😞

Hi, thanks for being so engaged!

It would give me

session

&

profile

consts where I can access the data, i'm not sure if i like that

that sounds like a reasonable solution, what don't you like about it? You could utilize something like Promise.all in a react query to only return once both are fetched.

I would kinda love to use

Ory Actions

or Webhooks in the on-prem solution.

But currently the

Request Authentication

in that is limited to either basic api key auth or

basic_auth

neither are good 😞

could you expand on this a bit? In what context do you want to use the actions?

About the 2 consts. I feel like it would be nicer to have them as one, so simply have it on an interface. And it would still mean that i should wrap the sdk my self and basically make my own

@ory/nextjs

or even

@ory/elements/element-react

For the ory actions. I don't feel like a single Api key for Auth between my frontend (server or client side) to my backend service is super secure. Same with basic Auth. I do want to leverage kratos and keto in my backend, so why shouldn't I be able to use that for Auth when an action is triggered.

I feel like it would be nicer to have them as one, so simply have it on an interface.

I agree, however, think of it this way: Kratos is not a database. What happens if a business requirement comes along, that requires changing the datatype of one of the fields to an array? In a database, that's a fairly trivial operation, change the schema, run some migrations, and you're done. In kratos, this requires more work, because you need to update the identity schema, update existing identities, etc. Also there is no schema for more complex data, nor relationships between different datafields. I'd always prefer the flexibility, over the initial convinience.

I don't feel like a single Api key for Auth between my frontend (server or client side) to my backend service is super secure.

Kratos handles end-user identities, not service-to-service auth. When Kratos' webhooks fire, that's server side code, not client side. If you self-host Kratos, you might even set it up in a way, that the traffic between Kratos and your webhook target never leaves the internal network. Or on your webhook target, you whitelist the IP address that Kratos is making requests from. You can also always rotate those keys, if you control both sides. There are plenty of ways to make this system even more secure, even though it really isn't necessary, as long as you keep the API key confidential. Does this answer your question?

I agree, however, think of it this way: Kratos is not a database. What happens if a business requirement comes along, that requires changing the datatype of one of the fields to an array? In a database, that's a fairly trivial operation, change the schema, run some migrations, and you're done. In kratos, this requires more work, because you need to update the identity schema, update existing identities, etc. Also there is no schema for more complex data, nor relationships between different datafields. I'd always prefer the flexibility, over the initial convinience.

I fully agree on this 🙂 makes total sense also from a sys-admin POV which is my field.

Kratos handles end-user identities, not service-to-service auth. When Kratos' webhooks fire, that's server side code, not client side. If you self-host Kratos, you might even set it up in a way, that the traffic between Kratos and your webhook target never leaves the internal network. Or on your webhook target, you whitelist the IP address that Kratos is making requests from. You can also always rotate those keys, if you control both sides. There are plenty of ways to make this system even more secure, even though it really isn't necessary, as long as you keep the API key confidential. Does this answer your question?

Ofc everything will be on the inner network, nothing public for that since it's backend. so just to write it in stone i guess (how i best understand stuff). "best" to use API Key between kratos & my backend service. have it made to change that key on-the-fly, i know kratos hot reload based on config changes, so should my backend and then ofc have that key somewhere else for security ofc. So, how should I secure my backend and basically authenticate my users into it? The kratos user id that is created on registration is "copied" over to my own DB. But obviously i don't want any user to just be able to access other users data 😛 my backend is made in golang. This is ofc when thinking about using Actions/Webhooks. If not using that, then I guess i would need to take the session cookie and send that in my server side requests from NextJS and simply do the

validateSession()

from https://www.ory.sh/docs/kratos/self-hosted/go (gin middleware). I apologize for the long message @bland-eye-99092 🙂 but i do appreciate the help.

But obviously i don't want any user to just be able to access other users data 😛

how would they?

And what about what about the 2 variabless?

Sounds good to me, what's the issue? @ory/nextjs and @ory/elements-react are just packages, that contain helper functions.

how would they?

I don't know, i'm not team red 😛 i'm team blue. I just don't want to have a fully open rest api, even on the inside of my network. that just screams in my head. And if the key gets leaked ? even worse.

don't want to have a fully open rest api

it's not, you're requiring an api key to talk to it, no? If the key is leaked, you rotate it.

yes, but 1 key to rule it all. where at, adding another security layer to isolate the requests to only what the user has access to.

I think you should consider a custom "wrapper" for the whoami API: 1. client sends session cookie/token to your whoami API 2. server does "normal" whoami call 3. server uses the identity ID from the response to look up and add additional data to the response 4. client receives all data in one call Note that this is just an idea, not a guide on how to securely implement it.

Ya, so implement the whoami kratos Api in my backend. Return required data. Right?

yes basically, the "get my extra user data" endpoint has to validate the session anyway to ensure each user can only get their own respective data

Exactly

yes, that endpoint can do much more if required, like keto permission checks