Hello, I wanted to know if we can get an access token for a user based on the email address of the user and using the clientid and client secret of the application?
Hi @bhavish,
It’s not possible to do what you describe. It sounds like you’re attempting to implement an impersonation feature. Is that the use-case that leads to your question?
Hello,
Yes - so the use case is, a user logs in on their own application on their system using whatever authentication they have in place. They will then have an iframe with my application where they only pass in that user’s email so they get access to my application without needing to login again, without using a password. That user would already be added by an admin from my application to Auth0.
I am guessing my application can look up if that email is in auth0, using the management api, but I am unsure, how I can then generate an access token for that user. Any idea how this can be achieved?
Thanks,
Bhavish
Depending on the authentication protocol that the system is using, you could create a connection to it, to use it as Identity Provider. In that way, all your app has to do is verify if there’s an existing session in the parent system.
Do you know what auth protocol does the system use?
Also, are you using “their system” in a general way, where your app could be integrated with multiple different systems from different customers of yours?
yes - so I would not know on how the parent system authenticates. I would like to have a general way where they just pass us the email address, and the app can log them in by checking if that user is already in my auth0 account by also providing an access token so other api calls can be authorised.
Thanks for the additional details. It’s not possible to achieve the flow you describe. It’s not secure, because anyone with access to your account would be able to arbitrarily access data of the users that are part of the system that embeds your app.
Regardless the protocol, in general you would establish a relationship of trust between the identity provider (the system, in your description) and the service provider (your app). Later you would ask users to login into your app by being redirected to the system. That redirection could be silent if the parent’s system authentication protocol allows for single sign-on.
Normally, apps that provide an embedded service like the one you describe, coordinate the configuration of that trust relationship in a way that varies depending on the protocol. If the system uses OAuth, they would create a client on their side that would represent your app. If they use SAML, you would exchange metadata information to setup each side’s connections, and so on.
If the system uses an in-house authentication protocol/system, then things can get more complicated if they don’t have ways of federating authentication.
Have you gone through our documented architecture scenarios? If you haven’t yet, I recommend you do. They could shed a light on what would be the best way to solve the problem you describe.
1 Like