Authorization prompt=none has only openid scope, not scopes from settings

[michael-mccoy]

It appears that no matter what scopes I specify in the settings, when the prompt=none request fires it only contains openid scope. The original sign in authorization contains the scopes from the settings, just not the prompt=none. Is this intended, any suggestions?

[brockallen]

It appears that no matter what scopes I specify in the settings, when the prompt=none request fires it only contains openid scope. The original sign in authorization contains the scopes from the settings, just not the prompt=none. Is this intended, any suggestions?

This is only done for the querySessionStatus, IIRC (and this is used as part of the monitor session feature). signinSilent should use the full scope.

[michael-mccoy]

What is the difference between the two? It looks like the lib is triggering prompt none as soon as I am redirected back and complete the code exchange. But our identity server requires an additional scope param besides oidc.

[brockallen]

One just queries, whereas the other establishes a session based on the results. As for your STS, not sure. Seems odd that you can't just request openid.

[michael-mccoy]

I think what's happening is on the redirect back from sign in, the session monitoring is doing its prompt=none and triggering a code exchange from that code before the app does the code exchange from the redirect code. I am seeing this on the code-identityserver-sample.html.

[brockallen]

You can disable the session monitoring then on the callback page. There's a flag on the settings.

[michael-mccoy]

I see the flag, I want session monitoring enabled on the callback page, I just don't want it making prompt=none requests and possibly generating tokens before the app calls signinCallback to generate a token from the url. Is there a method to essentially startSessionMonitoring on UserManager?

[brockallen]

Sorry, nothing like that. The callback page should only be run to process the result and then redirect to whatever page your app is.

[michael-mccoy]

Cool thanks

[michael-mccoy]

Reopening this. I wanted to go back to the original question about prompt=none not having all the scopes from the settings.

It appears that no matter what scopes I specify in the settings, when the prompt=none request fires it only contains openid scope. The original sign in authorization contains the scopes from the settings, just not the prompt=none. Is this intended, any suggestions?

This is only done for the querySessionStatus, IIRC (and this is used as part of the monitor session feature). signinSilent should use the full scope.

Are you saying we can't use the session monitoring feature because our idp requires more than just openid to get a token? Curious why it doesn't just contain all the scopes from the settings?

[brockallen]

Curious why it doesn't just contain all the scopes from the settings?

Because the response only needs an id_token to do its job. It's too much to also request (and receive) an access token.

What token server do you use?

[michael-mccoy]

Does the spec have access_token as optional from a successful token response for the auth code flow? Looking here seems to indicate it is always part of the successful response.

[brockallen]

That's a good point -- the original implementation of this library was implicit flow only, and code flow was added later. But still, having a downscoped access token is not a bad thing.

Again, I'm curious what token server you're using that won't process just the "openid" scope?

[michael-mccoy]

Yea you are correct in that the authorization server should be able to handle only openid, but a little unsure why any prompt=none call wouldn't contain the other scopes from settings. Perhaps there's something else going on here I'm not understanding. https://accounts.nike.com/.well-known/openid-configuration

[brockallen]

Sorry, not sure. Perhaps ask the token server vendor/developer why?