Session created by the OAuth flow should be short lived

[thingersoft]

Describe the bug
Session (Security Context) created following request to the authorization endpoint survives after the related access token has been released.

To Reproduce

1. Create two simple webapps: an authorization server based on SAS and a basic OAuth client app.
2. Login into the client webapp through the authorization server.
3. Logout from the client app (destroy client app session).
4. Try to login again into the client app

You will find yourself automatically logged in with the same account without being asked for consent and/or having the chance to switch to a different account.
This is due to the session-stored security context created during the authorization grant issuing phase.

Expected behavior
I would expect the security context to be destroyed after access token has been issued.
I think this should be the default (and possibly configurable) behaviour.

I would be happy to contribute but I would like to hear comments before coming up with a PR.

[jgrandja]

@thingersoft I'm not fully understanding the issue you reported here.

As far as the Session TTL and the Access Token TTL, there is no relation between the two. The Access Token could live longer or shorter than the Session. I'm not sure why you think these 2 should be linked? Did you read this somewhere in the related specs?

You will find yourself automatically logged in with the same account without being asked for consent and/or having the chance to switch to a different account.

Try the Demo Sample and you will see the Logout works as expected - you will need to log in again but consent might not be required if you previously granted consent.

I would expect the security context to be destroyed after access token has been issued.

I don't understand this? Please provide your reasoning for this. Did you read this in one of the related specs?

[thingersoft]

Try the Demo Sample and you will see the Logout works as expected - you will need to log in again but consent might not be required if you previously granted consent.

@jgrandja
I took a quick look at the demo code and it seems like the client is performing an OID Connect logout.

Upon further investigation I see that session management is really up to the single AP so I'm closing the issue.

What I was really looking for probably was the "login" value of the OID prompt parameter, it would be great if Spring AS could add support for it ( #501 upvoted).

Thanks for your time.

[jgrandja]

@thingersoft

I see that session management is really up to the single AP

That's correct. The authentication sub-system is managed separately from the authorization server. There could be 1 Idp configured or multiple Idp's configured in a federation. Either way, the authentication system is not a concern of Spring Authorization Server. This is typically configured using Spring Security integrations. The only requirement for certain oauth2 flows, e.g. authorization_code, is that the request is authenticated.

gh-501 has quite a few upvotes so it will likely get scheduled for 1.4.

[thingersoft]

@jgrandja

gh-501 has quite a few upvotes so it will likely get scheduled for 1.4.

Thank you, I would be available for a PR if you want/need.

[jgrandja]

@thingersoft I'll keep you posted when gh-501 is planned for a release.