authorize uri overrides and sid security

[Annaseron]

the first question,
a user wants to login system A,and the UA redirect to the login page, name it to Page1,and do not login,
then he open a new tab page to visit system B,then ,the UA redirect to the login page as well, name it to Page2
then he back to the Page1 and do login, he will login system B rather than A,which is not act as expected---on Page1,he can login to System A,and on Page2 he can login to System B,and the code request uri should not override.

the second one,
I think the sid should be encrypted and only be decrypted by the OP, instead of exposing the original value to the RP in the IDToken. If a valid IDToken is leaked from one of the RPs, then someone may be able to log into other RPs.

Please correct me if I missed something

[sjohnr]

@Annaseron,

a user wants to login system A,and the UA redirect to the login page, name it to Page1,and do not login,
then he open a new tab page to visit system B,then ,the UA redirect to the login page as well, name it to Page2
then he back to the Page1 and do login, he will login system B rather than A,which is not act as expected---on Page1,he can login to System A,and on Page2 he can login to System B,and the code request uri should not override.

Thanks for getting in touch, but it feels like this is a question that would be better suited to Stack Overflow. We prefer to use GitHub issues only for bugs and enhancements. Feel free to update this issue with a link to the re-posted question (so that other people can find it) or add a minimal sample that reproduces this issue if you feel this is a genuine bug.

I will mention that the behavior you're describing sounds specific to Spring Security's RequestCache. See also Handling Security Exceptions, looking specifically at AuthenticationEntryPoint.

I think the sid should be encrypted and only be decrypted by the OP, instead of exposing the original value to the RP in the IDToken. If a valid IDToken is leaked from one of the RPs, then someone may be able to log into other RPs.

Thanks! We will open an issue for this to be addressed prior to the 1.1.0 release.

[jgrandja]

@Annaseron FYI, see gh-1207. Thank you for reporting this!