in your documentation you mention a third party plugin to use ServiceStack together with IdentityServer. With your JwtProviderReader it's actually already possible:
host.Plugins.Add(new AuthFeature(() => new AuthUserSession(),
PublicKeyXml = _config.TokenSigningCertXml, // may also be fetched from https://demo.identityserver.io/.well-known/openid-configuration/jwks
HashAlgorithm = "RS256",
Audience = "xxxxx",
ServiceRoutes = new Dictionary<Type, string>() // it throws a NullRef if not initialized :(
I'd propose to mention this in your documentation.
There are 3 small things to fix:
JwtAuthProviderReader throws if not initialized.
"Aud" check should be contains and not ==
The RFC (https://tools.ietf.org/html/rfc7519#section-4.1.3)
The "aud" (audience) claim identifies the recipients that the JWT is
intended for. Each principal intended to process the JWT MUST
identify itself with a value in the audience claim
if (jwtPayload.TryGetValue("aud", out audience))
if (!audience.Contains(Audience)) // <-- contains
throw new TokenException("Invalid Audience: " + audience);
But i also see that contains might be problematic. But since in the RFC there is no separator defined, i think it's the only viable option.
- Map values to session
Claims are defined here: http://www.iana.org/assignments/jwt/jwt.xhtml
Since you call session.PopulateFromMap(jwtPayload); in CreateSessionFromPayload, it would make sense to map those Fields also in PopulateFromMap() like you do in JwtAuthProvider.CreateJwtPayload.
In our case we had to fork JwtAuthProviderReader to map auth_time, nickname, given_name, family_name.
What dou you think about those changes?
I could do a PR, but just if you are interested...
Sure would love a PR I've never used Identity Server but it would be great value add if they could be integrated easily, happy to accept PRs which make this easier.