Identityserver4: Parameter `session_state` not being returned for failed auth requests

[aryzing]

We're currently using Identity Server with the session management extension enabled. When the user successfully logs in, session_state is present in the 302 redirection when using the code flow. However, if the auth fails, as per spec,

Session state SHOULD be returned upon an authentication failure.

but it is not being returned,

This is causing unexpected behavior in the RP iframe since it can't send a session state value to the OP iframe for it to calculate any state changes.

Could this be a config issue on our side, or is ISv4 simply not returning session_state when the Auth fails (despite having the session extension enabled)?

[brockallen]

session_state is different than the state param. are you confusing those? also, if there's an error for most scenarios we don't redirect back to the client, due to guidance issued after the OAuth2/OIDC specs were finalized: https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00

[aryzing]

session_state is different than the state param. are you confusing those?

Thanks for the quick reply. I actually do mean session_state (as per the linked specs in the original post). In our case, we only redirect back to trusted uris, so that's not an issue.

[brockallen]

Ok, I went back and checked that section in the spec. To be honest it's not clear to me what that sentence means. If authentication fails, you'd not have a session, so how would you have a session state to return.

Also, oidc-client.js already implement this for you (https://github.com/IdentityModel/oidc-client-js/), so not sure you need to do all this work yourself.

[aryzing]

Session state is just a function of the client id, origin, and perhaps the End-User's auth state. So even if the user has no session, a session_state value can still be created. What's important is that this session state is created using the same algorithm on the server and on the OP's iframe, so that the RP iframe can send it over and thus enable the OP to calculate whether it has changed or not.

Anyhow, I have looked into oidc-client.js, however, as far as I can tell, it only supports a getUser method that attempts to authenticate the user once when called. The idea behind implementing this myself is allowing for the constant polling of the OP iframe. Which is why I care so much about the session_state parameter :)

[brockallen]

Anyhow, I have looked into oidc-client.js, however, as far as I can tell, it only supports a getUser method that attempts to authenticate the user once when called.

There's a lot more to it than that, and it automatically handles check session for you, including creating the iframe, polling, and re-requesting authorization w/ prompt=none if the response is changed. Also, it provides an event to let you know if the user's session has changed at the OP. In short, if you didn't want to implement it yourself then it's already all done and packaged for you already.

[brockallen]

Session state is just a function of the client id, origin, and perhaps the End-User's auth state.

We don't have a session state for anonymous users (mainly because the user's sid is maintained inside the authN cookie that we issue). That one-liner in the session mgmt spec certainly was not clear enough (for me at least) to consider returning one for anonymous users (especially given that it's in the RP Iframe section... shrug).

Anyway, we can consider it. It'd not be too difficult. Again, though, the absence of one certainly tells your client that you need to re-auth the user, right?

The only real benefit of adding it, as I can see, is that it might somehow protect the end user from a client sniffing their authN vs. anonymous status at the OP.

[aryzing]

we can consider it.

That would be awesome :)

tells your client that you need to re-auth the user, right?

Yes, but it doesn't allow for polling of the OP iframe. So if a user obtains a session elsewhere (in another tab) the only way to determine that that change has happened is by sending an http request to the auth endpoint, spending bandwidth. Checking the iframe is "free" :) But going back to my original point, this is not possible to do if there's no server-calculated session_state to send to the iframe in the first place.

[brockallen]

Ok, I see your point. So the anon session state will change once authenticated.

But if the client has no user, I guess I don't see the use case of polling check_session to know when they're authenticated. What's what use case, or what kind of app are you building where that's needed?

[aryzing]

For example, it's not uncommon for, what is perceived as a single app, to be in fact powered by many "smaller" apps, each with their own codebase. However, all using a single Authorization Server.

Say that each app is under

app1.example.com
app2.example.com
...

if a user logs in from app1.example.com, it would be nice to have app2 react accordingly (say, display that user's username or something).

In the case were a tab to app2 was already open, I would expect that, because the RP iframe from app2 is polling the same checksession OP iframe, it would be informed that there has been a change, and react accordingly, fetching the user's credentials.

[brockallen]

I guess I'm still confused. Why wouldn't the app just trigger authorize and get the user logged in? Or is it more that app2 just wants to allow the user to stay anonymous until it detects they have logged in (presumably in another tab)?

[aryzing]

app2 just wants to allow the user to stay anonymous until it detects they have logged in

Correct. app2 may have public and private routes, but the public routes' UI may be decorated differently if they detect that the user has authenticated (eg. display "Sign In" vs "Hi Alice!" in a navbar for a FAQ page)

[brockallen]

Ok, got it.

[aryzing]

Closing down, feature request in #2289

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.