OpenID Connect (OIDC): Pourquoi cela compte pour l'authentification et la gestion de l'identité

Explorez OpenID Connect (OIDC), une méthode d'authentification moderne qui simplifie les connexions, améliore la sécurité et améliore l'expérience utilisateur dans diverses applications.

Let's face it, login systems are everywhere. From ordering pizza to accessing office tools, every app asks you to 'Sign in with Google' or 'Log in with Microsoft'. OpenID Connect (OIDC) is the modern way for apps to authenticate users, building upon OAuth 2.0 to not only grant access but also verify user identity.

Avouons-le, les systèmes de connexion sont partout. De la commande de pizza à l'accès aux outils de bureau, chaque application vous demande de «vous connecter avec Google» ou de «connecter avec Microsoft». OpenID Connect (OIDC) est le moyen moderne pour les applications d'authentifier les utilisateurs, en s'appuyant sur OAuth 2.0 pour non seulement accorder l'accès, mais également vérifier l'identité de l'utilisateur.

What is OpenID Connect (OIDC)?

Qu'est-ce que OpenID Connect (OIDC)?

In simple terms, OIDC is a modern way for apps to authenticate users by piggybacking on OAuth 2.0. While OAuth is all about granting access to stuff like calendars and photos, OIDC adds an identity layer on top. This means it can also confirm who you are, not just whether you have permission to do something.

En termes simples, OIDC est un moyen moderne pour les applications d'authentifier les utilisateurs en repliant sur OAuth 2.0. Alors que OAuth consiste à accorder l'accès à des trucs comme les calendriers et les photos, OIDC ajoute une couche d'identité sur le dessus. Cela signifie que cela peut également confirmer qui vous êtes, pas seulement si vous avez la permission de faire quelque chose.

Consider SSOJet, a product designed to connect apps with multiple identity providers (like Google, Azure AD, and Okta) using standards like SAML and OIDC. When a customer wants users to log in with their Google or Azure AD account, SSOJet uses OIDC behind the scenes.

Considérez SSOJet, un produit conçu pour connecter des applications avec plusieurs fournisseurs d'identité (comme Google, Azure AD et Okta) en utilisant des normes comme SAML et OIDC. Lorsqu'un client souhaite que les utilisateurs se connectent avec leur compte Google ou Azure, SSOJet utilise OIDC dans les coulisses.

Why Should You Care About OIDC?

Pourquoi devriez-vous vous soucier de OIDC?

OIDC makes logins faster, safer, and easier for both developers and users. No one wants to remember another password, and you don’t want to store passwords you don’t have to. With OIDC, you can offload that to trusted providers while still knowing exactly who’s using your app.

OIDC rend les connexions plus rapides, plus sûres et plus faciles pour les développeurs et les utilisateurs. Personne ne veut se souvenir d'un autre mot de passe et vous ne voulez pas stocker des mots de passe que vous n'avez pas à le faire. Avec OIDC, vous pouvez décharger cela aux fournisseurs de confiance tout en sachant exactement qui utilise votre application.

In a nutshell:

En un mot:

• It’s a standard: Based on OAuth 2.0, widely adopted.
• It’s simple: Easy to implement with existing libraries.
• It’s secure: Offloads authentication to trusted providers.

How the OIDC Login Flow Works

Comment fonctionne le flux de connexion OIDC

When you hit that 'Login with Google' button, here’s what happens: Your app (the Relying Party) delegates the password management to a trusted Identity Provider (IdP) like Google or Microsoft. The IdP handles the login and then tells your app who just signed in.

Lorsque vous appuyez sur ce bouton «Connectez-vous avec Google», voici ce qui se passe: votre application (la partie en comptant) délègue la gestion des mots de passe à un fournisseur d'identité de confiance (IDP) comme Google ou Microsoft. L'IDP gère la connexion, puis indique à votre application qui vient de signer.

The OIDC Login Flow in Quick Steps:

Le flux de connexion OIDC en étapes rapides:

1. User clicks “Login.”
2. App redirects the user to the IdP (e.g., Google).
3. User logs in at the IdP.
4. IdP redirects the user back to your app with a special code.
5. Your app exchanges the code for an ID Token (and optionally, an Access Token).
6. Your app validates the ID Token to confirm the user’s identity.

Key Endpoints You’ll Use:

Points de terminaison clés que vous utilisez:

• /authorize: Where the login flow starts.
• /token: Where you exchange the code for tokens.
• /userinfo: Where you can request more user details (like email, name, etc.).

OIDC standardizes this process, so you don’t have to build a new flow for every IdP.

OIDC standardise ce processus, vous n'avez donc pas à construire un nouveau flux pour chaque PDI.

Picking the Right Identity Provider (IdP)

Choisir le bon fournisseur d'identité (IDP)

The next thing you’ll need to figure out is which identity provider your app should use. If you’re building for yourself, it’s simple — maybe you just need Google or Microsoft. But if you’re building something where your customers might use different providers (Google, Azure AD, Okta, etc.), you need to be a bit smarter about it.

La prochaine chose que vous devrez déterminer est le fournisseur d'identité que votre application doit utiliser. Si vous construisez pour vous-même, c'est simple - peut-être que vous avez juste besoin de Google ou de Microsoft. Mais si vous construisez quelque chose où vos clients peuvent utiliser différents fournisseurs (Google, Azure AD, Okta, etc.), vous devez être un peu plus intelligent à ce sujet.

An IdP is basically the service that handles your users’ authentication. It’s the one saying, “Yep, this person is who they claim to be.”

Un PDI est essentiellement le service qui gère l'authentification de vos utilisateurs. C'est celui qui dit: «Oui, cette personne est ce qu'elle prétend être.»

OIDC Login Example — .NET Web App

Exemple de connexion OIDC - Application Web .NET

Here’s how to set up a basic OIDC login in a .NET web app:

Voici comment configurer une connexion OIDC de base dans une application Web .NET:

1. Configure Your Application in your IdP’s developer console.
2. Add NuGet Packages to your .NET project.
3. Update Program.cs / Startup.cs with your IdP details.
4. Add Login and Logout Endpoints to handle the redirects.

Run your app, visit /login, and you’ll get redirected to Google’s sign-in page. Log in, and your app now knows who you are — using OIDC.

Exécutez votre application, visitez / connectez-vous et vous serez redirigé vers la page de connexion de Google. Connectez-vous, et votre application sait maintenant qui vous êtes - en utilisant OIDC.

Tokens in OIDC

Tokens dans OIDC

When the IdP sends your app a response after a successful login, you’ll typically get:

Lorsque l'IDP envoie une réponse à votre application après une connexion réussie, vous obtiendrez généralement:

• ID Token: A JWT that contains user information.
• Access Token: Used to access protected resources.
• Refresh Token: Used to get new Access Tokens without prompting the user to log in again.

Key parts to check in the ID Token:

Pièces clés pour vérifier le jeton ID:

• iss: Issuer (who issued the token).
• sub: Subject (the user’s unique ID).
• aud: Audience (who the token is intended for).
• exp: Expiration time (when the token expires).

Validating Tokens

Valider les jetons

Don’t just accept any token you get. Validate it. Here’s what to check before trusting any ID Token:

N'acceptez pas de jeton que vous obtenez. Validez-le. Voici quoi vérifier avant de faire confiance à n'importe quel jeton ID:

• Check the signature to ensure the token hasn’t been tampered with.
• Verify the issuer (iss) matches your IdP.
• Confirm the audience (aud) is your application.
• Ensure the token hasn’t expired (exp).

Where Should You Store Tokens?

Où devriez-vous stocker des jetons?

• ID Tokens: In a secure, HttpOnly cookie (server-side).
• Access Tokens: In memory on the client-side (if needed for API calls).
• Refresh Tokens: Server-side only.

Handling Token Expiry

Manipulation de l'expiration des jetons

Tokens don’t live forever — and that’s a good thing. When an Access Token or ID Token expires:

Les jetons ne vivent pas éternellement - et c'est une bonne chose. Lorsqu'un jeton d'accès ou un jeton ID expire:

• Redirect the user to the login page to reauthenticate.
• Use a Refresh Token to get a new Access Token (if you have one).

Wrapping Up

Emballage

From understanding what OIDC is and how its login flow works, to picking your IdP, wiring it up in a .NET app, handling tokens safely, and managing sessions and logouts like a pro, you're now well-equipped to implement modern authentication in your applications.

De comprendre ce qu'est l'OIDC et comment fonctionne son flux de connexion, pour choisir votre PDI, le câbler dans une application .NET, la gestion des jetons en toute sécurité et la gestion des sessions et des déconnexions comme un pro, vous êtes maintenant bien équipé pour implémenter l'authentification moderne dans vos applications.

Next move? Spin up your own test project, plug in Google as an IdP, and watch the magic happen. Once you get the basics down, you’ll be ready to connect Azure AD, Auth0, or any other OIDC-compliant provider you want.

Prochain mouvement? Faites tourner votre propre projet de test, branchez Google en tant que PDI et regardez la magie se produire. Une fois que vous aurez obtenu les bases, vous serez prêt à connecter Azure AD, Auth0 ou tout autre fournisseur conforme à OIDC que vous souhaitez.

Happy coding, and may your authentication flows always be secure and seamless!

Happy Coding, et que vos flux d'authentification soient toujours sécurisés et transparents!