Choose/pick application flow

t.vanherwijnen

Scenario

I understand logging in using only a tenant id will return only a JWT and no refresh token. But is it possible to obtain a refresh token after successful authentication?
Let's say I have 2 apps:

http://chat.app.com/ or http://app.com/chat/
https://files.app.com/ or http://app.com/files/

Both have "Generate Refresh Tokens" and "Enable JWT refresh" set to true

You could just navigate to the specific domain + subdomain or path and login to that exact app.
But what I'm after is a possibility to be able to login to http://app.com/ and pick one of the apps an get redirected and still be logged in.
A problem with the subdomain example is, the response carries a Set-Cookie header that sets the cookie on the current domain without any wildcards. (Is there a way of customizing this header?)

The flow would look like this:

User successfully logs in on http://app.com/
User gets presented apps it's registered to
User click app and gets redirected
(somewhere here the should be a way to obtain a refresh token)
User is able to use the app and is not required to re-authenticate

My questions are:

Is this possible using FusionAuth?
Is there a way to disable/modify the Set-Cookie header so I can handle the tokens myself using the Authorization header without confusing the FA API with HTTP-only cookies?
Is it possible to obtain a refresh token using a valid JWT and application id? (user must be registered of course)

ps: I love this live MD preview

dan

@t-vanherwijnen

Is this possible using FusionAuth?

Yes, but you are going to want to use server side logic, not just client side code.

User successfully logs in on http://app.com/

So here I'm assuming you are using the authorization code grant. If not, this advice is not applicable. The redirect_uri here would be to a URL like /app_picker or something similar that you would write. This is server side code with an API key.

User gets presented apps it's registered to

This is where app_picker would retrieve the user, iterate the registrations object and display all applications to which the user has permissions. It would use the client_id of the application to create another 'login' link, and the redirect_uri would point to the initial page of the application (call it /app_initial). You should also include the scope of 'offline_access' to get the refresh token.

User click app and gets redirected
(somewhere here the should be a way to obtain a refresh token)

The user will be sent to the login page, but since they've already logged in, they'll be sent right along to the redirect_uri with the refresh token and access token.

User is able to use the app and is not required to re-authenticate

Yup.

Is there a way to disable/modify the Set-Cookie header so I can handle the tokens myself using the Authorization header without confusing the FA API with HTTP-only cookies?

You can ignore them. Being able to turn them off is an interesting feature request, please feel free to file an issue with details about your use case: https://github.com/fusionauth/fusionauth-issues/issues

Is it possible to obtain a refresh token using a valid JWT and application id? (user must be registered of course)

Yes, using server side code and an API key: https://fusionauth.io/docs/v1/tech/apis/jwt#retrieve-refresh-tokens . I'd suggest doing this in /app_initial, which can set any cookies it wants.

Hope this helps.

t.vanherwijnen

@dan

You can ignore them.

Can you explain how? I've been trying to figure this out but couldn't find any solution on how to block request cookies or request headers (Set-Cookie header).

I'm working with in a Nuxt application, so requests are made using the Axios library.

If this is not possible or too complicated I'll submit the feature request.

dan

@t-vanherwijnen said in Choose/pick application flow:

Can you explain how?

Ah, there's no way to stop them being set on the FusionAuth side, sorry for the confusion. But your application, which gets the access token in a request from your client, can certainly choose to ignore any cookies it receives.

That's what I meant.

If you'd like to be able to configure FusionAuth to not send the cookies, that'd definitely be a feature request. Please feel free to file one: https://github.com/fusionauth/fusionauth-issues/issues