Accueil > OpenID Connect OAuth Server by DnC

OAuth Server by DnC (OAuthSD) is an authentication server that implements OAuth 2.0 and OpenID Connect.

With OAuthSD, passwords can not be intercepted when they are entered, do not circulate on the Internet, are not saved anywhere ! And the personal data of your prospects is stored in a protected area.

Architecture d’OAuth Server by DnC

Disclaimer : This website implements a demonstrator of OAuthSD ; the server may be unavailable and the saved data deleted at any time.
If you are interested in a production version of OAuthSD, on a private server on your property, contact DnC

What it is : official definition of OAuth 2.0 with comments and Discover
Instructions for use : Develop
Implementation : Manage

We often see in OpenID Connect a simple system of single connection (SSO), but it misses all the power of the process : the identity token JWT gathers, indissociable way and tamper-proof, the identity of the end user, the client application, and the authorization scopes ; see : Définition des scopes et généralités sur leur utilisation par les applications.

Since the beginning, OAuth and OpenID Connect have been designed to protect the sensitive data belonging to the end user, who is asked to access it. The vocabulary used and the examples given in the specifications are strongly oriented by this vision.

However, with a little hindsight, we see that we are in the presence of a set of techniques that can also do the opposite : ensure that the end user is the one he claims to be and allow access to protected resources or applications that contain sensitive data, owned or not.

Want to quickly get to the heart of the matter ? Read these articles : OpenID Connect : Lier une application cliente au serveur OAuthSD and Full Authorization Flow Examples.

To return to SSO (Single Sign ON), OAuthSD offers you the best : to ensure not only the unique registration, but also the single sign-on (Single Login Identification, SLI) on multiple applications, silent re-authentication (Silent Re-Authentication, SRA) and unique disconnect (Single Login Out, SLO). See : SLI, SLO et SRA sont dans un bateau : OAuthSD. While most implementations require developments on the side of client applications, OAUthSD offers you these features without any modification of them. All this end-to-end makes it possible to ensure the visualization and the management of the OpenID Connect session on the client side. Currently, we are committed to enhancing the security of identification with the Two-Factor Authentication (2FA).

OAuthSD builds on the library OAuth 2.0 Server PHP developed by Brent Shaffer. A notable work of DnC has been to encapsulate the entry points of this API inside a security layer. The development meets the specifications, see : OAuthSD towards the OpenID Connect certification.

A private authentication server is aimed at developers and website owners who want to protect themselves from the competition resulting from the behavioral targeting and profiling of their customers and, at the same time, to offer these customers the opportunity not to blindly disclose their personal data. This is a great way to comply with the RGPD.

DnC is an independent company whose policy is never to use or communicate the data collected. By entrusting us with the installation of your own authentication server, you can rest assured that your customers’ browsing will not be exploited for adverse advertising purposes. You can also avail yourself of a policy of protection of their personal data.

Derniers articles :

OpenID Connect : Grant Type flows


The Grant Type flows specifically defined for the OpenID Connect protocol are :
Authorization Code Grant,
Implicit Grant,
Hybrid Flow.
See also : OpenID Connect : Summary of all authorization flows.
Authorization Code Flow (spec. : Authorisation code flow) - the most commonly used stream for traditional web applications as well as native / mobile applications. Involves an initial redirection of the browser to the authentication server for authentication and user consent, and then a (...)


Verifying the origin of the request received by a resource server


The transmission of tokens to protected resources implies that the latters are receptive to tokens of any origin. This presents an opportunity for an attacker (a foreign application) to exploit a compromised or stolen token.
Once more, the analysis reveals that we are only able to ensure data security in the case of the "Authorization Code" flow.
Consideration about the security of token transmission to resource servers (RS)
The proposed RFC 6749 standard is quite clear on the need to (...)


Add additional claims to the JWT token


The OAuth 2.0 specifications allow the addition of new claims to the payload of the JWT token. This article shows how this is done within the framework of OAuthSD.
Use case
It should be ensured that the end-user is well able to access protected resources, whether personal data or the application owns the data. We also want to be able to control the data transmitted by a protected resource to an application based on the rights of the end user in this application.
Administrators as well as (...)


| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |

Plan du site :