Add ID Austria to the list of supported providers

[kescherCode]

This pull requests adds support for ID Austria, the Austrian governmental electronic identity service, as a web service provider. Both government entities and private entities (as long as they exist as a company) can create registrations for it in the "company service portal" (https://usp.gv.at).

Developer documentation, unfortunately, only exists in German.

I've validated that these changes work by locally adding the provider and the required credentials (client ID and secret) to the sandbox projects, and setting the required callback URLs at the service registration.

Some notes on the implementation:

• There are two environments, the one usually used to test implementations is called "Referenz", "REF" for short, which I've taken the liberty to loosely translate to "reference".
• For some reason, the backchannel identity token contains a "sub" node with some value which changes on every login, which would by default be mapped to the NameIdentifier claim by MapStandardWebServicesFederationClaims, and is described by the documentation as "transient value that should instead be replaced with the bPK value". Therefore, I added some code to replace the NameIdentifier claim below the condition that would usually handle a missing NameIdentifier claim in MapCustomWebServicesFederationClaims. Feel free to adjust this check or let me know what to adjust about it, I am somewhat unhappy about the place I had to put this workaround into for a consistent (per app registration) user identifier.
• No userinfo endpoint exists because the implementation has deliberately been made in a way where issued tokens cannot be directly mapped back to persons. This is why the "bPK" value exists. More has been described, also only in German, at https://www.bundeskanzleramt.gv.at/agenda/digitalisierung/stammzahlenregisterbehoerde/bereichsspezifische-personenkennzeichen/beschreibung.html

[kevinchalet]

Thanks for your PRs!

(the fact this provider returns a non-stable sub identifier is extremely unusual, but I guess there's a first for everything 🤣)

[kevinchalet]

Please ignore the build errors: they are caused by a vulnerable transitive package referenced by the EF Core SQLite package: dotnet/efcore#38257. I'll take care of that in a separate PR.

[kescherCode]

Thanks for your PRs!

(the fact this provider returns a non-stable sub identifier is extremely unusual, but I guess there's a first for everything 🤣)

I was honestly surprised myself, given they could just set the value in their custom bPK claim into the sub claim instead. But, they don't.

[kevinchalet]

I was honestly surprised myself, given they could just set the value in their custom bPK claim into the sub claim instead. But, they don't.

It's not super clear what they are trying to achieve with that weird approach. If they wanted to prevent tracking across multiple clients, they could have implemented pairwise subject identifiers instead, which is a fully standard thing: https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes.

[kescherCode]

I was honestly surprised myself, given they could just set the value in their custom bPK claim into the sub claim instead. But, they don't.

It's not super clear what they are trying to achieve with that weird approach. If they wanted to prevent tracking across multiple clients, they could have implemented pairwise subject identifiers instead, which is a fully standard thing: https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes.

Well, they are also a SAML2 provider, and they've kind of defined this specific identifier outside of any other standard. I guess that may be one reason they are not specifically doing that. But I agree that they could've picked some standard way of achieving this.

[kevinchalet]

Note: the build errors should go away if you merge dev into your branch or rebase it on top of dev.

[kevinchalet]

Please don't hesitate if you need help to finish that PR 😃

[kescherCode]

I was busy otherwise, but I've finished up this PR now and I think that everything is covered.

[kevinchalet]

Merged (with a few minor modifications): 948e3fe.

Thanks for that PR and congrats for your first contribution to OpenIddict 👏🏻