https://www.ory.sh/ logo
Join Slack
Powered by
This message was deleted.
# general
m
This message was deleted.
b
I have deployed Kratos and Hydra and implemented some of points you have mentioned… 1 to 4 in a slightly different way.
c
@bulky-architect-22083 I would be interested to hear if you could share 🙂
b
1.We manage apps by creating an OAuth Client for each app. The app has a domain such as 
<http://app.domain.com|app.domain.com>
2. Once the user logins in, we use the access token (access token contains kratos identity id) provided by hydra and send it as a bearer token to the Backend from the UI 3. We introspect the access token using the hydra introspect token endpoint and extract the kratos identity id and then extract user level information such as role etc. from the backend (this is not stored in kratos at the moment)
We are not using a BFF at the moment, once the login is successful, our IdP implementation which combines kratos and hydra generates the access token using hydra and embeds the kratos identity id and email address in that access token
UI is implemented using Next.js and we use Next-Auth where we have added our custom IdP Implementation (Kratos + Hydra) as an identity provider and Next-Auth takes care of the rest 🙂
Let me know if you have any questions 🙏
c
One question regarding workloads that working on the data but are internal, do they still using Hydra to get a token via client credentials flow or something else?
b
At the moment we use authorization code flow to login from the UI. We have not yet done any server to server API calls where a client credentials flow would be required.
c
When you say in point 2 that you pass the token from the BE to UI, this means you pass the username/password to one of your own APIs and then forward that to Kratos to handle the login and then generate a token and send it back?
b
Actually we pass the token from the UI to the BE. 1. From UI we use username and password and login using our identity provider (Kratos + Hydra) 2. IdP (Kratos + Hydra) generates access token and stores Kratos Identity ID in access token 3. UI receives access token from IdP 4. UI calls API with 
Bearer access_token
5. API uses Hydra Introspect token endpoint to get Kratos Identity ID and validate token 6. API gets other business related user information from our database using Kratos Identity ID
c
Ok that sounds how I thought it would, but point 5, is the token opaque then and not a JWT? In the solution we currently have built we send back a JWT, that JWT is then passed to the gateway which keeps active public RSA signing keys queried from the token server to verify without a network call. Do you know if something similar is possible with Hydra?
b
Its an opaque token and not JWT. I am not sure if you can do what you have described using Hydra. You would need Keto which will be the gateway for introspecting JWT.
Sorry not Keto... Oathkeeper
c
Thanks I will take a look at that
👍 1
Also, I don't know how many types of users you have, but do you have different schemas for each or do you have 1 schema? If you have 1, do you have the role on the schema or do you use permissions to determine access?
b
We have one schema with email and password and we let each app (oauth client) handle other user details required for that app
We store the roles in a separate user table that is accessed by the app
In the latest version of kratos you can store roles as metadata
When we implemented our IdP, we were using Kratos v0.8.2, so we had no choice but to store role in a separate database not related to kratos and then link it with kratos using the kratos identity id
c
Ok, I'm not the best with identities/security etc which is why I want us to just use something out the box, would you recommend storing the role in the metadata vs in another system/database?
b
The docs recommend storing it as metadata either at the admin level or public level. The public metadata is visible to the user but cannot be edited. The admin metadata is not visible to the user and cannot be edited by the user.
We are storing it in another database because we want the user to be able to change the role depending on their access level. You cant do this using kratos...
c
Thanks for the info and sparing you time to write it 🙂 I am going to try get something working see how it ends up
b
No problem 👍
c
Can Hydra and Krato exist on the same domain?
Also, is there a way that is doesn't ask for scope access and just grants them all the scopes the app has registered anyway?
b
Kratos and Hydra can exist on the same domain, it depends on how you implement your Identity Provider
You can grant scopes based on your business requirements.
c
The IdP is Kratos I thought
b
Yes sorry you are right IdP is Kratos
Internally we have also combined Hydra with Kratos
When you implement the UI, you can combine them
c
Ok sweet 🙂
Just out of interest how many developer hours did your solution take to build?
b
About 2 months to get everything working properly
Prototype took 2 weeks to get working locally
c
😅
b
The rest was Nginx, domain configuration etc.
Its not really hard actually, Ory Documentation is good and community members are very helpful. Its like putting together a puzzle 🙂
c
It really is well documented but also overwhelming, we've halted development until we've solved the permissions stuff which either means we do it our selves or swap it all out for something else, but if I say 2 months we would be told to implement a not very well thought out solution that will probably not scale with needs as they change
b
Permission stuff can be solved using Oathkeeper but I have not used it because we dont require it for our business needs...
c
Ah 🙂
s
We use the entire stack at pvotal. Kratos with custom login in go, then PKCE with Hydra in an auth cluster. Giving JWT/Refresh token to apps, then apps call business applicative clusters using Emissary with oathkeeper as authentication service validating previous JWT. Finally those calls are in gRPC/gRPC-web and we perform granular authorization with Keto with gRPC interceptors.
c
@sparse-cricket-59561 sounds good, can I just ask a quick question about authorizing internal requests too? so a workload (registered as an oauth client, using client credentials flow) that talks to grpc a using the token to get information and perform actions. How are you determining access?
15 Views
Open in Slack
PreviousNext
Powered by