Hello,
we have recently stumbled upon a problem when linking user accounts - for example one created with email/password, and the other via Google Authentication Provider.
In order to link the accounts, we use the Management API, wrapped within an SDK, on the backend side. Ideally, we would like to have the whole account merging logic hidden from our users, and just return ready-to-use id token that would be valid for any subsequent requests from users to our API, so that they don’t need to re-authenticate using merged account.
Looking at the documentation and API, we found out that account linking invocations return list of Identity objects, each of which contains, among others, an access_token field. However, according to our findings, this is not an id token, but merely an identity provider token that can be used to obtain the id token from identity providers, such as Google, Facebook, etc. Unfortunately, when looking at Auth0 documentation, we were not able to find a way to obtain the final id token - what we found were just references to providers’ documentation.
Is there any Auth0 abstraction built on top of identity providers that would allow us to pass an access token, and obtain an id token useful for our APIs?
Thank you in advance,
Wojtek Bauman
1 Like
Hi Wojtek
First of all, please be very careful with account linking. Hiding the account merging logic from the users is probably a security risk. If a user has only a social account, a hacker can sign up using that user’s email, and then the hacker has access to the user’s account. You should always require the user to prove they have access to both accounts before linking.
I am not clear if you want an ID token or an access token. I think what you want is an access token. Access tokens are passed to APIs to prove the user is authorized to use the API. An ID token does not authorize, it only provides data on who the user is.
Getting an access token (or an ID token) is separate from linking accounts. To get an access token, you should use an auth flow (such as auth code or auth code + PKCE), then you get the tokens back.
John
3 Likes
Hi John,
Thank you for your reply. Actually, what we got back after linking the accounts (part of the Identity object), was the IdP access token - in this particular case that we were testing, it was Google’s access token that we could then use to authenticate the user and obtain an id token (which, in turn, we would use to have the user call our own API).
What we wanted to achieve, is to skip the additional step of having the user to authenticate again (displaying identity provider’s login/auth form, etc.), and instead use IdP’s access token to obtain an id token. Then we’d be able to return such a token to the user within the response to a single request - the same request that was used to link the accounts.
So the flow right now, as we see it, is the following:
- the user requests to link her/his accounts (request goes from the user to our API)
- we handle the request, validate the user, etc., and from our backend we invoke Auth0’s Management API to perform the actual account linking
- once the accounts are successfully linked, Auth0 returns list of Identity objects, each of which contains the access token field - which we found out to be IdP’s access token
- the user needs to re-authenticate using the linked account
- as a result, Auth0 issues new id token, and the user can use it to access our API
However, the flow that we’d like to achieve is the following:
- the user requests to link her/his accounts (request goes from the user to our API)
- we handle the request, validate the user, etc., and from our backend we invoke Auth0’s Management API to perform the actual account linking
- once the accounts are successfully linked, Auth0 returns list of Identity objects, each of which contains the access token field - which we found out to be IdP’s access token
- on our backend server, we use IdP’s access token obtained in the previous step to authenticate the user and obtain an id token
- we then return the freshly obtained id token to the user, so she/he does not need to authenticate again
So, assuming we got everything else right, all this actually boils down to a question if there is a way to obtain an id token based on IdP’s access token without requiring a manual step in between.
As I mentioned before, we use several IdPs, so for us it would be ideal to use some Auth0 abstraction/interface that would hide IdP details from us.
I hope this, albeit lengthy, description sheds some more light on what we’re trying to achieve.
Wojtek