1. Choosing an RP Product
As said in previous chapter, there are multitude of products and implementations available for OIDC. You should start your journey from the list of certified products and implementations.
Also, if still planning on relying on SAML, there also is very wide range of different solutions.
Following sections that present RP solutions contain huge amount of details. We don’t repeat all technical details here, so please follow the provided links if mentioned terms sound unfamiliar. Also, we don’t currently give an example code snippets on how to configure recommended solutions. Most implementations provide the code snippets already.
We are planning in publishing a demonstration template implementations that you could use as starting point for your application if such can’t easily be found yet.
First things first, there is an important announcement that we need to make:
Do Not Plan on Writing Your Own
This is so important that we want to dedicate a complete sub-section for this. OIDC is fairly simple to implement. We see it often that developers take the product reference documentation and start coding their own implementation. Sometimes even IdP product vendors call their IdP as authentication API where the service developer is thought to connect.
This is where things may fail severly. Even though OIDC, JSON and JWT are fairly simple, the protocols and specifications define quite detailed security and privacy controls.
OIDC is simple in a sense that developers can get their implementations working quite easily and then they think that it just works and move on to next problem. When it just works, it is not said that it implements the security controls that are baked deep in the specifications.
With this in mind, if you had initial thought that you will implement your own OIDC client, please give it another thought. There is multitude of thoroughly implemented products already. What makes you think that your own implementation would be at all better or secure?
One better step forward from the thought of writing your own is to use a ready library or the functionality already in the development framework or coding platform that you are using. However, even with those, you should make sure that you are using the authentication functionalities to their full extent when it comes to securing your application.
Now, sorry about the rant and let’s move forward.
We will give few examples of possible products to use as Relying Party RP implementation.
Apache HTTPD & mod_auth_openidc
Hans Zanbelt has written very good implementation of OIDC RP, the mod_auhn_openidc. Hans Zanbelt is widely respected specialist in the field and provides support for the product through his company.
mod_auth_openidc plugs in to Apache HTTPD Web server that can function fairly efficiently as authenticating reverse HTTP Proxy.
The mod_auth_openidc project already has very good configuration documentation and example configuration snippets that you can use to get your project started.
You can find one sample of using the module with Olevi IdP here.
Spring Framework and Spring Security
If Java is your language, Spring Framework is very likely your platform. Spring Security adds OAuth2 and OIDC support to applications that are written in Java with Spring.
If you are only just starting your application, Spring Boot is very quick way of putting up your software project. There is even an initialiser web site that helps you define your project specification files (Maven POM).
Spring project provides code samples that you can start with to integrate your application to external authentication.
.NET and C#
TO BE REFINED
.NET seems to be Free, Cross-Platform, Open Source developer platform that developer can benefit to build apps for Andoid, iOS, macOS and Windows from a single codebase. C Sharp, also known as C# is a general-purpose, multi-paradigm programming language to write applications in .NET environment and apparently also in others.
The simple guides an tutorials available show that the platform is vivid and strongly living.
As we don’t curently have good references to C# libraries or implementations, we just save you the bourden of internet searches and list some references:
That seems to be a short list. However, ASP.NET Core documents an ability to provide authentication based on commonly known authentication providers available in the Internet. If this is possible, it should be quite easy to implement OIDC Client with ASP.NET Core services as well.
TO BE REFINED
This section contains citations from background materials that the links point to. As might be evident, this section is initially written by a Java Boomer and we hope that an actual C# developer would refine this section to be more accurate and useful.
Now, by looking the .NET platform, it seems to be locked in and not very well standards based. By locked in, it is referred that the ASP.NET documentation doesn’t describe a way to openly connect to identity providers in general, but only to those recommended by the platform.
This section need to be refined by a developer that has better understanding of the platform.
TO BE REFINED