OAuth Authentication Flow: Parameters for Account Selection Prompt

Hi @user126 !

What do you mean by “select an account” ?
Do you mean that the end user would see a list of users, and he will need to select the correct user ?

Hi, @CodeBoxSeb!

Do you mean that the end user would see a list of users, and he will need to select the correct user ?
The answer of your question is yes.

We want user to be enable to select which account to use every time they start OAuth flow.
This is because user sometimes want to select which account they should use in our product at different times and in different situations.

For example, Google API OAuth flow has the way to do this.
In Google API OAuth flow, if we add query parameter “prompt=consent” to URL, we can prompt OAuth consent screen to user every time, and user can select their account every time.

Reference: Using OAuth 2.0 for Web Server Applications  |  Authorization  |  Google for Developers

However, when we research the Box API document, we cannot find any parameter same as “prompt=consent” of Google API.
So, if the Box API has same feature, please tell me the way to achieve it?

Best Regards.

Do you have any updates for this?

Hi @user126 ,

I’m not sure I understand your use case.

Do you really want the users to re-authorize the app every time they login to your portal?

If you really want to do this, all you have to do is redirect the user to the Authorize user url.

You get this url by doing a get to the https://account.box.com/api/oauth2/authorize end point, re-starting the authorization process every time.

Somehow I don’t think that this is what you want, but…

Can you elaborate on your use case?

Best regards

Thank you for your response.

To explain my use case:
I would like to avoid automatic authentication based on existing sessions or cookies stored in the browser, and allow users with multiple accounts to choose different accounts when logging in.

For example, Google uses parameters like prompt=consent to address this use case, and I would like to know if Box has a similar setting or functionality to meet this requirement.

As suggested in the reply, redirecting the user to the https://account.box.com/api/oauth2/authorize URL may not be enough. The reason is that the user may be automatically selected upon redirection based on an existing session in the browser or the user’s cookies.

I hope this clarifies my intention.

Hi,

It does yes, thank you.

So Box is not an identity provider (iDP) like google is, and OAuth 2.0 protocol by it self does not provide that functionality. The idea is to authorize an authenticated user in your app to interact with its Box account. This is why the user has to agree in granting this permission at least once.

Once the user did this grant, your app gets an access, and a refresh token. The access token is valid for 60 minutes, and the refresh token is valid for 60 days. You should store these securely in your database.

When a user logs in your application, the application can then fetch a fresh access token, using the refresh token and getting a new pair of access and refresh tokens. This means that if the user uses your application at least once every 60 days, they wont need to re-authorize the application. On top of that your application continues to retrieve fresh access tokens.

There are no browser session or cookies involved, at least on Box side.

The question here is login where? I’m assuming your app because your app is not really logging into Box.com

You could have multiple Box account related with a single user, and ask the user which one they want to use, however that is a very strange use case for OAuth.

I’m wondering if this is what you really want, so let me illustrate a different use case.

Some applications prefer to hide to the users that the app is using box at all. In this use case the user of the app is not supposed to go and login to Box.com directly, and interact exclusively in the custom app.

For this you would use CCG or JWT authentication, that has a service account, but can create users within box, and impersonate them. This way when a user is created in your app, you use the service account to create a mirror user in box, and store that link. When a user logs in your app, you then request an access token in the name of the mirror user.

I wonder if you can elaborate on your use case. Let me start by asking:

Are the users of your application supposed to still be able to login directly in Box.com, and manipulate their content?