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 (...)
i-Tego >
Documentation >
Authentification
>
OAuth Server by DnC (OAuthSD) is an authentication server that implements OAuth 2.0 et OpenID Connect.
Secure data access with OpenID Connect
With the Single Sign On (SSO), an entity allows users of its applications to seamlessly navigate from one to the other. But even more:
By centralizing the authentication of applications and users, an OpenID Connect server makes it possible to perfectly control access to sensitive 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 practice : "Authorization Code Grant"
When an application needs to authenticate user (for example to access protected resources), it will contact the OpenID Connect server. The latter identifies the application by exchanging with it an authorization code.
The server identifies the user of the application and determines its rights on this application. The user gives his consent to authorize the application to use all or part of his personal data.
This results in an authentication, binding the user and his personal data, the application and the rights of the user on the application (or vice versa) into a tamper-proof and transmissible object called Identity Token ( IDToken ).
The application then uses the Identity Token to access protected resources and obtain or modify data based on the rights of the user.
Different flows for different configurations
All application, server, and resource configurations do not provide the same level of security, especially for authenticating the application.
For optimal security, the application should be of "web" type and implement the Authorization Code Grant.
However, OpenID Connect can meet different needs, especially for mobile applications, with different Grant Types. Many have moved away from maximum security by applying OIDC workflows to mobile and workstation applications ("native" applications as opposed to "web" applications). PWAs, which allow the authorization flow with code to be used under optimal security conditions, therefore offer so many advantages that they should replace all native applications, whether installed on a mobile or on a workstation.
Supervision: organizing the configuration of the rights
In a large entity, with several thousand end-users (both staff and customers) and a large number of applications, it will not be possible to centralize the management of individual rights in relation to applications because they will be distributed users and applications among members of the entity.
Using a specific application
A specific application will have to delegate the configuration of rights to the local level. Such an application is not part of the OpenID Connect specification. OAuthSD offers external applications the means to manipulate the data of the server through a HTTP API REST + TreeQL whose access is secured with ... OAuthSD.
Using an existing identification system: LDAP etc.
An organization implementing an identification system already has the means to manage users and their profile. OAuthSD allows the integration of third-party identification systems, whether standard such as LADP and Active Directory (Kerberos) or organization-specific (ID card, biometric identification ...).
In addition, it is also possible to use the users data of an application developed with a CMS such as WordPress, SPIP or Typo3.
Providing different identification modules, OAuthSD allows automatic integration of this data by the authentication server. This results in a configuration in which the authentication server delegates the identification of the user to an Identity Provider.
Put an end to passwords
Some identification systems allow you to no longer use a password. Moreover, they prohibit the user from registering himself to manufacture his login credentials. Such systems offer companies the means to protect access to data with great security. DnC’s IdentMaster or OpenID Connect Identification with ID Card give working examples built on the OAuthSD authentication server.
The OpenID Foundation: standardization and certification
The OpenID Connect standard is coordinated by the largest IT companies within the OpenID Foundation. An abundant documentation provides the technical framework for the development of an authentication server (called "OpenID Connect Provider" or OP).
A battery of tests, made available by the foundation, allows the OAuthSD server to obtain the OpenID Connect Certification. This ensures that the authentication server conforms to the current state of the standard. A server should be updated and regularly tested.
What implications for client applications?
"Client" applications must be able to delegate user authentication to the OIDC server. More and more applications offer this possibility in accordance with the OpenID Connect standard.
When this is not the case, a special development is needed to adapt the application. This usually involves substituting an OIDC module for the code of the classical connection. Adaptation is therefore particularly easy in the context of a new development or an "open source" application.
Bertrand Degoy supports you
A company wishing to adopt SSO with OpenID Connect must follow three steps:
install an OpenID Connect Provider (OP) server,
adapt the applications so that they delegate user authentication to the OP,
register users on the Op, or integrate an existing identification system.
Impregnated with the consultant’s method and ethics, Bertrand Degoy supports you in your OpenID Connect project to set up your own OAuthSD authentication server. His vertical mastery of the subject allows him to assist developers as well as project managers and the owner.
Finally, if the purpose of the intervention is to adapt OAuthSD to a configuration and objectives that are specific to you, know that Bertrand Degoy will pass on to your teams full knowledge of the application, including the source code.
Latest articles :
OIDC session management: Features
Discover :
Q: is authorization flow as good for native/mobile ?
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!
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 (...)
Develop :
Verification Key for Code Exchange (PKCE)
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 (...)
previous page | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | ... | 11 | next page
Site Map :
OpenID Connect OAuth Server dedicated