Since the release of our IdentityModel.OidcClient client library we have had iOS and Android samples for using the system browser to allow a user to authenticate with the token server. Receiving the results from the system browser is interesting since the native client application is in a different process than the system browser. Fortunately those platforms provide an easy way to map a custom URI scheme (used in the client’s redirect_uri) to the native client application. This allows the response parameters from the authorize endpoint to be passed from the system browser into the native client so it can complete the protocol workflow.
Windows also has such a facility, but we never had a sample for it… until now. I just created a sample that does this.
There are two main aspects that are specific to Windows clients. First, the application needs to add certain registry keys to enable…
View original post 93 more words
leastprivilege.com 
Ich finde das einen guten Ansatz. Der callback über einen shared port hat in der Praxis einen wesentlichen Nachteil.
Dadurch, dass der shared port zum empfangen des redirects erst bei der Nutzung geöffnet wird, kommt es sporadisch immer wieder zu belegten Port-Situationen durch andere Programme, welche für sendenden Verkehr Ports exklusiv öffnen.
Unsere bisherige Idee diesem Problem entgegenzuwirken ist einen Port bereits beim Systemstart shared zu öffnen.
Die Idee mit dem benutzerdefinierten URI-Schema war uns bezüglich der Rück-Kommunikation in den eigentlichen Prozess zu komplex. Schön, wenn diese Möglichkeit künftig in die Bibliothek einfließt. Bleibt noch die Frage nach der Performance wegen des zusätzlichen Prozess-Start zu beantworten.
Good work Dominick and Brocke