One login, endless possibilities: the single sign-on revolution.

Article by Daniel Marella – Full-stack Developer at AzzurroDigitale

Have you ever had to remember a thousand usernames and passwords to access your work tools?
With Single Sign-On (SSO), this problem disappears: you authenticate just once and automatically access all connected applications and services, without having to enter your credentials every time you change tools.

In practice: just one login and off you go, everything else opens automatically.

At AzzurroDigitale, we’ve implemented single sign-on in several projects, such as the Wepladoo integration for Staff International, using the OpenID Connect (OIDC¹) standard.
The results? They fully confirm the concrete benefits of SSO, for both end users and businesses.

Benefits of SSO for the end user

✅ Simplified Access
A single login to access all authorized systems means no more remembering multiple credentials.

🚀 Increased productivity
Instant access to work tools, even remotely and across devices.
Flexible switching between apps and fewer distractions: everything contributes to a more efficient workday.
Switching between apps (CRM, ERP, project management tools, etc.) is instant and eliminates constant log-ins and log-outs, improving daily workflow.

🔐 Greater personal security
Fewer passwords = fewer errors and risks. The experience remains seamless without compromising data protection.

Benefits of SSO for the company

🧾 Simplified Compliance
Centralized, traceable access managed from a single console. SSO simplifies compliance with regulations such as GDPR, ISO, and HIPAA², ensuring control and auditability.

🔐 Strengthened security
Fewer credentials to manage = fewer vulnerabilities. SSO reduces the attack surface and integrates easily with MFA³, strengthening access protection.

📉 Fewer errors and IT tickets
Fewer forgotten passwords, fewer support requests. Users are more autonomous, and IT can focus on strategic projects rather than managing repetitive tickets.

🔄 Faster onboarding and offboarding
With SSO integrated into user management, new employees have immediate access to work tools, and if they leave, their accounts are centrally and securely deactivated.

📊 Better control and governance
Continuous monitoring and complete visibility into who is accessing what, when, and from where. Ideal for strengthening security and preventing anomalous behavior.

⚙️ Easy integration and scalability
Based on open standards such as OpenID Connect (OIDC), SSO integrates with any IT ecosystem, facilitating growth and the adoption of new digital solutions.

How does SSO work?

With single sign-on, once you’ve logged in for the first time, you’ll no longer have to enter your username and password for each application. More specifically:

• The company uses an Identity Provider (IdP⁴), the system that manages and verifies user access.
  The IdP is the central “gatekeeper” of corporate access security: it authenticates users when they attempt to log in, securely manages credentials (often with support for multi-factor authentication, MFA), and issues the digital tokens needed to access applications without having to enter a username and password each time.
• Enterprise applications “trust” the token issued by the IdP
• Everything happens via standard protocols (e.g. SAML⁵, OAuth2, OpenID Connect)

In our case, the SSO implementation is based on OpenID Connect (OIDC), a modern standard designed to manage authentication securely, flexibly, and suitable for cloud and API-driven systems. It’s an authentication protocol designed to securely identify users and allow applications to trust this identity, without having to directly manage passwords.

OpenID Connect (OIDC), for short

The standard we’ve adopted is OpenID Connect, perfect for cloud and API-driven environments.
How it works:

1. The user tries to log in to a company app.
2. The app redirects it to the IdP (Google, Azure AD, Okta…).
3. The user enters the credentials and, if required, completes the MFA.
4. The IdP generates:
   • ID Token → contains the user’s identity.
   • Access Token (optional) → to access protected resources.
5. The app validates the token and grants access.

An ID Token contains a set of key user information, such as email address, name, a unique identifier, any assigned roles or permissions, and the token’s expiration date. All this data is digitally signed, so applications can verify its authenticity and trust its content without having to contact the Identity Provider again.

Choosing OpenID Connect means opting for a solution designed for modern environments: it is perfect for web apps, mobile applications, and APIs, it integrates easily into distributed and cloud-native architectures, it guarantees security thanks to signed, temporary tokens compatible with multi-factor authentication, and it is simple to implement even with existing frameworks and providers.

👉 Don’t have an Identity Provider (IDP) yet?
No problem: AzzurroDigitale can support you throughout the entire integration process, guiding you step by step towards a complete, secure, and customized SSO solution for your business.

---

Deep Tech for Insiders

Inside the SSO Engine (with OpenID Connect) – Wepladoo for StaffInternational

SSO is much more than a simple user experience: it is a complex identity orchestration architecture that relies on standardized protocols, secure exchange of digitally signed tokens, and reliable communications between distributed systems.

The key technology in StaffInternational’s SSO integration with Wepladoo is OpenID Connect (OIDC), an identity protocol that enables secure and standardized authentication flows for user management.

📚 The fundamental components of the system

Component	Role
User Agent	Browser or mobile app used by the user to interact with applications
Client	Application that requests access to protected resources
Authorization Server / Identity Provider (IdP)	Responsible for authenticating the user and issuing security tokens
Resource Server	Server that hosts protected resources or APIs, accessible only with valid tokens
OpenID Provider (OP)	Authorization Server che implementa lo standard OpenID Connect

In our setup, we use the Authorization Code flow to ensure robust and secure authentication in web and mobile environments.
Here’s how it works, step by step:

Step 1 – Initial Redirect

The client redirects the user to the IdP’s /authorize endpoint, passing:

• client_id
• redirect_uri
• scope=openid
• other configuration parameters (es. response_type=code)

Step 2 – Authentication and MFA Verification

The user enters their credentials. If applicable, the IdP also requires multi-factor verification (MFA), increasing security.

After the user authenticates and consents, the IDP returns a response to the app at the given redirect URI using the method specified in the parameter response_mode.

The successful response when using response_mode=form_post looks like this:

Parameter	Description
id_token	ID token requested by the app. You can use the id_token parameter to verify the user’s identity and initiate a session with them.
state	If a state parameter is included in the request (not required), the same value must appear in the response. The app must verify that the state values ​​in the request and response are identical.

Error responses can also be sent to the redirect URI so that the app can handle them, for example:

Parameter	Description
error	An error code string that can be used to classify the types of errors that occur and fix them.
error_description	A specific error message that helps you identify the root cause of an authentication failure.

Step 3 – Release the Authorization Code

After authentication, the IdP redirects the client’s browser to the redirect_uri, attaching a temporary authorization code, which represents permission to exchange the authenticated identity.

Step 4 – Exchange code for token

The client sends a POST request to the IdP’s /token endpoint, including:

• The authorization code received
• client_id and, if applicable, client_secret

If the request is valid, the IdP returns:

• ID Token (signed JWT), which contains the user’s identity data
• Access Token
  • It’s a JWT intended to be read by the OAuth client, which is the recipient of the token.
    It can also contain user information, such as their name or email address.
    Client applications can use it to build a user profile and personalize the user experience.

• Refresh Token (optional), to renew tokens without re-login

Step 5 – Login and Token Verification

The client:

• Decrypt and verify the ID Token signature using the IdP’s public key
• Use the Access Token to authorize requests to protected resources
• Manages the user session without the need for further logins as long as the tokens are valid

Step 6 – Retrieving User Information Using Access Token

After receiving the tokens from the Authorization Server, the client uses the Access Token to request additional information about the user directly from the OpenID Provider’s endpoint /userinfo.

• The client sends an API call to the /userinfo, including the Access Token in the Authorization: Bearer <access_token> header.

• The server responds with a JSON payload containing additional claims about the user, such as name, email, role, etc.
• This allows the client to get dynamic, up-to-date data without having to include all of it in the Token ID, thus keeping the tokens lighter and more secure.

Below is an explanatory chart from Authorization Code Flow that illustrates the Authorization Code Flow with OpenID Connect step-by-step, showing how the user, client, and Identity Provider interact for a secure and seamless login.

If you want to learn more or implement the solution, here are some additional resources:

• 🔗 An Illustrated Guide to OAuth and OpenID Connect
• 🔗 Creating an OpenID connect system
• 🔗 OpenID Connect Official Site
• 🔗 Auth0: Authorization Code Flow Explained
• 🔗 Microsoft Identity Platform Documentation
• 🔗RFC 6749: The OAuth 2.0 Authorization Framework

Developer Glossary