Is OAuthSD compatible with OPenID Connect?
OAuthSD aims to comply with the IETF specifications as published by the OPenID Foundation.
OAuthSD is 100% compliant for the Authentication Code flow, see: OAuthSD towards the OPenID Connect certification.
Note that :
OAuthSD does not implement some flows, see: OpenID Connect : Summary of all authorization flows.
OAuthSD evolves quickly and new compliance tests will be done,
OAuthSD imposes some restrictions that go in the direction of security; thus, the state parameter is mandatory in requests to Authorize, while the specification does not require it.
OAuthSD offers extensive features that, however, do not contradict the specifications. The SLI mechanism is a good example: the OIDC specifications define everything needed for silent re-authentication (especially with the prompt = ’none’ parameter), but this would still have to be done by going back and forth between the server and the client application. OAuthSD processes this at the Authorise controller level using the SLI cookie, avoiding the developers a tedious adaptation work of the applications.
OAuthSD adds some additions to the specification, without impacting compliance. Thus, the Authorize controller can be queried in Ajax and return the remaining session time. See: Monitoring de l’état de l’authentification et SLO, Avertir de la fin de session OIDC et la prolonger.
What does OAuthSD bring to security?
The OIDC specifications do not take into account certain threats. For example the "Broken End-User Authentication" attack is not taken into account by the specifications, the proof is the fact that the parameter state is not obligatory.
The focus is on the eviction of a client application or a questionable user-agent. For example, there are now 12 tests in the Authorize controller to eliminate dubious requests.
In the field of security, OAuthSD is not only an authentication server but a supervisor.
For example, in the "Monitor" pages, the history of incidents is dated to better than the microsecond to facilitate cross-referencing. This requires that other histories are also microsecond timed [1].
OAuthSD also includes an administrator alert by E-mail or SMS, as well as an interface for tracking and alerting with PRTG.
The events history is in a syslog-compatible format for processing by intrusion detection, tracking, and alerting applications.
I can read criticisms about some flows, why implement them?
It must be considered that the OIDC server is as secure as the least secure flow that it implements.
An amazing feature of OAuth 2.0 is to offer very insecure flows compared to the Authorization Code flow. Yet this one is really only complete in its OpenID Connect (not OAuth 2.0) version which implements the identity token.
Opening the possibility that the server responds to various requests (such as implicit and hybrid flows) without controlling the client application can be considered a security breach [2]!
We want to provide a 100% OpenID Connect compatible server. At the same time, developers and administrators need to be aware that exposing the server to implicit and hybrid flows is a security breach. For this reason, configuration constant is used to choose using implicit flows or not. One could thus answer only requests of types Authorization Code and Client Credentials.
Can we do it all with the Authorization Code flow?
We think so, see for example: Applications natives : un exemple avec Windev.
The Client Credentials feed is also useful for an application’s access to protected resources. But it is possible to use the Authorization Code flow for this, see: OpenID Connect : Exemples complets du flux d’Autorisation via un code puis requête UserInfo.
This remains an open point for discussion.
What does "There is more information, log in to see them"?
When this message appears at the bottom of an article, it means that there is information reserved for privileged users of this site. If you have write permission on the topic, you will be allowed to see this text after logging in.
RSS 2.0