Session Mode Missing Doc Explanation

[NilsBaumgartner1994]

Page

https://docs.directus.io/reference/authentication.html#login

Describe the Inaccuracy

Okay, so first, sorry to bother with this topic. But as now the default moves to the new "sesseion" mode, alot of things are now making life hard.

The documentation is missing how to login with a directus_session_token. As for our native app users we would like to safe somewhere the credentials the question arises, how to safe the session token?

Also the question arises, how to refresh with a passed session token?

As the directus SDK client does not support SSO logins for native app users, we have no clue on how to give them access to the app, as we need somehow to pass the token to the users. It is also neccessary to pass the tokens in headers for getting images, as we cannot rely on cookies always.

[NilsBaumgartner1994]

As a workaround it would be nice to know how to generate an access_token and refresh_token out of the session token, as the session token is not the same.

[br41nslug]

The documentation is missing how to login with a directus_session_token.

If you have a session token then you have already logged in. Logging in is what returns you the token for the mode used. That token is then used to authenticate to endpoints in the API.

how to refresh with a passed session token?

This would be the same as any other endpoint. Do a request with the session cookie set in the headers. Since the browser handles cookie management for you this may require extra configuration/dependencies/etc for a native non-browser platform.

As for our native app users we would like to safe somewhere the credentials the question arises, how to safe the session token?

I'm no expert in native mobile development but my first instinct would be that there are probably options to deal with cookies (considering thats a commonly used method of authentication on the web) however if they cant support cookies for some reason i would assume there'd be a platform specific secure form for storing credentials.

It is also neccessary to pass the tokens in headers for getting images, as we cannot rely on cookies always.

Cookies are passed as a header too! But there is a bunch of extra logic surrounding it in browsers dealing with domain security / js access / formatting the header / parsing response cookies and such.

[NilsBaumgartner1994]

Well the problem is with native SSO login the following:

you are in the app, you open the browser for the SSO login and get authenticated in the browser. Now the Directus instances redirects the user to the mobile app.
by that redirect the native app has no access to the cookie set. Therefore it is required to pass the token to the app via url.

So it is required to pass the token to the app somehow.

or I would need somehow to set and get the session token from within the app.

[NilsBaumgartner1994]

Could you otherwise tell me how to create/get access and refresh tokens within a custom endpoint from the session token?

this would work as a workaround.

[NilsBaumgartner1994]

Also using cookies would have the negative effect, when using a native app, the user would be logged out when the browser cache is resseted.

[NilsBaumgartner1994]

Created a temporary workaround to get refresh token for "session" auth providers: #22427

[br41nslug]

Well the problem is with native SSO login the following:

you are in the app, you open the browser for the SSO login and get authenticated in the browser. Now the Directus instances redirects the user to the mobile app. by that redirect the native app has no access to the cookie set. Therefore it is required to pass the token to the app via url.

So it is required to pass the token to the app somehow.

or I would need somehow to set and get the session token from within the app.

So quick curiosity in this native workflow, do you really need the session mode? It doesnt look like you are actually sharing the SSO login between the native app and the directus instance which would mean there is no real need to be "compatible with the browser data studio" 🤔

Couldnt you open the browser directly to the SSO provider of your users choice (/auth/login/:provider) using the authentication mode that works best for you / you were using before?
https://docs.directus.io/reference/authentication.html#login-using-sso-providers

[NilsBaumgartner1994]

Well the problem is with native SSO login the following:
you are in the app, you open the browser for the SSO login and get authenticated in the browser. Now the Directus instances redirects the user to the mobile app. by that redirect the native app has no access to the cookie set. Therefore it is required to pass the token to the app via url.
So it is required to pass the token to the app somehow.
or I would need somehow to set and get the session token from within the app.

So quick curiosity in this native workflow, do you really need the session mode? It doesnt look like you are actually sharing the SSO login between the native app and the directus instance which would mean there is no real need to be "compatible with the browser data studio" 🤔

Couldnt you open the browser directly to the SSO provider of your users choice (/auth/login/:provider) using the authentication mode that works best for you / you were using before? https://docs.directus.io/reference/authentication.html#login-using-sso-providers

Well I am open in the native browser the SSO provider directly. But this causes that the app is left and the native browser is opened. This results in not being able from within the app to access the cookie.

export const ButtonAuthProvider = ( {provider}: SsoProvider) => {
const isDebug = useIsDebug();

const translation_log_in_with = useTranslation(TranslationKeys.sign_in_with);

let providerName = provider.name;
// capitalize first letter
providerName = providerName.charAt(0).toUpperCase() + providerName.slice(1);

const accessibilityLabel = translation_log_in_with+': '+providerName;
let text = translation_log_in_with+': '+providerName;

const url = ServerAPI.getUrlToProviderLogin(provider);

const disabled = !isSsoLoginPossible();

if (disabled) {
	text += '\n'
	text += 'Does not work on local ExpoGo'
}

if (isDebug) {
	text += '\n'
	text += 'Debug: URL: '+url
}

const onPress = () => {
	CommonSystemActionHelper.openExternalURL(url)
}

return (
// @ts-ignore
	<ButtonAuthProviderCustom key={'ssoButton'+provider.name} disabled={disabled} accessibilityLabel={accessibilityLabel} onPress={onPress} icon_name={provider.name} text={text} />
);

};

[br41nslug]

So i am a little confused now

This results in not being able from within the app to access the cookie.

How were you doing this before? because before session mode was introduced you had to use cookie mode which also required you to deal with that refresh cookie. That specific flow of SSO redirect then receive a cookie which you can refresh hasnt changed in that respect only what the token in the cookie is capable of.

[NilsBaumgartner1994]

So i am a little confused now

This results in not being able from within the app to access the cookie.

How were you doing this before? because before session mode was introduced you had to use cookie mode which also required you to deal with that refresh cookie. That specific flow of SSO redirect then receive a cookie which you can refresh hasnt changed in that respect only what the token in the cookie is capable of.

Before I used the Json mode. And I let the user redirect to a custom Directus endpoint. This endpoint took the „refresh_token“ and added it to a redirect to the native app deep link

[NilsBaumgartner1994]

The current workaround uses the session mode and creates a new refresh token and adds this also to the redirect.

[br41nslug]

Before I used the Json mode. And I let the user redirect to a custom Directus endpoint. This endpoint took the „refresh_token“ and added it to a redirect to the native app deep link

So then what was stopping you from carrying on with this original workflow? this authentication is unrelated to the Directus Studio authentication and specific to the native app as far as im reading

[NilsBaumgartner1994]

Before I used the Json mode. And I let the user redirect to a custom Directus endpoint. This endpoint took the „refresh_token“ and added it to a redirect to the native app deep link

So then what was stopping you from carrying on with this original workflow? this authentication is unrelated to the Directus Studio authentication and specific to the native app as far as im reading

You are totally correct. But regarding the increasing native app amount, it would be beneficial for Directus to also support these kind of native auth flows. For me I will stick to this workaround but I would love to see a support of this also as for SDK clients.