I am testing a variation of the Web Application sample where the organization_id is passed as a parameter during login. This works in that my test users are able to authenticate correctly, but the organization metadata is not populated in the Post Login action. I have metadata in the organization that is needed along with the user’s metadata as part of my requirements. The ids are matching, or I wouldn’t (shouldn’t) be allowed to login. Any advice for troubleshooting or pointers would be very appreciated.
Welcome to the Auth0 Community!
Organization metadata is available in a post login action via “event.organization.metadata”.
Please confirm that the user is logging in with an organization, the organization metadata is set correctly in your organization, and the Action is being triggered successfully during the flow.
If this doesn’t solve it, please provide more info. i.e. your action code, what you’ve done to troubleshoot, etc.
1 Like
Thanks much for the feedback. The problem was that populating the organization id with the login was not working as expected, largely because the actual url is not the one we display in the app. When I had the parameter configured correctly, it worked as expected.
As I understand, the first time a user connects these actions trigger: pre-user-reg → post-user-reg → (login-flow) → post-login.
The pre-registration action references event.client, but does not provide insight to org. The only options for metadata are client and user, and request doesn’t contain additional info either. Client is application in this parlance, so I am not sure how to pass the organizational context upon connection.
In our use case, we are trying to configure an Okta tile that will identify the application and the appropriate org for the user’s context. The goal is that the user store for each org would potentially need to be different, and I need an additional connection variable to my APIs available during this flow (I’ve been storing it in org metadata, as multiple orgs can use the same app, but their related permissions would be different in our APIs). What is the best practice for this use case?
Could you provide some additional context, maybe an example or diagram? I’m having trouble visualizing your architecture. There may not be an established best practice if you have a novel use case.
- User connects to our platform from Okta Dashboard as a new user on the platform, or connects to the web app directly and registers a user store account in Auth0. A tenant ID is passed to recognize the platform data/scope that is available.
- Auth0 pre-user-reg triggers, and creates a user profile record in our platform (this process loads platform base permissions behind the scenes). A profile id for our platform is generated and stored on Auth0. A profile ID is valid for one tenant ID
- Auth0 post-login action triggers, grabbing permissions for our platform from the appropriate service based on user profile record. tenant ID and user id are used to determine permissions.
We are not planning on storing roles or permissions in Auth0, as the platform services each identify their permissions and we don’t want to store all of the details on a third party when we need it locally as well. We need a way to identify the tenant ID (this is not an Auth0 tenant, closer to an org ID) for the platform throughout the process.