Microsoft-authentication-library-for-js: Get logged in user in @azure/msal-browser": "^2.0.0-beta.3"

[jrmcdona]

Please follow the issue template below. Failure to do so will result in a delay in answering your question.

Library

@azure/msal-browser": "^2.0.0-beta.3

Description

I see in the new beta 3 version we getAccountByUsername and getAllAccounts which could return more than one account.

It is not clear to me how come we know longer have getAccount. If I getAllAccounts, how do I know which is the one that they just signed in with (if there is more than one)? If I don't know whom is signed in, then I cannot getAccountByUsername since I don't know the username yet of the person signed in. Normally that is what getAccount would let me know.

[jrmcdona]

Another is example is that previously, to get the loginHint, I was getting the member name

this.msalInstance.getAccount() which would give me the user information and from there I could get the loginHint.

It seems in Beta 3 it isn't possible anymore to figure out the username you want when getAllAccounts returns more than 1 account.

[jmckennon]

There is an example of how we use getAllAccounts in our sample. If there is only one signed in user it will return that one user just like getAccount did. When there are multiple accounts, you will need to have some logic to determine which one you want to get.

[jrmcdona]

Ok, so essentially we need to store the user's username in a cookie to track who they last signed in with? That way we can call in getAccountByUsername (username). If we don't store the username somewhere we wouldn't know who they have last signed in with.

Is that correct?

Isn't anyway MSAL can do that for us so we can keep getAccount() ?

[pkanher617]

@jrmcdona MSAL will track the account info you have signed in, but we don't support keeping track of a current account session. If you want to ensure your application is always a single account application, you can do that yourself by ensuring you don't present a sign-in screen after the initial login.

I am investigating the bug filed in #1844 where the getAllAccounts() API is returning bad data, but ideally 1 login = 1 account.

Ok, so essentially we need to store the user's username in a cookie to track who they last signed in with? That way we can call in getAccountByUsername (username). If we don't store the username somewhere we wouldn't know who they have last signed in with.

Is that correct?

We can discuss adding an API or object for single account scenarios if this is difficult to manage, but ideally yes, you would have to store the username of the currently signed in user somewhere if you want to use MSAL as before.

[jrmcdona]

@pkanher617 thanks . Would you be able to add the last username they logged in with into the localStorage/sessionStorage so we can get that via MSAL API instead of rolling our own?

[jrmcdona]

@pkanher617 @jmckennon
I think the MSAL API should let us know the username that is currently logged in so that we don't have to create a separate cookie and manage this cookie and logic. It seems very incomplete on a part of the MSAL API. It is not a streamlined .

getAllAcounts should give us all the accounts.
getAccount should give us the account that it is currently signed in/active.

How comes this is an issue?

[pkanher617]

Closing as this was resolved offline. MSAL.js will not keep track of the currently signed in account - developers must track that themselves.

[dglozano]

@pkanher617 @jmckennon

If you want to ensure your application is always a single account application, you can do that yourself by ensuring you
don't present a sign-in screen after the initial login.

If I understand correctly, this is not always possible to ensure by just not presenting the sign-in screen after the initial login in my application. For example, if I use my admin Azure AD user to login to portal.azure.com and then I go to my own application and try to log in with my personal user, MSAL.js will keep track of both accounts, even though one of the logins didn't happen in my own application. Is that right?

Is there any piece of documentation on how to achieve the same single account behaviour that we had in MSAL v1 using loginPopup?

I agree with @jrmcdona that it would be nice if MSAL provided an API to keep track of an user session, as it did before. For us, is a stopper for going to v2.x.x