Microsoft-authentication-library-for-js: Changes in acquireTokenSilent now cause "User login is required"
I'm submitting a...
[X] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Other... Please describe:
Browser:
- [X] Chrome version 74.0.3729.169 (Official Build) (64-bit)
- [ ] Firefox version XX
- [ ] IE version XX
- [ ] Edge version XX
- [ ] Safari version XX
Library version
Library version: 1.0.1
BoyanPalagachev
All 26 comments
This also didn't work prior to the version 1.0.0 update. It actually looks like it only worked in 1.0.0 as a result of a mistake on the intended boolean condition, which the commit you identified "fixed".
I submitted a PR #572 for a "loginSilent", but they were working on 1.0.0 at the time. I don't plan on updating my PR, but someone else is welcome to do something similar for the current version of the library.
Some related discussion can be found on #275.
It seems to me that this issue pretty strongly prevents any actual SSO behavior (being able to log into one application and let that count as being authenticated in a second application with no prompts to the user).
zamzowd
on 5 Jun 2019
The bug that gave us the desired behavior was introduced in this commit: https://github.com/AzureAD/microsoft-authentication-library-for-js/commit/e9204be39b4b797d0cd119888fdcab7b3f472363
Pretty clear that inverting the condition was not intended in this change.
zamzowd
on 5 Jun 2019
@zamzowd Thanks for bringing up the 'loginSilent' context. We are not allowed to send a request to service without any local cache/account information. But let me check with the service if this is something can be supported in the Azure AD world.
@BoyanPalagachev I am curious about one thing, Can you send a login_hint or account information as a part of your subsequent login request (this could be the second app) once you logged in with one application? We designed our SSO based on the existing account/hints information the user can pass to MSAL JS.
sameerag
on 6 Jun 2019
We are not allowed to send a request to service without any local cache/account information.
@sameerag I've seen this expressed by the team before - that this is a requirement. What is the cause or justification of this requirement?
Single Sign On behavior is generally achieved by letting an authentication on the authority count as authentication on all registered applications. Both Azure AD and Azure AD B2C can accept and respond to authentication requests with prompt=none and no hints. If the user already has an active session on the authority domain, it responds with the token, otherwise it responds that the user is unauthenticated. So far as I can tell, that's the intended behavior for OpenID Connect.
Both Microsoft docs and OpenID docs list login_hint as optional. (I couldn't find documentation for the sid query parameter). The closest the OpenID docs get to a required parameter for prompt=none is id_token_hint (which MSAL.js does not supply):
When possible, an
id_token_hintSHOULD be present whenprompt=noneis used and aninvalid_requesterror MAY be returned if it is not; however, the server SHOULD respond successfully when possible, even if it is not present.
Other client authentication libraries do not make any login hint required. So far as I can tell, this requirement only exists on this specific library.
zamzowd
on 6 Jun 2019
Thank you for your replies.
I see that there is possibility to call acquireTokenSilent specifying both request.sid and request.loginHint. I guess I can get the SID as suggested in this documentation article (in the "Using Session ID (SID)" section). Based on this documentation article, the login_hint is the username of the currently logged-in user. I could try and get both the SID and login_hint on the server side and inject those values when each SPA in loaded. @sameerag, is this what you would suggest?
BoyanPalagachev
on 9 Jun 2019
@BoyanPalagachev That is under the "Automatically select account on Azure AD" section of the article. Is having a single user logged in with multiple accounts simultaneously a scenario for you? How do you plan on determining which SID to provide?
So far as I can tell, the "Applications on different domains" section of the SSO article is actively blocked for acquireTokenSilent. I suppose the direction there indicates to use loginRedirect or loginPopup, and since the user is already authenticated they should be automatically redirected back to the application with a token.
zamzowd
on 10 Jun 2019
trying to clarify here, is this a bug or a feature request in line with login silent?
DarylThayil
on 21 Jun 2019
@BoyanPalagachev @zamzowd How did you overcome the issue? Did you end up downgrading the dependency version?
another-guy
on 22 Oct 2019
@another-guy Honestly, I switched to using https://github.com/IdentityModel/oidc-client-js
I'm sorry to direct anyone from here to a competing library, but don't want to avoid answering the direct question. SSO behavior across applications and without any user prompts is a primary requirement for me, and the PR I submitted didn't seem to get any traction.
If I had to stay with MSAL.js, I would have gone with maintaining my own fork with a loginSilent method available.
zamzowd
on 22 Oct 2019
@zamzowd thank you for your input. I am myself very surprised with the state of this issue.
another-guy
on 22 Oct 2019
@zamzowd Sorry to see you use something else other than MSAL JS :(
SSO without a login_hint is a little concerning model from our end. As I have mentioned before, SSO once you send a login_hint is supported today, SSO with apps that do not talk to each other and would like to piggy back on the AAD session is a little fuzzy for us to support. I have engaged the larger team on understanding use cases like this and see if there is a way to do this securely.
I do apologize though regarding the traction cycles, we have been dealing with multiple features and will try to do a better job closing loops going forward.
sameerag
on 29 Oct 2019
@sameerag That's exactly how SSO with OIDC is supposed to work, and Azure AD and Azure AD B2C both support that behavior. I haven't found any guidance other than from MSAL JS that login_hint or prompt should be required.
Remember that the applications all have to be registered onto the authority, so it's not like some rogue application can acquire authentication from SSO. If "piggy backing" on an existing session is still a concern even for registered applications, then that can be restricted on the authority (at least Azure AD B2C can).
The MSAL JS Core library is - fundamentally - a utility for constructing the OIDC authentication request and interpreting the response based on the OIDC spec. While additional features are nice, I feel that MSAL JS still fails in its fundamental utility because of these decisions on what to allow or disallow beyond what the specification says.
MSAL JS can't actually apply any real additional security, because a programmer can always simply construct their own authentication request. If a particular combination of arguments shouldn't be allowed, it is ultimately dependent on the the authority to reject the request. If a given request matches the specification, and the authority allows it, this library should be able to construct and deliver that request.
zamzowd
on 30 Oct 2019
I am having this problem too (msal v1.1.3 2019-08-14) and I have noticed that MSAL opens three popups instead of only one, one of the auto-closing and two of them not closing, staying blank (no URL loading). Have you also faced this issue?
Germain-Italic
on 6 Nov 2019
@sameerag do you know what may have changed to have caused this ? Do we have a repro?
DarylThayil
on 12 Nov 2019
Closing this as we are supporting silent logins only if there is a sid or login_hint passed into the library.
jmckennon
on 5 Dec 2019
Closing this as we are supporting silent logins only if there is a
sidorlogin_hintpassed into the library.
Can you please explain what sid and login_hint are ?
dusanjovanov
on 24 Mar 2020
@dusanjovanov
sid: session id
login_hint: used to pre-fill the username/email address field of the sign-in form. Apps can use this parameter during re-authentication.
check this out
derisen
on 24 Mar 2020
@derisen
Thanks for the response.
Is session id required for acquireTokenSilently to work ?
I get the Token calls are blocked in hidden frames error so I don't know if those things are related.
dusanjovanov
on 26 Mar 2020
@dusanjovanov no worries : )
both sid and login_hint are optional, so I don't think they are related to your issue here. You should be able to acquireTokenSilently as long as the user is already signed in, has a cookie and already consented to the scopes in the token. Is the error a breaking error? Can you take a look at this issue here?
derisen
on 26 Mar 2020
@dusanjovanov no worries : )
both
sidandlogin_hintare optional, so I don't think they are related to your issue here. You should be able toacquireTokenSilentlyas long as the user is already signed in, has a cookie and already consented to the scopes in the token. Is the error a breaking error? Can you take a look at this issue here?
Isn't this issue specifically about making acquireTokenSilent without sid nor login_hint, and it was closed saying that the library will continue to require one of those?
They aren't required in the specification, and setting up the request outside of this library with prompt=none does get a successful response if the user has a cookie on the authority, but unless something has changed this library does require one of them to be available for acquireTokenSilent.
zamzowd
on 26 Mar 2020
@zamzowd sorry, my bad. I was referring to general acquireTokenSilent case. Indeed in SSO scenario one of them is required now. The documentation hasn't catch up unfortunately : (
derisen
on 26 Mar 2020
Where exactly can "sid" be acquired from in a b2c scenario?
alex-mason-by
on 2 Apr 2020
Closing this as we are supporting silent logins only if there is a
sidorlogin_hintpassed into the library.
This is an artificial limitation from your side. More on that you even don't fully implement this your limitation: if a user signed in on domain A and then will open domain B then acquireTokenInteractive method from your library will do actual silent login without login_hint or sid. Why in your opinion acquireTokenSilent is not allowed to do this?
es-repo
on 4 Apr 2020
Closing this as we are supporting silent logins only if there is a
sidorlogin_hintpassed into the library.
I have to agree with @es-repo in that this is an artificial limitation.
andersthorsen
on 23 Apr 2020
B2C as a platform should work seemlessly as a login platform without tons of coding to adjust to all its quirks.
The requirement for sid or login_hint isn't even a Azure AD B2C thing. It works perfectly fine without those. So far as I can tell, this is only a thing in MSAL.js, and nowhere else.
zamzowd
on 23 Apr 2020
acquireTokensilent is still failing to get the token with error in case of multiple Azure AD accounts logged in the browser. Tried passing sid and loginHint but i think they are not at all being considered as don't see any difference in the output and error. Can someone help regarding this issue?
I am using the latest 1.0.0 version of msal-angular.
@jmckennon I saw you Comment that we are supporting with sid and loginhint but i dont see that working.Can you please suggest ?
ramya-chekka
on 20 May 2020
Related issues
spottedmahn
路
4Comments
Anees-Raja
路
3Comments
jfbloom22
路
3Comments
baltuonis
路
4Comments
ArneMancofi
路
3Comments
Most helpful comment
This is an artificial limitation from your side. More on that you even don't fully implement this your limitation: if a user signed in on domain A and then will open domain B then
acquireTokenInteractivemethod from your library will do actual silent login withoutlogin_hintorsid. Why in your opinionacquireTokenSilentis not allowed to do this?