manfredsteyer / angular-oauth2-oidc

Support for OAuth 2 and OpenId Connect (OIDC) in Angular.
MIT License
1.89k stars 688 forks source link

Logout does a navigate (GET), would be more secure with a POST #531

Open filipvh opened 5 years ago

filipvh commented 5 years ago

As it is now, when you do a logout oauth-service.ts:1769 it simply sets 'location.href'. While all communication should happen over HTTPS, when (and if) logs get leaked/exposed, one could use information from the URL. Since a POST would also be an option, this would be preferred.

jeroenheijmans commented 5 years ago

Interesting suggestion. I'm not sure how sensitive logout info would be, but I do suppose it wouldn't hurt to try and hide it from said logs.

As far as I can tell, the relevant spec says nothing explicitly about the http methods that should be supported by the ID Server for the log out endpoint. Still, even though a cursory check at IdentityServer4's code suggest that ID solutions do support it, I wouldn't dare assume that all of them do. So I'd suggest this would have to be an opt-in feature (or otherwise at least part of a major update, possibly with an opt-out toggle).

filipvh commented 5 years ago

The current method has a boolean that if true, skips the logout redirect/GET a second boolean, or a config obj, ... something would indeed make sense I would however, in documentation, push people into using it (POST), since I would consider it a best practice if supported.

lbuyse commented 2 years ago

Hello , From the OIDC spec (https://openid.net/specs/openid-connect-rpinitiated-1_0.html ):

OpenID Providers MUST support the use of the HTTP GET and POST methods defined in RFC 7231 [RFC7231] at the Logout Endpoint. RPs MAY use the HTTP GET or POST methods to send the logout request to the OP. If using the HTTP GET method, the request parameters are serialized using URI Query String Serialization. If using the HTTP POST method, the request parameters are serialized using Form Serialization.

Enabling a logout through POST method would not only make sense security wise , but also technically. In our case some of our logout requests exceed the HTTP url limit of 2048 characters because in some cases the base64 encoded 'id_token_hint' param is too large and the total url exceeds 2048 characters. This results in logout requests being blocked by our WAF (Web Application Firewall).

Technically speaking, your URL should never be longer than 2,048 characters. Any longer than this and Internet Explorer won’t be able to load your page.

The 'id_token_hint' doesn't even have to be that big for the url to exceed the limit ...

schettn commented 3 months ago

@lbuyse Why not just use client_id instead of id_token_hint?

client_id: The most common use case for this parameter is to specify the Client Identifier when post_logout_redirect_uri is used but id_token_hint is not. Another use is for symmetrically encrypted ID Tokens used as id_token_hint values that require the Client Identifier to be specified by other means, so that the ID Tokens can be decrypted by the OP.