The redirect URI is not well-formed. The URI is: 'http://грант.рф:5000/connect/authorize ...

[myrtex]

Guys, hello!

When I use OpenIdConnect I have a problem in a OpenIdConnectHandler (394 line)

So, I use a cyrillic domain http://грант-лев.рф and redirect URI in OpenIdConnectHandler looks incorrect.
The redirect URI is not well-formed. The URI is: 'http://грант-лев.рф:5000/connect/authorize?client_id=RosgrantService&redirect_uri=http%3A%2F%2Fxn----7sbhbm9amwu.xn--p1ai%3A5002%2Fsignin-oidc&

Seems, punycode like here redirect_uri=http%3A%2F%2Fxn----7sbhbm9amwu.xn--p1ai
would be good, but I dont know where I can handle it.

Moreover, after this warning I catch an exception in kestrel

System.InvalidOperationException: Invalid non-ASCII or control character in header: 0x0433 at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.FrameHeaders.ThrowInvalidHeaderCharacter(Char ch) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.FrameHeaders.ValidateHeaderCharacters(String headerCharacters) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.FrameHeaders.ValidateHeaderCharacters(StringValues headerValues)
....

So, how can I turn my cyrillic domain to punycode to prevent warning and a Kestrel craching in OpenIdConnectHandler?

Thank you for your advice!

[Tratcher]

Interesting catch. @brentschmaltz this may be a bug in CreateAuthenticationRequestUrl.

[Tratcher]

@levnikolaevich if you look at the metadata document OIDC downloads for configuration, the host value is not encoded in there is it?

[myrtex]

@Tratcher
Do you mean this metadata?

Client configuration looks like this

[Tratcher]

Yes. One way of addressing this is changing the metadata. Can you do that?

Also, why did you add ConvertToAscii for your Authority? We should be able to handle that one in Unicode.

[myrtex]

@Tratcher , I'm using idsrv4. I think, I don't have a direct access to that code. I've asked their support for help.
I'll let you know if we come up with something.

PS ConvertToAscii was just for a experiment =)

[Tratcher]

Ok, the other workaround you can try is setting the Options.Configuration property and manually entering the metadata with encoded urls.

[Eilon]

Tagging @leastprivilege re: idsrv4. Any ideas on this? This hostname should probably be punycode encoded in the metadata document itself.

[leastprivilege]

I have no idea.

[Eilon]

@leastprivilege do you suggest that this bug should be tracked by your org? We couldn't think of anything in ASP.NET Core that would be causing this.

[myrtex]

@Eilon , @leastprivilege, hello!
Actually, I've found a problem here. https://github.com/IdentityServer/IdentityServer4/blob/ecffbb062485b0656461eba4af5648dc9f45a589/src/IdentityServer4/Hosting/BaseUrlMiddleware.cs#L32

request.Host.Value contains the original host name (http://грант-лев.рф), not a punycode

I resolved my issue the following way
http://amilspage.com/set-identityserver4-url-behind-loadbalancer/

it also helped me with https issue.. =)

Seems, you can close this issue

[myrtex]

@Tratcher , thank you very much for your help!

[Tratcher]

https://github.com/IdentityServer/IdentityServer4/blob/ecffbb062485b0656461eba4af5648dc9f45a589/src/IdentityServer4/Hosting/BaseUrlMiddleware.cs#L31 does look like a bug in idsrv4. It should consider the host encoding when generating addresses.

[brockallen]

@levnikolaevich there's a PublicOrigin setting you can use for this scenario as well: http://docs.identityserver.io/en/release/reference/options.html#identityserver-options

[brockallen]

@Tratcher can you elaborate?

[Tratcher]

While the OIDC spec doesn't call out the host encoding specifically, it repeatedly sites RFC 3986 URLs which do not allow unicode. That makes sense as several of these urls values are intended for use in redirect Location headers and must be encoded there.

[brockallen]

So you're saying the incoming value for the host could be unicode? I guess I'm confused why ASP.NET Core would allow that in in the first place if it's not a valid host value.

[kevinchalet]

it repeatedly sites RFC 3986 URLs which do not allow unicode

The URI spec is not that restrictive:

The reg-name syntax allows percent-encoded octets in order to represent non-ASCII registered names in a uniform way that is independent of the underlying name resolution technology. Non-ASCII characters must first be encoded according to UTF-8 [STD63], and then each octet of the corresponding UTF-8 sequence must be percent-encoded to be represented as URI characters.
When a non-ASCII registered name represents an internationalized domain name intended for resolution via the DNS, the name must be transformed to the IDNA encoding [RFC3490] prior to name lookup. URI producers should provide these registered names in the IDNA encoding, rather than a percent-encoding, if they wish to maximize interoperability with legacy URI resolvers.

http://грант.рф:5000/ is a perfectly valid URI representation when percent-encoded and I don't see why it couldn't be returned without being puny-encoded first by an OIDC server (tho' it's likely not a good idea since many clients won't be able to deal with such URIs).

The real issue is that this address is used as-is by the OIDC handler that blindly calls HttpResponse.Redirect() without ensuring the URI can be used in a HTTP header (retrospectively, Redirect should probably take a Uri instance and rely on Uri.IdnHost to compute a safe address).

That said, it's absolutely not a new issue. I'm pretty sure even the Katana OIDC middleware had the same problem (which is why I personally went with the safest option, i.e returning punycode-encoded URIs).

Edit: in the URL "living" standard proposed by the WHATWG, percent or puny-encoding is no longer necessary for many Unicode chars:

The URL code points are ASCII alphanumeric, U+0021 (!), U+0024 ($), U+0026 (&), U+0027 ('), U+0028 LEFT PARENTHESIS, U+0029 RIGHT PARENTHESIS, U+002A (*), U+002B (+), U+002C (,), U+002D (-), U+002E (.), U+002F (/), U+003A (:), U+003B (;), U+003D (=), U+003F (?), U+0040 (@), U+005F (_), U+007E (~), and code points in the range U+00A0 to U+10FFFD, inclusive, excluding surrogates and noncharacters.

[Tratcher]

@brockallen HostString.Value returns the decoded from. HostString.ToString() or ToUriComponent gives the encoded form.