OpenID Connect OAuth Server dédié

OIDC session management: Features

DnC — 2024-04-28T11:51:24Z

SSO, SLI, SLO, SRA: These features offered by OAuthSD simplify session and connection management for users, ensuring a smooth and secure experience when using multiple applications compatible with OpenID Connect.

Before detailing how OAuthSD implements these features, let's make sure to distinguish them:

SSO (Single Sign-On): This is a mechanism that allows a user to log in once to access multiple applications, without having to log in again each time. With OAuthSD, SSO is set up to offer single authentication for a group of applications, thus preventing the same Internet user from having to authenticate several times to access different applications.

SLI (Single Login In): SLI is a similar concept to SSO, but it focuses on the fact that once logged in, a user can access multiple applications without having to log in again. OAuthSD uses SLI to facilitate navigation and data exchange within a multiple application.

SLO (Single Log-Out) : SLO is the counterpart of SSO, but for disconnection. It allows a user to log out just once to log out of all applications they are logged in to. This guarantees a global disconnection and reinforces security in the event of the user leaving their workstation.

SRA (Single Re-Authentication): SRA is a mechanism that allows a user to seamlessly re-authenticate when an authentication cookie is no longer valid. This ensures enhanced security in the event of a need for re-authentication.

This article was written using i-Tego ChatBot, in response to the question: "Dans le contexte d'OAuthSD, expliquer SSO, SLI, SLO, SRA."

Q: is authorization flow as good for native/mobile ?

DnC — 2024-03-14T09:21:34Z

i-Tego masters generative AI using your company's data. We can therefore provide you with advanced search tools on a very large number of documents of all types, explore your databases, your emails, etc. All with automatic translation!


i-Tego chat bot: i-Tego offers businesses a chatbot whose document database includes their own data: https://chat.i-tego.com/

This is an example built on i-Tego's documents :

Q: what are key points to consider when using authorization code flow with native/mobile application ?

R: When using the authorization code flow with native/mobile applications, there are several key points to consider:

Security: Native/mobile applications cannot securely store the client secret, which could be exposed through reverse-engineering. Therefore, additional security measures such as Proof Key for Code Exchange (PKCE) should be implemented to mitigate this risk.

Client Type: Native/mobile applications should be registered as "public" clients on the server, meaning they have a null secret.

Code Challenge: Instead of the client secret, the application should generate a random code verifier and send its hash as the code challenge parameter during the authorization request.

Token Exchange: After the user authentication and receiving the authorization code, the application exchanges it for tokens, including the code verifier parameter.

Code Challenge Creation: The code challenge is created by hashing the code verifier with SHA256 and encoding it in base64 URL format. The code challenge method should be set to 'S256'.

Additional Security Measures: Implementing methods like PKCE enhances the security of the token issuance process and helps prevent interception or misuse of authorization codes by malicious applications residing on the same user-agent.

These considerations help ensure the security and integrity of the authorization process for native/mobile applications using the authorization code flow.

Q: what says OAuthSD about this : is authorization flow as god for native/mobile application as for web application?

R: OAuthSD emphasizes the importance of using the Authorization Code flow for web applications due to its ability to provide a secure way to handle authorization. This flow is particularly well-suited for web applications that require a constant connection to the server and deal with sensitive data. However, OAuthSD also mentions that certain systems may find the simplicity of OAuth 2.0 flows, such as the Client Credentials Grant, more suitable for their needs, especially in trusted environments where user identification is not a priority.

In summary, while the Authorization Code flow is highly recommended for web applications, OAuthSD acknowledges that different application types may have varying requirements and security considerations when it comes to authorization flows.

Sources:

Découvrir - OpenID Connect OAuth Server dédié.pdf (page 22)
Authentifier l'application - OpenID Connect OAuth Server dédié.pdf (page 1)

Q: what says OAuthSD about security of authaurization code flow for native/mobile applications?

R: OAuthSD emphasizes the importance of security when using the Authorization Code Flow for native/mobile applications. The Authorization Code Flow is considered safe when applied to web applications with a back-end, as it provides a secure way to authenticate and authorize access to protected resources. However, for native/mobile applications, additional considerations are needed to ensure the security of the authentication process.

OAuthSD highlights the need to verify the origin of requests received by a resource server to prevent token theft by foreign applications. This strict security approach leads to the conclusion that the Authorization Code Flow is only considered safe for web applications with a back-end. This means that for native/mobile applications, there may be limitations or vulnerabilities that need to be addressed to ensure the security of the authentication process.

In summary, while the Authorization Code Flow is a secure option for web applications with a back-end, additional security measures may be necessary when implementing this flow for native/mobile applications to prevent unauthorized access and protect sensitive data.

Verification Key for Code Exchange (PKCE)

DnC — 2024-01-13T08:41:50Z

OAuthSD can implement the Authorization code + PKCE flow. The main difference between the Authorization code + PKCE flow and the standard flow is that the client does not provide the application secret, but a verification key.

On the other hand, since there is no longer a secret, there is no longer any identification of the application implemented by the client, which is therefore of the "public" type.
The method avoids propagating a secret, but does not provide any new information on the identity of the application since it is a public instance that is thus identified. Conformity of the application to the original model is not guaranteed.

PKCE (pronounced "pixy") is an acronym for "Proof Key for Code Exchange".
See RFC 7636: Proof of Key for Code Exchange (PKCE)

Usefulness of PKCE for mobile/native apps

When authenticating, mobile/native apps (without a backend) can use the authorization code flow, but they require additional security because they cannot Securely store the client secret that could be revealed by reverse-engineering (the client secret is tied to the application and is the same for all users and devices).
Apps without a backend can use a custom URL scheme to capture redirects (for example, MyApp://). This can be hijacked by a malicious application, residing on the same user-agent, to receive an authorization code.

To address this issue, OAuth 2.0 and OpenID Connect provide a complement to the authorization code flow using a Verification Key for Code Exchange (PKCE).

Authorization code flow + PKCE

A client application implementing the authorization code flow with PKCE must be of the "public" type, i.e. be registered on the server with a null secret.

The public client application creates a random (unique and containing no information) string value, the code_verifier. When the client application initiates the authorization code request, instead of the secret, it sends to the Authorize controller the code_verifier hash under the code_challenge parameter.

After the user is authenticated and the authorization code is returned to the client application, the client application requests the tokens in exchange for the authorization code, including the code_verifier parameter.
If the codes match, authentication is complete and an access_token is returned.

Creation of the code_challenge

In the authorization code request, the application must transmit the code_challenge and the coding method "code_challenge_method" [1].

Starting from a random string 'code_verifier', we obtain the code_challenge by applying a SHA256 hash and base64 URL encoding. You must then pass code_challenge_method = 'S256'

PHP

// Prepare PKCE code_challenge
$code_verifier = substr( str_shuffle("abcdefghijklmnopqrstuvwxyz0123456789ABCDEFabcdefghijklmnopqrstuvwxyz0123456789ABCDEFabcdefghijklmnopqrstuvwxyz0123456789ABCDEF"), 0, 50);
$code_challenge = strtr(rtrim(base64_encode(hash('sha256', $code_verifier, true)), '='), '+/', '-_');
$_SESSION['code_verifier'] = encrypt($code_verifier);
...

Download

Javascript

function base64URLEncode(str) {
return str.toString('base64')
.replace(/\+/g, '-')
.replace(/\//g, '_')
.replace(/=/g, '');
}
var code_verifier = crypto.randomBytes(50);
var code_challenge = base64URLEncode(code_verifier);
...

Download

ENFORCE_PKCE configuration constant

If the ENFORCE_PKCE configuration constant is set to true, all clients must enforce PKCE.
If false, PKCE is applied only to clients querying Authorize with the code_challenge parameter.
This constant is set to False by default.

Error 'missing_code_challenge'

If the ENFORCE_PKCE configuration constant is set to true or if the client queries Authorize with the code_challenge parameter, and the client does not provide the challenge code and encoding method in the authorization code request, the Authorize controller responds with a code 400 and the message 'missing_code_challenge', 'This application requires you provide a PKCE code challenge'.

Call to Token controller

When the client application calls the Token controller to obtain the tokens, it passes the code_verifier parameter and the client ID in the body of the POST request (instead of passing the client ID and the secret in the header by the authentication method HTTP Basic).

Example in PHP:

$code_verifier = decrypt(@$_SESSION['code_verifier']);
$data = array(
'client_id' => $client_id,
'grant_type' => 'authorization_code',
'code' => $code,
'code_verifier' => $code_verifier,
);
$h = curl_init($token_endpoint);
curl_setopt($h, CURLOPT_RETURNTRANSFER, true);
curl_setopt($h, CURLOPT_TIMEOUT, 10);
//curl_setopt($h, CURLOPT_USERPWD, "{$client_id}:{$client_secret}");
curl_setopt($h, CURLOPT_POST, true);
curl_setopt($h, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($h, CURLOPT_HTTPHEADER, array('Content-Type: application/x-www-form-urlencoded'));
curl_setopt($h, CURLOPT_POSTFIELDS, http_build_query($data));
$res = curl_exec($h);
...

Download

Error 'code_verifier_missing'

If the client queried Authorize with a code_challenge (regardless of the value of the ENFORCE_PKCE configuration constant), and the client does not provide the 'code_verifier' parameter in the token request, the Token controller responds with a 400 code and the message 'code_verifier_missing', 'The PKCE code verifier parameter is required'.

PKCE Security Discussion

First of all, let's remember that PKCE does not replace the secret of the application, and therefore does not provide any answer to the problem of identifying the client application.
The PKCE-enhanced authorization code flow introduces a random code "code_verifier", obscure (containing no information), created by the calling application and can be verified by the authorization server. Additionally, the calling application creates a transformed code checker value called "code_challenge" and sends this value over HTTPS to retrieve an authorization code. In this way, a malicious attacker can only intercept the authorization code and cannot exchange it for a token without the code checker.

However, after creating the verifier code in the first step of the authorization code flow, the client application must store it somewhere to provide it in the second step, when requesting the token. Even if this only lasts a very short time (of the order of a second), the code verifier is exposed to malware which clearly has everything it needs to try to obtain a token in place of the legitimate application. In principle, the legitimate application should have requested the token immediately, probably before the malware which will stumble on the ban on using the same verifier code twice. Unless the hacker is capable of changing execution priorities? Even if it seems difficult or improbable, there is perhaps an opportunity for exploit.

[1] code_challenge_method can take the values "plain" or "S256".

OIDC and Single Page Applications: Example of a Beautiful Masquerade!

DnC — 2022-09-17T09:45:04Z

A Single Page Application (SPA) is a web application that loads a single HTML page from the web server and then dynamically updates it in response to user interaction and other events.

Arguing from advances in browsers allowing JavaScript to implement CORS rules and access encryption, some advocate implementing "Authorization Code" flow rather than "Implicit flow".

The magic of the "Authorization Code" flow is then invoked to claim that data access is secure. It's just a masquerade! Bling bling bling...

A single-page application is a "no back-end" application

There are several architectures for creating single-page applications. The trend is the "light server" architecture, which installs on the user agent (usually the user's browser) the initial page containing Javascript code. This code will provide logic and state transitions for the application as it gets its RESTful API data protected by OAuth 2.0. In this configuration, the application resides on the user agent and not on the server: a single-page application is therefore a "no back-end" application.

SPAs can (now?) implement Authorization Code Grant

There are many configurations in which the application hosts and the service endpoints are located on different servers: authentication server, protected resources (RS) or APIs.

Single-page apps are a good example.

In normal web usage, this multi-host or, more accurately, "multi-origin" approach is restricted for good security reasons. Declarations of cross-origin resource sharing ( Cross-Origin Resource Sharing, CORS ) make it possible to circumvent the constraint.

Browsers have improved since the design of the implicit flow. The CORS implementation to allow token request from JavaScript is now available, along with the necessary cryptography APIs to validate the JWT token signature.
It is therefore technically possible to use the authorization code flow for the authentication and authorization of applications without a back-end, including for single-page applications.

Does this mean that the use of this flow, in this configuration, guarantees data security?

With SPAs, authentication security issues remain

SPAs are "no-back-end" applications. Their code is on the user agent, so anywhere, unlike applications "with back-end" whose unique code is protected within a server. As such:

Are exposed in the code, in a more or less accessible way to the public:
- the identifier and the secret of the application,
- access or identity tokens.

With the identifier and the secret, a malicious application can obtain tokens. With the tokens, it could request data on behalf of the real application.

The redirection URL is that of the application, therefore that of its host, ie the user-agent. It cannot be registered on the server and must be provided by the application.
If we are in the case of workstation user-agents ( desktops ) located in a trusted space (one or more known domains), it is still possible to compare this URL to a model saved on the server authorization. But even in this case, if the malicious application is on the same host [1], the distinction is impossible. If we are dealing with a mobile application, it becomes really risky.

In the case of a mobile application, the token request at the Token entry point and the response do not circulate in a connection from server ( that of the application ) to server ( the authentication server ) in which both ends are identified, but between different unidentified mobiles and the authentication server. Thus disappears one of the recognized qualities of the authorization code flow applied to customers with back-end.

There are many additional methods allowing the tokens to be linked to the user-agent or to the TLS connection identifier (TLS Token Binding). This makes it possible to prove that the user-agent (eg the end-user's browser) is the one with which the authentication was performed and the token created. But this does not make it possible to discriminate between the good application and malware running on the same TLS link. In the same vein, the proof of possession technique Proof of Possession (PoP) seems to lead to the same conclusion.

In particular, the "Proof Key for Code Exchange, PKCE" method, applied to applications without a back-end as part of the Authorization Code flow, strengthens security by preventing authorization code hijacking. With this technique, the secret of the application is not used, which makes it possible not to disclose it. However, this prohibits identifying the application. PKCE makes it possible to ensure that the application which presents the authorization code is indeed the one in which the end user identification procedure was carried out, whatever this application may be.

In the case of a SPA as in that of any application without a back-end [2], it is not possible to ensure that the application presenting the token is indeed the expected application, and not malware.

Encapsulate encrypted data in a Javascript class ???

With SPAs, it is not possible to store credentials using traditional methods, such as access tokens in cookies and session storage. Instead, we imagine keeping sensitive data in JavaScript variables.

Some then recommend using a JavaScript class to store and provide these variables. This method receives the pretty name of "encapsulation" which gives a serious and innovative aspect to a method that is however very banal.

However, this is only an obfuscation method whose effectiveness is insufficient against a determined attacker. A simple web debugger (all modern browsers include one) allows you to execute the code step by step and see the variables pass.

Why do the specs confirm questionable practice?

We can read in the document Health Relationship Trust Profile for OAuth 2.0 [3]

2.1.3. In-browser client with user delegation

This client type applies to clients that act on behalf of a particular resource owner and require delegation of that user's rights to access the protected resource. Additionally, these clients are integrated with a web browser and effectively share an active session between systems.

These clients use the implicit flow of OAuth 2 by sending a resource owner to the Authorize endpoint for authorization. The user MUST authenticate to the Authorize endpoint. The user's web browser is then redirected to a URI hosted by the client, from which the client can directly obtain an access token. Since the client itself never authenticates to the server and the token is made directly available to the browser, this flow is only suitable for clients embedded in a web browser, such as a JavaScript client without a backend server component. Whenever possible, preferred to use authorization code flow due to its superior security properties.

This type of client MUST NOT request or receive a refresh token. Access tokens issued to this type of client MUST be short-lived and SHOULD be discarded when the user's authenticated session with the client expires.

It is therefore well recognized that there is a problem that the authorization code flow will not solve. This flow is arguably "higher security", but in the case of applications without a back-end it fails to authenticate the application, which may be overridden by malware located on the user agent.

Still, the wording of the paragraph suggests that the authorization code flow will do better than the implicit flow. And we avoid the exposure of the application's secret in a simple way, and for good reason: "the client itself never authenticates with the server".

In this context, talking about the security offered by the "Authorization Code" flow is a masquerade: n.f. hypocritical comedy, deceptive staging.

An article presenting the cons and concluding on the pros

Here is an interesting article for the analysis that is made: SECURELY USING THE OIDC AUTHORIZATION CODE FLOW AND A PUBLIC CLIENT WITH SINGLE PAGE APPLICATIONS.

The author advocates the use of authorization flow with code for public SPAs, but provides a detailed analysis that highlights the multiple shortcomings of the configuration. Contrary to the title "Securely..." and the conclusion of the article, here is another ambiguity.

By titling on public apps, the author avoids at least disclosing the app's secrecy, since there is none. This will facilitate the work of malicious applications! we're not going to ask for protected data like that.

Incompetence or marketing lie?

Our article was motivated by reading this one: https://www.ubisecure.com/single-si....

The red thread of this article is simple:

1. Advances in browsers (CORS and cryptography) allow JavaScript to implement the authorization code flow.

2. So we no longer need to implement the implicit flow with the SPAs, but the Authorization Code flow.
Understood: since you know that the Authorization Code flow is the one to use with OIDC, and that you were told that the implicit flow was of questionable security, you understand that everything is fine now.

3. Of course, we have to store the tokens. You have to encapsulate them in a class, so they will be well hidden.

So, incompetence or intox? Wouldn't it be a question of making people believe in a new system and thus crediting the existence of a comparative advantage over the competition?

Why distort the truth?

OpenID Connect has a good image, it sells well. Too bad if the data is only secure in the case of classic web applications (with back-end). Want to keep up with the mobile app trend? Then marketers will sell you OIDC without telling you about the limitations.
Better still: they will highlight complementary methods, such as PKCE or POP, suggesting that they provide the solution to the problem of authentication of a client application without a back-end.

What about headless servers ?

The "headless server" configuration is an architecture that allows writers to produce and organize content, while providing developers with structured data that can be displayed using a separate system on the frontend of a site. web or app.

We often end up, on the front-end, in an SPA.
But, since the data is served by an application with back-end, there is a way to ask the end user for OIDC authentication on this application, registered as a client of the OIDC server. If this gives a guarantee on the authorization of the user to access the data, it will not make it possible to identify the SPA and what it does with the data.

So there is no hope of securing SPAs?

There is an interesting track with applications installed on mobile in Progressive Web App (PWA) mode. Under certain conditions, the code and data of PWAs are maintained, on the mobile side, identical to their model on the server side. Such a SPA - Headless Server architecture (see SPIP CMS headless + Gatsby) could therefore be suitably secured with OIDC.

i-Tego accompanies you

i-Tego (heiress of DnC) provides advice and assistance. We help our customers to implement their own OAuthSD server. We support Dev/Ops by transferring our skills to them, which results in using OIDC only in secure configurations.
And we fully recognize the work of IT to protect access to the network, and thus create the "trusted space" required for the correct application of OpenID Connect.

[1] which is not only the common case but also the case ( worst case ) that one must take into account for an analysis of security

[2] Just as in the case of a native mobile application and any application without a back-end. This is the same problem, except perhaps for desktop applications in a trusted space

[3] Who can translate " Health Relationship Trust Profile"? Google Translator gives "Health Relationship Trust Profile". Could this incomprehensible title be intended to give a pseudo-scientific aspect to an otherwise very obscure text?

SaaS and OIDC: a successful marriage thanks to OAuthSD!

DnC — 2021-07-29T07:31:00Z

One of the features that DnC has developed to the highest level with its OAuthSD server is to transmit secure information using the JWT identity signed token (JWS).

We describe in this article the application i-Tego SaaS, a software as a service (SaaS) delivery system. In this application, OAuthSD provides OIDC authentication and securely transmits to SaaS applications the parameters relating to end-user' subscriptions.

Position of the problem

Most SaaS systems integrate the application and the sales system in one software.

If several web applications are to be distributed in SaaS mode by the same entity, the first problem to be solved consists in providing single sign-on service (SSO) between the sales system and the different applications. No problem, that's the role of an OIDC server, OAuthSD does this very well.

The second problem, more interesting, consists in transmitting information from the sales system to applications.
Regarding the validity of the subscription and the (paying) options, this data must be secured, ie allow the recipient application to control:
integrity (the data have not been falsified),
the authenticity of their origin (they were indeed delivered by the SaaS system),
the actuality (these are indeed data valid at the time considered),
the destination (these are data relating to this application),
and of course the identity of the end user (it is not an intruder who uses the application).

The solution: OAuthSD

OAuthSD allows integrating SaaS data as additional declarations in JWT token payload. The recipient application (client of the OIDC server) will only need to validate the identity token by introspection (and not locally to ensure the token validity at this time) to carry out the checks described above in a single operation.

The system DnC SaaS and one of its applications NSS Lite perfectly illustrate this technical.

To achieve this we have:
integrated in the same application the OIDC server and the sales system,
developed OIDC-SaaS extension plugins, in particular for applications based on SPIP or Wordpress.

We would be happy to assist SMEs to allow them to develop their own SaaS system and adapt their web applications.
Our positioning of advice and assistance would allow our customers to developp their applications independently of expensive external providers. And third-party systems that are risky in terms of security: why feed big data to the benefit of your competitors?

Definition of OIDC scopes and generalities on their use by applications

DnC — 2020-10-05T11:50:00Z

The extent of the authorization is defined by the Scopes. This is probably the most open point of the standard and therefore a difficult concept to master for the developer of an application using OpenID Connect.

The ability to modulate authorization extent based on the client application and the end user is an exceptionally interesting feature of OAuthSD.

We often see in OIDC a simple SSO, but it misses all the power of the device: the JWT identity token combines inseparably and in a tamper-proof way the identity of the end user, that of the client application and the authorization extent.

DnC gives an example of application of the transmission of authorization scopes with i-Tego SaaS.

OpenID Connect defines scopes in multiple places in the OAuth 2.0 documentation, yet does not give it the synthesis it deserves. The library OAuth2 Server Library for PHP developed by Brent Shaffer implements the scopes without the author presenting the philosophy. However, analyzing the code of this library makes it possible to complete the specification, to identify the main definitions and to propose a concept of use.

Four levels of scopes definition:

1. Scopes supported by the server (Supported scopes)

In addition to the reserved and non-reserved scopes defined by OpenID Connect, the developer defines the particular scopes used by the applications. They are registered in the server configuration file (variable $supportedScopes).

The scope 'basic' is also included in the configuration as the default scope.

Only these scopes can be used, the Authorize controller rejecting any request including a scope missing from this list.

2. Reserved Scopes

Reserved Scopes play a special role [1]. They are mainly used by the server to modify the flow behavior.

openid: This scope is required for the application to work with OpenID Connect. If it is the only scope requested, the identification of the end user will be reduced to the claim sub.

offline_access: OpenID Connect access requests include the refresh token only if the offline_access scope has been requested and granted.

sli: this scope is required for the application to accept one-time identification (Single Login Identification, SLI) and silent re-authentication (Silent Re-Authentication, SRA) as we we implemented them in OAuthSD.

kerberos: This scope authorizes the creation of an OAuthSD SLI session from authentication with Kerberos.

Notes:
The first two scopes are defined by the OAuth 2.0 standard, while the last two are introduced by OAuthSD.
The reserved scopes do not give rise to consent from the end user, with the exception of scope offline_access.

3. Scopes available for an application (Available scopes)

These scopes are defined at the time of application registration on the server. They include :
all or part of the reserved scopes,
Non Reserved Scopes, which are defined by OpenID Connect or defined by the designer's initiative. [2] We propose to call them private scopes.

Subsequently, an application will NOT be able to use other scopes than those which have been registered thus. In particular, the Authorize controller verifies from the beginning of the process that the scopes requested in the request appear in the list of Scopes available for the application (Available scopes).

4. Granted scopes

An application transmits the scopes in the authorization request (call to Authorize endpoint). They must be in the list of Scopes available for an application.

Some of these scopes are Requested Scopes. A good understanding of the subject requires distinguishing two positions of the end user from the owner of the data, as defined by the OAuth 2.0 standard (see Portée de l'autorisation (Scope)). In summary, it is necessary to consider the scopes in two cases [3]:
either the protected data is the property of the user, and the scopes must be understood as an access request of the application to this data: the application will have to obtain the consent of the user for to pursue,
or the application (in the broad sense) "owns" the protected data, and the scopes must be understood as an authorization granted by the application.

In the second case (if the data belongs to the application) an application can modulate the privileges granted to the user according to the profile of the latter which is translated by the scopes.

If the application does not provide for modulating granted privileges, the designer can use the allowed scopes or the default scope.

Once the authentication has been performed (and, if necessary, the scopes have been accepted by the end user), the scopes become granted scopes.

Embed additional declarations into the identity token

Note that the authentication server is transparent with respect to non-reserved scopes and "non-standard" declarations (claims): it is up to the protected resource to define what must be done with it within the framework of a given application.

OAuthSD offers three complementary approaches for incorporating additional declarations into the identification token:

1. OAuthSD: scope "privileges"

This scope is unique to OAuthSD as part of the OpenID Connect flows.

The scope "privileges" includes the claims "scope" and "profil" [4] which correspond to the eponymous fields of the table users.

It is up to a third party application to determine the values to be assigned to the "scope" claim. For this, OAuthSD offers two interface techniques:
Add additional claims to the JWT token,
Use an HTTP Rest service .

If an application presents the "privileges" scope to the Authorize controller, the "profile" and "scope" declarations will be embedded in the UserInfos data. In this respect, it is a granted scope (Granted Scope) in the same way as the "basic", "email" and so on. that control access to the data in the users table.

In addition to this standard behavior, these statements will be embedded in the payload of the identity token.
Thus the identity of the application, the end user and its authorization staves is perfectly established by the signature of the JWT token.

2. Using the scope "privileges" claim "scope" for granting privileges in applications

OAuthSD groups the end user information in the users table. The field 'scope' is of the type text and can therefore accommodate any kind of data to describe the profile of the user or give the list of his privileges. For example, you can create a 'profiler' data object and store it in Json format.

3. For developers: a technique to programmatically embed additional declarations in the JWT token

In addition to the previous techniques, OAuthSD allows to incorporate additional declarations into the JWT token. Although we present this method last, it is arguably the one that will be of most interest to developers. DnC applies this technique to realize DnC SaaS.

i-Tego SaaS: a system to deliver applications as a service

i-Tego SaaS couples an online sales system to an OIDC server (OAuthSD of course) in order to lease services online .

The leased software is configured as a client application of the OIDC server.

At the time of end-user authentication, the Authorize controller identification module calls the online sales system to verify that the user is up to date with their payments.

This step also allows define end user privileges on the application, for example:
validation of any application options taken with the subscription,
limited rights (consultation only ...) during a grace period after expiry,
etc.
The privileges are incorporated into the payload of the ID Token in the form of additional declarations. The names of the declarations and the values transmitted are specific to the application in question.

[1] So special that they have nothing to do with a scope of authorization, but appear rather as a way to tune the flow. Is there perhaps a semantic flaw in OpenID Connect? Note that IBM refers to this as "client metadata", which seems relevant.

[2] How much should we extend the definition of scopes? We discuss the issue here: /web/-OpenID-Connect-UserInfo-.html. Facebook defines a hundred scopes! But, from the perspective of controlling access to web-services and APIs, the use of scopes can go much further than the mere modulation of Userinfo. Google makes extensive use of scopes to allow access to different APIs. GitHub uses scopes to modulate user access to different features. These are proprietary applications and therefore a very particular implementation of OpenID Connect that shows two things: OpenID connect is much more than an SSO; In contrast to the idea of a universal authentication system (allowing access to any application with a single identifier), control of access to applications and data can only be done in a corporate realm.

[3] As expected by the standard: see Portée de l'autorisation (Scope).

[4] Note that the claim "profil" and the scope "profile" must be distinguished. The definition of the scopes is well entangled!

Two-Factor Authentication (2FA)

DnC — 2020-06-19T09:00:00Z

New EU regulation will require a two-factors authentication for payment, the 'Strong Customer Authentication' (SCA) which has come into force in September 2019.

The need for 2-steps validation is also felt for connecting users to sensitive applications. The principle of two-steps validation (Two Factors Authentication, 2FA) is well known for several years and implemented in different ways, the most common being the code sent by SMS.

OAuthSD Implements two-factors Authentication by SMS or with Google Authenticator.

What is 2FA ?

Two Factor Authentication, also known as 2FA, two step verification or TFA (as an acronym), is an extra layer of security that is known as “multi factor authentication” that requires not only a password and username but also something that the user owns, that is with them and that no one else owns or knows about.

After login, give a second proof

The process begins as usual, the end-user giving his login and password :

She/he is asked to provide a second proof of identity : OAuthSD offers the classic method : SMS or Google Authenticator. We add our own highly securised identification system : DnC's IdentMaster.

2FA by SMS

If this first step ends successfully, OAuthSD continues on a request for code by SMS:

The SMS is sent to the smartphone number registered with the user's profile [1].

After confirmation, consent is requested if necessary, as usual:

2FA with Google Authenticator

Google Authenticator is a 2FA system that generates a TOTP.

What is TOTP ?

TOTP is a short form for Time-based One-time Password (usually called Token) which is password that can only be used once and is only valid to be used in a defined time range. Usually TOTP generators generate new passwords every defined tens of seconds.

This necessitates to register OAuthSD as a Google Authenticator application [2]. This is what the QRCode is used for. See many how-to on the Web. This is a one-time action for the smartphone life time: once it is done, GA will display a code every 30s : nothing to remember!

After confirmation, Consent is asked if necessary, as usual.

Why Google Authenticator ?

Google Authenticator has been provided by Google for several years and proved a user-friendly process. Many people have Google Authenticator (for free) on their smartphone, and would probably have difficulties adopting an other application.

What about tracking? Applications delegate user identification to OAuthSD, this means Google see the OAuthSD server, not the applications. Google knows that a user is related to OAuthSD, but doesn't see the relation with the application ... provided there is no tracking leakage elsewhere in this application!

TFA with DnC's IdentMaster

We have developped DnC's IdentMaster, a passwordless mobile application that can be used as first as well as second authentication method.

With the DnC's IdentMaster application installed on your mobile, you just need to scan the QR-Code presented by the application to open your OpenID Connect session:

Configure 2FA on OAuthSD

A request for a second validation is presented to the end user:
if the reserved scope "tfa" is present in the authorization request and if the application has been registered on the server with the scope 'tfa'.
If the LOGIN_WITH_TFA configuration constant is set to true, the 2FA form will always be presented to the end user after the login form.
the TFA_PROVIDER configuration constant is used to define the second mode of identification ("gangsta", "checkbysms ", " smartconnect "...).

And then ?

In the current state of development, OAuthSD offers three methods for 2FA: TFA by SMS (the classic solution!), Google Authenticator and SmatConnect.

Other ID providers will follow soon, including our own (= your private) for a top level security.

We may develop any private system suited for the particular needs of our customers, as we did with the OpenID Connect Identification with ID Card : Aramis .

[1] The SMS identification method will fail if no number has been registered for the user trying to login.

[2] Note that OAuthSD is registered on Google Authenticator, not client applications. The advantage of delegation of authentication is therefore retained to prohibit the tracking of end-user navigation.

How does OIDC contribute to the ZTNA approach?

DnC — 2020-03-27T09:03:48Z

ZTNA: "Zero-trust" access to the network. This concept formalized in 2010 by the research firm Forrester aims to give users the minimum necessary privileges (unlike access to the network by Virtual Private Network, VPN).
OpenID Connect provides certain responses in this area, in particular for in-depth protection, beyond controlling access to the network.

In the context of COVID-19, telework leads many employees to access their company network by means of a VPN tunnel from the personal computer or - absolute horror - the family computer. Checks should be made at this level.

Principles of ZTNA

It is about protecting the information system (IS) and sensitive data based on the principle that nothing and no one should be trusted. From user equipment to application, there are three general principles to apply:

1. Control of the materials used to access the IS: The sole control of the end user is not sufficient, it is also necessary to control the user agent by means of which she/he accesses the network and the applications, and his/her hardware also.

2. Multi-factor authentication: Authentication (at least two factors, or Two Factors Authentication, TFA) requires multiple proofs of identity from the end user.

3. Minimum privilege: Give users only access to the resources or data they need to perform their tasks.

How is OpenID Connect compared to this principles?

1. OpenID Connect intervenes at the application level. OIDC cannot therefore replace the means of identifying and controlling the material layers. However, the Authorization Code Grant, when applied to "back-end" applications and services, provides a way to identify these components at the hardware level. On this subject, see: Verifying the origin of the request received by a resource server.

2. Multi-factor identification is not part of the OpenID Connect standard. The identification layer of the Authorize controller must implement several identification means, OAuthSD provides multi-factor identification.

3. By allowing identity tokens and privilege information to be conveyed by the identity token (ID Token) and guaranteeing its integrity by means of the token signature, OpenID Connect opens a means of controlling access to applications and data. OAuthSD allows the transmission of privileges.
However, it all depends on what the protected applications and resources will do with this information.

Disclaimer: It is important to note that OpenID Connect, like any other authentication system, does not ensure the security of applications or data services, but provides them with more complete and reliable information about the end user than simpler methods. On the one hand, security will depend on what applications and services do with this information, on the other hand, their intrinsic security as well as that of the network.

In conclusion :

Applications of the ZTNA principles most often aim to replace access by VPN, and are therefore interested in the transport layer. Identification and control of hardware integrity is still the poor relation of security solutions, OIDC adds nothing.

OpenID Connect extends security at the application level (in the upper layer of the OSI model) and therefore finds its place in a complete ZTNA approach.

However, the difficulty of OIDC lies in the need to adapt applications and protected data resources by incorporating an OIDC module into them. See: Adaptation des applications.

Prospects for the evolution of OAuthSD

Note that the OAuthSD server already integrates some security functionalities at the level of the hardware and transport layers, and will bring more and more as it is developed, the OIDC server becoming part of OAuthSD.

In this perspective, the development effort will focus on:
physical identification of the user's machine at the packet (IP address) and frame (MAC address) level,
integrity check of the remote host.

One solution would be to develop a specific user agent which, seen from OIDC as an application, would collect physical information and communicate it to the OAuthSD server. This application should perform integrity checks, for example by uploading data collected from security software residing on the host.

Verifying the origin of the request received by a resource server

DnC — 2019-10-31T15:15:00Z

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 use access tokens only between authorized parties (§ 10.3.):

Access token credentials (as well as any confidential access token attributes) MUST be kept confidential in transit and storage, and only shared among the authorization server, the resource servers the access token is valid for, and the client to whom the access token is issued.

If all the resource servers (RS) to which the tokens are transmitted belong to the same organization (corporate realm), we can hope that the tokens will not be compromised, that is to say accessible to applications outside the organization. It can also be assumed that the resources are located in a subnet protected by a firewall that prohibits application requests from outside the subnet. It can then be assumed that any application directed to the resources is allowed to receive a response.

This is called "trusted applications". But note that, from the point of view of a resource server, trust does not result from a particular character of the application, but from the fact that it is located inside a space of confidence that we assume inaccessible to other applications.

However, even in this case, a well-crafted attack could lead to stealing the token and exploit it with a foreign application.

In any case, the assumptions are never very good in terms of security.

Of course, if you address a token to a foreign resource, you must consider the token as a compromise because it can be used by a foreign application.

Rather than rest on a notion of confidence area and trustable applications, the resource server must be able to verify the legitimacy of the token holder.

But how ?

The specification clearly describes this limitation (section 10.3):

This specification does not provide any methods for the resource server to ensure that an access token presented to it by a give client was issued to that client by the authorization server.

Two types of applications must be distinguished with regard to the origin of the request:
applications "with back-end", ie sending their requests from a server: the request will be sent with the IP of the application server.
The applications without back-end, issuing their request from a user-agent (the browser of the end user, the operating system of the host computer of a native application etc. .): the request will be issued with the IP of the user-agent connection, possibly masked by a proxy.

In the current state of development of OAuthSD, we will only consider "back end applications" whose IP is related to their identity. In other words, we are only able to ensure data security in the case of the "Authorization Code" flow.

OAuthSD offers two ways to verify the legitimacy of a "back-end" application presenting the token based on the IP of origin:
by introspection with the IP of the applicant,
with the additional declarations of the JWT token 'cip_hash' or 'cip'.

The IP of the client application, to which the IP of the applicant will be compared, are determined as follows:
if the client application is registered with a non-empty 'ip' field of the 'clients' table, OAuthSD will use this value,
Otherwise, the IP (s) will be obtained by querying the DNS with the host name of the return URL (redirect URI) registered for the application [1] [2].

The general problem is developed here: Typology of applications with regard to data security.

Check by introspection with the IP of the applicant

The draft RFC 7662 implicitly recognizes the question, but does not give a standardized answer. It is indeed indicated in section 2.1:

The introspection endpoint MAY accept other OPTIONAL parameters to provide further context to the query. For instance, an authorization server may desire to know the IP address of the client accessing the protected resource to determine if the correct client is likely to be presenting the token. The definition of this or any other parameters are outside the scope of this specification, ....

OAuthSD do the following:
If the RS calling the Introspection endpoint transmits the IP address of its own requestor using the 'requester_ip' parameter, introspection verifies that this IP address is in the same subnet as the client application identified by the 'aud' declaration.

In order to avoid responding to a malware a protected resource receiving an identity token must validate it by passing the parameter 'requester_ip'.

On OAuthSD, for this verification to be effective, it is necessary to:
fill in the IP of the client applications when they are registered (otherwise the domain IP of the return URI will be used),
set to 'true' the configuration constant CHECK_CLIENT_IP.

Notes:
In general, the IP of the applications using the Introspect or UserInfo controllers is verified as indicated above, without being necessary to provide the 'requester_ip' parameter, in order to verify that it is well of the registered client application. It will be understood that in the case of a request made to a resource server that calls the Introspect controller, it is necessary to provide the IP of the applicant, otherwise it would be the IP of the resource server that would be monitored, not the one of the requester.
Note that there is also an optional verification of membership in the same domain or subdomain (see configuration constant CHECK_SAME_DOMAINS) performed by the Introspect controller.

Examples of calling introspection with the 'requester_ip' parameter

By header:

PHP

// Method Bearer + parameters by Post
$data1 = array(
'requester_ip' => $_SERVER['SERVER_ADDR'],
);
$authorization = "Authorization: Bearer ". $res1['id_token'];
$h = curl_init($introspection_endpoint);
curl_setopt($h, CURLOPT_HTTPHEADER, array(
'Content-Type: application/x-www-form-urlencoded',
'Authorization: Bearer ' . $res1['id_token']
));
curl_setopt($h, CURLOPT_RETURNTRANSFER, true);
curl_setopt($h, CURLOPT_POST, 1);
curl_setopt($h, CURLOPT_POSTFIELDS, http_build_query($data1));
$res = curl_exec($h);
...

Download

By Post :

// Post Methode
$data1 = array(
'token' => $res1['id_token'],
'requester_ip' => $_SERVER['SERVER_ADDR'],
);
$trace = $_SESSION['trace'];
$trace .= '----- Step 3 : JWT Introspection -----' . "
";
$trace .= 'access token : ' . $access_token . "
";
$trace .= 'data : ' . print_r($data1,true) . "

";
$_SESSION['trace'] = $trace;
$h = curl_init($introspection_endpoint);
curl_setopt($h, CURLOPT_RETURNTRANSFER, true);
curl_setopt($h, CURLOPT_TIMEOUT, 100); //100 : DEBUG
curl_setopt($h, CURLOPT_POST, true);
curl_setopt($h, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($h, CURLOPT_HTTPHEADER, array('Content-Type: application/x-www-form-urlencoded'));
curl_setopt($h, CURLOPT_POSTFIELDS, http_build_query($data1));
$res = curl_exec($h);
...

Download

Check with the JWT token 'cip_hash' or 'cip' additional claim

OAuthSD introduces a 'cip' or 'cip_hash' claim into the payload of the JWT token to enable verification of the IP of the applicant [3] [4].

This verification can be done locally, or by introspection called as described above with the parameter 'requester_ip'.

'cip_hash'
In the general case, an application has only one IP. In this case, it is this claim that will be generated, and not 'cip', with the advantage of hiding the IP of the client application by transmitting it in the form of a hash. If the application has multiple IPs, and the FORCE_CIP_HASH configuration constant is true, the first IP in the list will be used to generate the declaration.

'cip'
The 'cip' claim is generated when the IPs of the client application are multiple. Its value is a suite of space-separated IPv4.
However, if the FORCE_CIP_HASH configuration constant is true, the 'cip_hash' claim will still be issued instead.

Notes:
One of these additional claims will always be added to the JWT identity token payload of the OpenID Connect Authorization Code stream, but not in its OAuth 2.0 counterpart.
This method has the advantage of allowing verification by the protected resource (remember that the payload of the JWT token is simply URL64-encoded ). This is useful for blocking an attack without introspection, or when validation of the JWT token is done locally without introspection.
The Introspect controller will also perform IP verification with these claims. In the case of a resource server, it is necessary to transmit the parameter 'requester_ip'.
In principle, there should not be a proxy in front of an authentication server, which must have access to the network (including its own router-firewall). Any proxy located between the network and the authentication server must faithfully relay the IPs. Of course, reverse proxies are prohibited in front of an authentication server.

Alternate method: with JWT token audience claim

The oauth2-server-php library reduces "aud" to the client_id client id.

Yet the specification provides:

It MAY also contain identifiers for other audiences. In the general case, the aud value is an array of case sensitive strings."

Some implementations of OpenID Connect consider that the audience claim is application-level, which means that its value is a convention established within the same organization (corporate realm) between the application and the resource server.

With this in mind, the "aud" claim is a table of strings that can contain the IPs of the applications authorized to present the token. This will allow the resource server to directly check the IP and thus block some malware without having to issue an introspection request.

Since the audience claim is defined in the oauth2-server-php library, we must modify it to integrate the IP of the client application (provided when the application was registered on the server) in the "aud" claim. This development is underway.

Taking into account a "trusted proxy"

The question is whether one can trust the HTTP_X_FORWARDED_FOR declaration by which a proxy retransmits the IP of the original request.

Any proxy located between the Internet and the authentication server is controlled by the organization and can be considered trusted.
OAuthSD allows to designate these proxies by their IP in the configuration constant TRUSTED_PROXIES. If the USE_PROXY configuration constant is true, OAuthSD will replace for IP verification these IPs by the one provided by the HTTP_X_FORWARDED_FOR declaration.

Notes:
Among the trusted proxies we can find the reverse proxies whose function is to provide a cache system. The very principle of authentication excludes the use of cache.
Among the trusted proxies are also load balancers. Some of these proxies do not have a fixed IP. In this case, it will be impossible to apply the client verification by IP.
It will be necessary to verify that the trusted proxy only retransmits the real IP of the request by the declaration HTTP_X_FORWARDED_FOR, unless an identical mechanism makes it possible to recognize the trusted upstream proxies.
Note that this concept of trusted proxy is the opposite of what a large number of Internet users refer to as the proxy they expect to hide their IP address. Such proxies call themselves "anonymous" and are referred to as "private proxy", which has nothing to do with the fact that they are private, but that they aim to ensure the anonymity (privacy) of the user.
OAuthSD has a "SAFEIP" feature to block questionable IP addresses, most of which are those of such proxies. We are in the presence of two complementary mechanisms: The taking into account of trusted proxies allows to authorize the proxies of the LAN / Web interface, while the "SAFEIP" function will block the suspicious proxies of the Web.

[1] It is therefore important to ensure the integrity of the DNS. It would be best if the DNS of the applications and the DNS to which the server is accessing (preferably a local DNS) are in a trusted space, and / or protected by DNSSEC.

[2] This method can introduce an unwanted response time of the resource, which is why OAuthSD offers the registration of the IP.

[3] We extol the interest of the signed JWT identity token to link the identity of the end user, the application and the authorization scopes. However, a HTTP resource server can only identify the origin of the request by its IP in the server-server relationship. The identifier of the client transmitted by the token is not convincing since the token may have been "stolen". It is therefore essential to incorporate in the JWT token the IP of the legitimate application so that a resource server can check it.

[4] Can the 'aud' declaration be used to transmit this URL? This seems to be the case if we stick to the JWT specification for which 'aud' can be a list of URIs. But the OpenID Connect is more restrictive:

aud
MANDATORY. Audience (s) for which this identifier token is intended. It MUST contain the client_id OAuth 2.0 of the trusted party as the audience value. It MAY also contain identifiers for other audiences. In the general case, the aud value is an array of case-sensitive strings. In the usual special case where there is an audience, the aud value MAY be a case-sensitive string.

As a result, the oauth2-server-php library sets the value of the 'aud' parameter to the identifier of the client application. The 'aud' declaration is not the right choice for OAuthSD to propagate client IP.

OpenID Connect : Grant Type flows

DnC — 2019-09-04T20:03:00Z

The Grant Type flows specifically defined for the OpenID Connect protocol are:
Authorization Code Grant,
Implicit Grant,
Hybrid Flow.

Authorization Code Flow (spec. : Authorisation code flow) - the most commonly used stream for traditional web applications as well as native / mobile applications ( with security concerns ). Involves an initial redirection of the browser to the authentication server for authentication and user consent, and then a second request from the client application to retrieve the ID token.

The flow diagram is identical to its counterpart of OAuth 2.0, the difference being the Token Token that accompanies the access token.

The signing of this token provides protected resource servers (RS) with the opportunity to validate the token locally, provided that a key form is known to them.

Authorization code flow provides optimal security because:
the application secret, resident on the server, is protected,
tokens are not revealed to the browser (only run in a server-server connection),
the client application can be authenticated, just like the end user,
the signature of the token binds indissolubly: the identity of the end user, the identity of the application, the scope of the authorization.

The implementation of this flow within the framework of OAuthSD is detailed here: OpenID Connect : Autorisation via un code (Authorization Code Flow).

Implicit Flow (spec. : Implicit flow) - for browser-based applications that do not have a backend, such as a Javascript application. This stream is also used for single page applications (SPA). The identification token is received directly with the redirection response of the OP. No call to the return channel is required here. Because of this, the client can not be authenticated.

The implementation of this flow within the framework of OAuthSD is detailed here:Autorisation implicite.

Hybrid Flow (spec. : Hybrid Flow) - Essentially a combination of code and implicit flows, rarely used. It reads: "Allows the front-end and back-end application to receive tokens separately from each other". It seems more secure and just as easy to separately apply a flow of code and an implicit flow.

The Implicit and Hybrid flows are implemented by OAuthSD but their use is discouraged because they do not have the security advantages attached to OpenID Connect:
they compromise the application secret which is easily accessible to the public,
they expose the tokens to the browser of the end user, which makes possible exploitation by a malware,
they do not authenticate the client application.

Notes:
The features of OAuth 2.0 are integrated into the OpenID Connect protocol. All features of OAuth 2.0 and OpenID Connect can therefore be reached by OpenID Connect Endpoints, especially OAuth 2.0 Client / User Credentials. All flows are summarized here: OpenID Connect et OAuth 2.0 : Synthèse des flux d'autorisation (Grant Type).
The Hybrid flow is only partially implemented by OAuthSD. This method is little used and can be advantageously replaced by a succession of calls to the first two.