Return refresh token via query string when using SSO.

[sekhuat]

DirectUs is one of the best frameworks I had used so far. It is easy to enable SSO authentication (e.g. with Auth0 or other authentication providers). I just need to set up the SSO config in the .env file and my web application (web client), I just need to redirect the user to https://my.directus_domain.com/auth/login/auth0?redirect=https://my.app_domain.com to perform the login. When the user had completed the authentication via Auth0, DirectUs will redirect the user to the URL specified in the redirect query parameter. DirectUs will also set a refresh token in the cookie before the redirection. In my web app, when the redirect URL is fired, it will detect if is there any refresh token in the cookie. If have, my web app will perform a refresh using the DirectUs JS SDK. If refresh is successful, then the app will allow to user to access the system as an authenticated user.

This worked fine with the web application that needs to authenticate with DirectUs via SSO. However, when a mobile app needs to authenticate with DirectUs via SSO, it is not so straightforward.

I use React Native to build the mobile app and installed the react-native-auth0 npm module. However, the react-native-auth0 module only returns the access token from Auth0 and not from DirectUs. This access token is not recognised by DirectUs and will not allow the user to access the system. Furthermore, the react-native-auth0 npm module will not return the state and code returned by the Auth0 server which we can use to authenticate with DirectUs via the build in https://my.directus_domain.com/auth/login/auth0/callback URL. Therefore, I had to drop the idea of using react-native-auth0 module to perform authentication with DirectUs via SSO.

So, I decided to use the same method as the web application. I will use the expo-web-browser npm module to re-direct the user to https://my.directus_domain.com/auth/login/auth0 to perform login using the code below.

import * as Linking from 'expo-linking';
import * as WebBrowser from 'expo-web-browser';
...
const onLoginPress = async () => {
    let loginUrl = `https://my.directus_domain.com/auth/login/auth0?redirect=${Linking.createURL('/?')}`; // Linking.createURL will create a URL that point back to the mobile app
    await WebBrowser.openBrowserAsync(loginUrl)
  };

When the user clicks on the Login button, the app will launch the mobile device browser and perform authentication via the DirectUs SSO. After the user is authenticated, the browser will be dismissed and switch back to the mobile app. The mobile app will fire the Linking event listener that I had added in the useEffect.

...
useEffect(() => {
    const linkHandler = Linking.addEventListener('url', handleDeepLink);
    return () => {
      linkHandler.remove();
    }
  }, []);
...

function handleDeepLink(event) {
    let data = Linking.parse(event.url);
    
    if (Constants.platform.ios) {
      WebBrowser.dismissBrowser();
    } 
   ....    
  }

However, since the https://my.directus_domain.com/auth/login/auth0 returned the refresh token in the cookie, the mobile app won't be able to access the refresh token, therefore, my mobile app cannot complete the authenticate flow. To solve the cookie issue, I modified the file in DirectUs application node_modules/directus/dist/auth/drivers/openid.js in the createOpenIDAuthRouter method at router.get('/callback'... function call around line 314. I change the line of code from return res.redirect(redirect); to return res.redirect(redirect + '?refresh_token=' + refreshToken); to return the refresh cookie via URL query parameter also and not just via the cookie only.

With the above change, now my mobile application can complete the authentication flow with the new logic in the handleDeepLink event handler.

...
function handleDeepLink(event) {
    let data = Linking.parse(event.url);
    
    if (Constants.platform.ios) {
      WebBrowser.dismissBrowser();
    } 

    if(data && data?.queryParams?.refresh_token && data?.queryParams?.refresh_token.length > 0) {
      // Set the refresh token into the directus sdk storage
      directus.storage.set('auth_refresh_token', data?.queryParams?.refresh_token);
     
      // Perform a refresh with the newly set refresh token received from the event.
      directus.auth.refresh()
      .then(result => {
        // Success login, redirect user to main application screen
      })
      .catch(err => {
        // Login failed, prompt user to login again
      });
    }
    
  }

With this minor change in the DirectUs SSO driver, we can authenticate the user with DirectUs via SSO using a mobile application. I Googled a few days and most of the solutions for authenticating the mobile app with DirectUs SSO is to build a custom endpoint which I think is too troublesome and might face issues in a future release of DirectUs. This Authentication flow should be provided by DirectUs instead.

I hope that DirectUs can include these changes to all SSO drivers in the new release. For now, I can create an npm patch for my mobile app to automate the change, but this is not a long-term solution. Thanks for your kind consideration.

[rijkvanzanten]

I'm wondering what the security implications are for putting the refresh token in the readable URL that's returned 🤔 The reason it's in a httpOnly cookie right now is to make sure there's no place in the request that the client side JS can read (and therefore prevent XSS attacks). However, with a redirect URL with the refresh token in plain text in a query parameter, man in the middle attacks become way more of a threat 🤔 Happy to hear your thoughts on how to make this secure!

[efonte]

That's the same error I wrote here (https://github.com/directus/sdk/discussions/87) two months ago and we still don't have a solution :(

[sekhuat]

If your application is a web application, then the Directus SSO works fine. I have a web application using Directus SSO without any issue. The issue I faced is when building the mobile app to authenticate with Directus SSO. End up I create a custom endpoint to receive the access token from the Auth provider (e.g. Auth0), it will verify the access token using the key from Auth provider to ensure the authentication is a valid one. It then proceed to check if the user existed or not. If not exist, then create the user. The custom endpoint will then use Directus API to create the Access Token from Directus and send back to the mobile app.

[rijkvanzanten]

Heya! Thank you for taking the time to submit this request!

It has been over 90 days, and this discussion has not received at least 15 votes from the community. This means that we don't feel like there's enough community interest to warrant further R&D into this topic at this time. 🧊

This request will now be closed to keep our discussions tidy. Please reach out if you have any questions!

For more information, see our Feature Request Process.