Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

/signout-oidc endpoint on ASP.NET WebForms client #43

Closed
deastr opened this issue Apr 3, 2017 · 12 comments
Closed

/signout-oidc endpoint on ASP.NET WebForms client #43

deastr opened this issue Apr 3, 2017 · 12 comments

Comments

@deastr
Copy link

deastr commented Apr 3, 2017

I have an IdentityServer4 provider and I'm trying to connect an ASP.NET WebForms 4.5.2 client using OpenIdConnect 3.0.1. Everything works fine but I'm having a problem with /signout-oidc endpoints on the WebForms client: it doesn't seem to exist. I'm getting 404 error. Interestingly, /signin-oidc does exist. I'm using same configuration for an ASP.NET Core client with the same OpenIdConnect 3.0.1 version and /signout-oidc does work there. Am I doing something wrong?

Here's the /connect/endsession/callback and /signout-oidc log from logout process using Fiddler:

GET /connect/endsession/callback?sid=5f5617803ca616c7cb247d2d30f178af&logoutId=1ea004139be63cfd7d088ef6ea1483be HTTP/1.1

HTTP/1.1 200 OK
Date: Mon, 03 Apr 2017 08:08:53 GMT
Content-Type: text/html; charset=UTF-8
Server: Kestrel
Cache-Control: no-store, no-cache, max-age=0
Pragma: no-cache
Set-Cookie: idsrv.ClientSessions.5f5617803ca616c7cb247d2d30f178af=.; expires=Sun, 03 Apr 2016 08:08:53 GMT; path=/; httponly
Set-Cookie: LogoutMessage.1ea004139be63cfd7d088ef6ea1483be=.; expires=Sun, 03 Apr 2016 08:08:53 GMT; path=/; httponly
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline' 'sha256-u+OupXgfekP+x/f6rMdoEAspPCYUtca912isERnoEjY=';frame-src http://localhost:9869
X-Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline' 'sha256-u+OupXgfekP+x/f6rMdoEAspPCYUtca912isERnoEjY=';frame-src http://localhost:9869
Content-Length: 223

<!DOCTYPE html><html><style>iframe{display:none;width:0;height:0;}</style><body><iframe src='http://localhost:9869/signout-oidc?sid=5f5617803ca616c7cb247d2d30f178af&iss=http%3A%2F%2Flocalhost%3A3027'></iframe></body></html>

GET /signout-oidc?sid=5f5617803ca616c7cb247d2d30f178af&iss=http%3A%2F%2Flocalhost%3A3027 HTTP/1.1

HTTP/1.1 404 Not Found
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/10.0
X-SourceFiles: =?UTF-8?B?RDpcUHJvamVjdHNcS1lTVjNcU291cmNlXElkZW50aXR5LkF1dGhlbnRpY2F0aW9uXFRlc3RzXElkZW50aXR5LkF1dGhlbnRpY2F0aW9uLkNsaWVudC5XZWJGb3Jtc1xzaWdub3V0LW9pZGM=?=
X-Powered-By: ASP.NET
Date: Mon, 03 Apr 2017 08:08:53 GMT
Content-Length: 5089

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml"> 
<head> 
<title>IIS 10.0 Detailed Error - 404.0 - Not Found</title> 
...
@Tratcher
Copy link
Member

Tratcher commented Apr 3, 2017

Katana does not implement /signout-oidc, that was first implemented in ASP.NET Core.
aspnet/Security@d6763bd

@deastr
Copy link
Author

deastr commented Apr 4, 2017 •
edited

@Tratcher : Thank you. I'm just curious why was signin-oidc was implemented but not signout-oidc?

Also do I need an additional step for signouts on WebForms other than /connect/endsession/callback? IdentityServer3 defines a SignoutCleanup process but do you reckon it's needed?

@Tratcher
Copy link
Member

Tratcher commented Apr 7, 2017

@deastr The sign-out standard was still being developed when Katana released.

You primarily need to clear auth cookies and any Session contents.

@deastr deastr closed this as completed Apr 7, 2017
@DerAlbertCom
Copy link

The Problem is that it is not possible to identity the current user, because the signout callback is done on an iframe. so the auth cookie will not be send reliable (only if 3rd Party Cookies are allowed, or the IdServer is in the trusted sites on IE). But with no Cookie, it is not possible to check if the signout request ist Valid. So how to do this?

@Tratcher
Copy link
Member

@DerAlbertCom If that's true then the spec itself is flawed. Do you have this problem in other browsers?

@DerAlbertCom
Copy link

@Tratcher yes, the openid spec is flawed in my opinion, for GET based sign outs. Maybe that's the reason that there is also a backchannel signout specified.

Modern browser don't send 3rd party cookies to avoid tracking. So if the Identity Provider (like IdentityServer3/4) is running on a different Domain, and is trying to log out the client it is done via a simple iframe which calls the signout uri. No cookie is send in that case.

In IE you can add the Identity Provider Uri to the trusted sites (possible in Company Environments) and in Firefox and Chrome you can allow 3rd Party Cookies. Then it works as expected. But as a developer I have no impact on that.

@Tratcher
Copy link
Member

@brentschmaltz ?

@brentschmaltz
Copy link
Contributor

@DerAlbertCom @Tratcher what kind of feedback are you looking for here?
Think we should ping Mike Jones?

@Tratcher
Copy link
Member

Yes, please

@brentschmaltz
Copy link
Contributor

@Tratcher done.

@selfissued
Copy link

The sid=5f5617803ca616c7cb247d2d30f178af parameter enables you to identify the user. Match the sid value with the "sid" claim in the ID Token that was sent at login time. That way, you can sign out only that user. Alternatively, some implementations ignore the "sid" and sign out all users upon receiving the front-channel logout message.

@DerAlbertCom
Copy link

DerAlbertCom commented Jul 26, 2017 •
edited

@selfissued it is not possible to verify the user because no cookie get sent (on different domains then the OP) which allows to identify the user, login out regardless of the sid is a great possibility for a Denial of Service.

@brentschmaltz the feedback i'm looking is a possibility to log the user securely logout. But this seems not possible with OpenId Connect Front Channel Logout.

Sorry, i'm on vacation, so this answer took awhile

@aspnet aspnet locked as resolved and limited conversation to collaborators Jan 6, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@DerAlbertCom @Tratcher @brentschmaltz @selfissued @deastr