How to use social login refresh token yielded by user management API

Get Help
,
16

Hi Bram :wave:

:thinking: So it sounds like you have quite an interesting use case, where you’ve identified how leveraging Auth0 to front multiple third-party IdP’s can abstract away the need to know the specifics of each third-party Authorization Server when it comes to obtaining tokens to call the APIs each third-party provides. Right? Interesting. Can you share some other situations in addition to windows live and the OneDrive APIs you mention? Feel free to DM me if you’d prefer :slight_smile:

I’d agree, there is significant merit in using Auth0 to do what you’re proposing :sunglasses: The problem is that with out due care and attention (in situations like this we normally recommend engaging with Auth0 Professional Services) it’s all too easy to create a vulnerable attack surface. However, going back over the details in this thread it does sounds like you’ve understood the ramifications of using Auth0 stored third party tokens outside of Auth0 extensibility - only using them in an APS.net core secure back-end context, for instance, being a good example. So as long as you follow the few basic principles below (listed in no particular order) you should be in good shape; I would definitely recommend engaging with Auth0 Professional Services to review your design patterns in more detail though just to be doubly sure:

  • Don’t acquire third-party tokens from an insecure context. And don’t transfer them to an insecure context either. Auth0 originally obtained such tokens via a secure - i.e. regular web application back-end workflow using a Client Secret - so sharing them with a less secure context could have some very serious security implications. See here for more details.

  • Do request a third-party Refresh Token. Access tokens should, ideally, be short lived. By design, short lived access tokens are inherently more secure as they limit the potential attack surface and therefore reduce the potential a bad actor has to perpetrate an attack. So whilst you can securely read a 3rd party access token from Auth0, it will eventually expire! And probably sooner rather than later!

  • Store the third-party Refresh Token securely; don’t rely on the Auth0 stored token more than once. Refresh Tokens can come in a variety of forms, and you can read more about that in the blog post here. Because you don’t know necessarily know what form is being delivered by a third party, you may not be able to use the Auth0 stored one more than once.

  • Refresh the third-party Access Token using the third-party Authorization Server directly. And don’t forget to securely store any Refresh Token returned, using it to refresh any third-party Access Token in the future. The previously linked blog post should explain about this from a Rotating Refresh Token perspective, and the link here will explain why Auth0 doesn’t refresh third-party tokens automatically.

I’d also recommend making use of the connection_scope parameter if you’re not doing so already. Rather than setting explicit scopes on the Auth0 Connection definition. The former is more in keeping with the Principle of Least Privilege, whereas the latter will apply to all Auth0 Applications and all Users who use that connection.

2 Likes