This is the Trace Id: 5bcadf584388c7ef503bd4b3f57726fc
Gå til hovedindholdet Hvorfor Microsoft Security Cybersikkerhed, der er drevet af kunstig intelligens Skysikkerhed Datasikkerhed og styring Identitet og netværksadgang Beskyttelse af personlige oplysninger og risikostyring Sikkerhed til kunstig intelligens Samlet SecOps Nul tillid Microsoft Defender Microsoft Entra Microsoft Intune Microsoft Priva Microsoft Purview Microsoft Sentinel Microsoft Security Copilot Microsoft Entra ID (Azure Active Directory) Microsoft Entra-agent-id Microsoft Entra eksternt id Microsoft Entra ID-håndtering Microsoft Entra ID-beskyttelse Microsoft Entra-interadgang Microsoft Entra-privatadgang Microsoft Entra Tilladelsesstyring Microsoft Entra Bekræftet id Microsoft Entra arbejdsbelastnings-id Microsoft Entra-domæneservices Azure Key Vault Microsoft Sentinel Microsoft Defender for Cloud Microsoft Defender XDR Microsoft Defender for Endpoint Microsoft Defender for Office 365 Microsoft Defender for Identity Microsoft Defender for Cloud Apps Microsoft Security administration af eksponering Admininstration af håndtering af sikkerhedsrisici til Microsoft Defender Microsoft Defender Threat Intelligence Microsoft Defender Suite til Business Premium Microsoft Defender for Cloud Microsoft Defender Administration af sikkerhedsniveau i skyen Ekstern angrebsoverfladeadministration til Microsoft Defender Azure Firewall Firewall til Azure-webapp Azure DDoS Protection Avanceret GitHub-sikkerhed Microsoft Defender for Endpoint Microsoft Defender XDR Microsoft Defender til virksomheder Kernefunktionaliteter i Microsoft Intune Microsoft Defender for IoT Admininstration af håndtering af sikkerhedsrisici til Microsoft Defender Microsoft Intune Advanced Analytics Microsoft Intune håndtering af slutpunktsprivilegier Microsoft Intune-administration af apps for virksomheder Ekstern hjælp til Microsoft Intune Microsoft Cloud PKI Microsoft Purview Kommunikationsoverholdelse Microsoft Purview Overholdelsesstyring Administration af Microsoft Purview-datalivscyklus Microsoft Purview eDiscovery Microsoft Purview-gennemgang Microsoft Priva Risikostyring Microsoft Priva Anmodninger om den registreredes rettigheder Microsoft Purview Datastyring Microsoft Purview Suite til Business Premium Funktionaliteter til datasikkerhed i Microsoft Purview Prisfastsættelse Tjenester Partnere Fokus på cybersikkerhed Kundehistorier Sikkerhed 101 Prøveversioner af produkter Anerkendelse fra branchen Microsoft Security Insider Microsofts rapport om digitalt forsvar Security Response Center Blog om Microsoft Security Microsoft Security-begivenheder Microsoft Tech Community Dokumentation Teknisk indholdsbibliotek Kurser og certifikater Compliance Program til Microsoft Cloud Microsoft Center for sikkerhed og rettigheder Service Trust Portal Microsoft Secure Future Initiative Hub til løsninger for virksomheder Kontakt salgsafdelingen Start gratis prøveversion Microsoft Sikkerhed Azure Dynamics 365 Microsoft 365 Microsoft Teams Windows 365 Kunstig intelligens Azure Space Mixed reality Microsoft HoloLens Microsoft Viva Kvantecomputere Bæredygtighed Uddannelse Biler Finansielle tjenester Myndigheder Sundhedspleje Produktion Detail Find en partner Bliv partner Partner Network Microsoft Marketplace Marketplace Rewards Softwareudviklingsfirmaer Blog Microsoft Advertising Udviklercenter Dokumentation Arrangementer Licenser Microsoft Learn Microsoft Research Vis oversigt over websted

Hvad er OIDC?

Få mere at vide om OpenID Connect (OIDC), en godkendelsesprotokol, der bekræfter brugeridentiteter, når de logger på for at få adgang til digitale ressourcer.

OpenID Connect (OIDC) defineret

OIDC (OpenID Connect) er en identitetsgodkendelsesprotokol, der er en udvidelse af OAuth 2.0 til at standardisere processen for godkendelse og godkendelse af brugere, når de logger på for at få adgang til digitale tjenester. OIDC giver godkendelse, hvilket betyder at det bekræfter, at bruger er dem, de udgiver sig for at være. OAuth 2.0 godkender, hvilke systemer disse brugere har adgang til. OAuth 2.0 bruges typisk til at give to ikke-relaterede programmer mulighed for at dele oplysninger uden at gå på kompromis med brugerdata. Mange personer bruger f.eks. deres mailkonti eller konti på sociale medier til at logge på et tredjepartswebsted i stedet for at oprette et nyt brugernavn og en ny adgangskode. OIDC bruges også til at angive enkeltlogon. Organisationer kan bruge en sikker identitets- og adgangsstyringssystem (IAM) som f.eks. Microsoft Entra ID (tidligere Azure Active Directory) som den primære godkender af identiteter, og derefter bruge OIDC til at overføre denne godkendelse til andre apps. På denne måde skal brugerne kun logge på én gang med ét brugernavn og én adgangskode for at få adgang til flere apps.

 

 

Nøglekomponenter i OIDC

Der er seks primære komponenter i OIDC:

  • Godkendelse er processen til at bekræfte, at brugeren er den, vedkommende udgiver sig for at være.

  • En klient er softwaren, f.eks. websted eller program, der anmoder om tokens, der bruges til at godkende en bruger eller få adgang til en ressource.

  • Afhængige parter er de programmer, der bruger OpenID-udbydere til at godkende brugere.  

  • Identitetstokens indeholder identitetsdata, herunder resultatet af godkendelsesprocessen, et id for brugeren og oplysninger om, hvordan og hvornår brugeren godkendes. 

  • OpenID-udbydere er de programmer, som en bruger allerede har en konto til. Deres rolle i OIDC er at godkende brugeren og videregive disse oplysninger til den afhængige part.

  • Brugere er personer eller tjenester, der forsøger at få adgang til et program uden at oprette en ny konto eller angive et brugernavn og en adgangskode. 

 

Hvordan fungerer OIDC-godkendelse?

OIDC-godkendelse fungerer ved at give brugerne mulighed for at logge på ét program og få adgang til et andet. Hvis en bruger f.eks. vil oprette en konto på et nyhedswebsted, kan vedkommende have mulighed for at bruge Facebook til at oprette sin konto i stedet for at oprette en ny konto. Hvis de vælger Facebook, bruger de OIDC-godkendelse. Facebook, der kaldes OpenID-udbyderen, håndterer godkendelsesprocessen og indhenter brugerens samtykke til at angive bestemte oplysninger, f.eks. en brugerprofil, til nyhedswebstedet, som er den afhængige part. 

Id-tokens 

OpenID-udbyderen bruger id-tokens til at overføre godkendelsesresultater og alle relevante oplysninger til den afhængige part. Eksempler på den type data, der sendes, omfatter et id, en mailadresse og et navn.

Områder

Områder definerer, hvad brugeren kan gøre med sin adgang. OIDC indeholder standardområder, der definerer ting som f.eks. hvilken afhængig part tokenet blev genereret for, hvornår tokenet blev oprettet, hvornår tokenet udløber, og den krypteringsgrad, der bruges til at godkende brugeren. 

En typisk OIDC-godkendelsesproces omfatter følgende trin:

  1. En bruger går til det program, vedkommende ønsker at få adgang til (den afhængige part).
  2. Brugeren indtaster sit brugernavn og sin adgangskode.
  3. Den afhængige part sender en anmodning til OpenID-udbyderen.
  4. OpenID-udbyderen validerer brugeren ’legitimationsoplysninger og får godkendelse.
  5. OpenID-udbyderen sender et identitetstoken og ofte et adgangstoken til den afhængige part.
  6. Den afhængige part sender adgangstokenet til brugerens enhed.
  7. Brugeren får adgang baseret på de oplysninger, der er angivet i adgangstokenet, og den afhængige part. 

Hvad er OIDC-flows?

OIDC-flows definerer, hvordan tokens anmodes og leveres til den afhængige part. Et par eksempler:

  • OIDC-godkendelsesflow: OpenID-udbyderen sender en entydig kode til den afhængige part. Den afhængige part sender derefter den entydige kode tilbage til OpenID-udbyderen i bytte for tokenet. Denne metode bruges, så OpenID-udbyderen kan bekræfte den afhængige part, før tokenet sendes. Browseren kan ikke se tokenet i denne fremgangsmåde, hvilket hjælper med at beskytte det.

  • OIDC-godkendelsesflow med PKCE-udvidelse: Dette flow er det samme som OIDC-godkendelsesflowet, bortset fra at det bruger en offentlig nøgle til PKCE-udvidelse (Code Exchange) til at sende kommunikation som en hash. Dette reducerer risikoen for, at tokenet opfanges.

  • Klientlegitimationsoplysninger: Dette flow giver adgang til web-API'er ved hjælp af identiteten af selve programmet. Det bruges typisk til server til server-kommunikation og automatiserede scripts, der ikke kræver brugerinteraktion.

  • Enhedskode: Dette flow giver brugerne mulighed for at logge på og få adgang til webbaserede API'er på internetforbundne enheder, der ikke har browsere eller har en dårlig tastaturoplevelse, f.eks. et smart tv. 

Yderligere flow, f.eks. det implicitte OIDC-flow, der er designet til browserbaserede programmer, anbefales ikke, fordi de udgør en sikkerhedsrisiko.

OIDC vs. OAuth 2.0

OIDC blev bygget oven på OAuth 2.0 for at tilføje godkendelse. OAuth 2.0-protokollen blev udviklet først, og derefter blev OIDC tilføjet for at forbedre dens funktioner. Forskellen mellem de to er, at OAuth 2.0 giver autorisation, mens OIDC giver godkendelse. OAuth 2.0 er det, der giver brugerne mulighed for at få adgang til en afhængig part ved hjælp af deres konto hos en OpenID-udbyder, og OIDC gør det muligt for OpenID-udbyderen at videregive en brugerprofil til den afhængige part. OIDC giver også organisationer mulighed for at tilbyde deres brugere enkeltlogon.

 

 

Fordele ved OIDC-godkendelse

Ved at reducere antallet af konti, som brugerne skal bruge for at få adgang til apps, giver OIDC flere fordele for både enkeltpersoner og organisationer:

Reducerer risikoen for stjålne adgangskoder

Når folk skal bruge flere adgangskoder til at få adgang til de apps, de har brug for til arbejde og deres personlige liv, vælger de ofte adgangskoder, der er nemme at huske, f.eks. Password1234!, og bruger den samme på tværs af flere konti. Dette øger risikoen for, at en ondsindet aktør gætter en adgangskode. Og når de kender adgangskoden til én konto, kan de muligvis også få adgang til andre konti. Ved at reducere antallet af adgangskoder, som nogen skal huske, øger det sandsynligheden for, at de vil bruge en stærkere og mere sikker adgangskode.

Forbedrer sikkerhedskontrollerne

Ved at centralisere godkendelse i én app kan organisationer også beskytte adgangen på tværs af flere apps med stærke adgangskontroller. OIDC understøtter tofaktorgodkendelse og multifaktorgodkendelse, som kræver, at brugerne bekræfter deres identitet ved hjælp af mindst to af følgende:

  • Noget, brugeren ved, typisk en adgangskode.

  • Noget, de har, f.eks. en enhed, der er tillid til, eller et token, der ikke nemt kan duplikeres. 

  • Noget brugeren har som et fingeraftryk eller en ansigtsscanning.

Multifaktorgodkendelse er en dokumenteret metode til at reducere kontokompromittering. Organisationer kan også bruge OIDC til at anvende andre sikkerhedsforanstaltninger, f.eks. privilegeret adgangsstyring, adgangskodebeskyttelse, logonsikkerhedeller identitetsbeskyttelse på tværs af flere apps. 

Forenkler brugeroplevelsen

Det kan være tidskrævende og frustrerende for folk at logge på flere konti i løbet af dagen. Og hvis de mister eller glemmer en adgangskode, kan nulstilling af det forstyrre produktiviteten yderligere. Virksomheder, der bruger OIDC til at give deres medarbejdere enkeltlogon, hjælper med at sikre, at deres arbejdsstyrke bruger mere tid på produktivt arbejde i stedet for at forsøge at få adgang til apps. Organisationer gør det også mere sandsynligt, at kunder tilmelder sig og bruger deres tjenester, hvis de tillader enkeltpersoner at bruge deres Microsoft-, Facebook- eller Google-konto til at logge på. 

Standardiserer godkendelse

OpenID Foundation, der omfatter profilerede brands som Microsoft og Google, har bygget OIDC. Det er udviklet til at være kompatibelt og understøtter mange platforme og biblioteker, herunder iOS, Android, Microsoft Windows og de største cloud- og identitetsudbydere.

Strømliner identitetsstyring

Organisationer, der bruger OIDC til at levere enkeltlogon til deres medarbejdere og partnere, kan reducere antallet af identitetsstyringsløsninger, de skal administrere. Det gør det nemmere at holde styr på ændring af tilladelser og giver administratorer mulighed for at bruge én grænseflade til at anvende adgangspolitikker og regler på tværs af flere apps. Virksomheder, der bruger OIDC til at give personer mulighed for at logge på deres apps ved hjælp af en OpenID-udbyder, reducerer antallet af identiteter, de overhovedet skal administrere. 

Eksempler på OIDC og use cases

Mange organisationer bruger OIDC til at aktivere sikker godkendelse på tværs af web- og mobilapps. Her er nogle få eksempler:

  • Når en bruger tilmelder sig en Spotify-konto, får de tre valgmuligheder: Tilmeld dig med Facebook, Tilmeld dig med Google, Tilmeld dig med din mailadresse. Brugere, der vælger at tilmelde sig via Facebook eller Google, bruger OIDC til at oprette en konto. De omdirigeres til den OpenID-udbyder, de har valgt (enten Google eller Facebook), og når de er logget på, sender OpenID-udbyderen Spotify grundlæggende profiloplysninger. Brugeren behøver ikke at oprette en ny konto til Spotify, og brugerens adgangskoder forbliver beskyttet.

  • LinkedIn giver også brugerne mulighed for at oprette en konto via deres Google-konto i stedet for at oprette en separat konto til LinkedIn. 

  • En virksomhed vil gerne give enkeltlogon til medarbejdere, der skal have adgang til Microsoft Office 365, Salesforce, Box og Workday for at udføre deres arbejde. I stedet for at kræve, at medarbejdere opretter en separat konto for hver af disse apps, bruger virksomheden OIDC til at give adgang til alle fire. Medarbejdere opretter én konto, og hver gang de logger på, får de adgang til alle de apps, de skal bruge til deres arbejde.  

Implementer OIDC for sikker godkendelse

OIDC indeholder en godkendelsesprotokol til forenkling af logonoplevelser for brugere og forbedring af sikkerheden. Det er en fantastisk løsning til virksomheder, der ønsker at opfordre kunderne til at tilmelde sig deres tjenester uden at skulle bøvle med administration af konti. Det giver også organisationer mulighed for at tilbyde deres medarbejdere og andre brugere sikker enkeltlogon til flere apps. Organisationer kan bruge identitets- og adgangsløsninger, der understøtter OIDC, f.eks. Microsoft Entra, til at administrere alle deres identiteter og godkendelsessikkerhedspolitikker på ét sted.

   

 

Få mere at vide om Microsoft Security

Ofte stillede spørgsmål

  • OIDC (OpenID Connect) er en identitetsgodkendelsesprotokol, der er en udvidelse af OAuth 2.0 til at standardisere processen for godkendelse og godkendelse af brugere, når de logger på for at få adgang til digitale tjenester. OIDC udfører godkendelse, hvilket betyder, at det bekræfter, at bruger er dem, de udgiver sig for at være. OAuth 2.0 godkender, hvilke systemer disse brugere har adgang til. OAuth 2.0 bruges typisk til at give to ikke-relaterede programmer mulighed for at dele oplysninger uden at kompromittere brugerdata. 

  • Både OIDC- og SAML- (Security Assertion Markup Language) er identitetsgodkendelsesprotokoller, der giver brugerne mulighed for at logge sikkert på én gang og få adgang til flere programmer. SAML er en ældre protokol, der er blevet udbredt til enkeltlogon. Den overfører data ved hjælp af XML-format. OIDC er en nyere protokol, der bruger JSON-format til at overføre brugerdata. OIDC bliver mere og mere populær, fordi det er nemmere at implementere end SAML og fungerer bedre med mobilapps.

  • OIDC står for OpenID Connect-protokollen, som er en identitetsgodkendelsesprotokol, der bruges til at give to ikke-relaterede programmer mulighed for at dele brugerprofiloplysninger uden at kompromittere brugerlegitimationsoplysninger.

  • OIDC blev bygget oven på OAuth 2.0 for at tilføje godkendelse. OAuth 2.0-protokollen blev udviklet først, og derefter blev OIDC tilføjet for at forbedre dens funktioner. Forskellen mellem de to er, at OAuth 2.0 giver autorisation, mens OIDC giver godkendelse. OAuth 2.0 er det, der giver brugerne mulighed for at få adgang til en afhængig part ved hjælp af deres konto hos en OpenID-udbyder, og OIDC gør det muligt for OpenID-udbyderen at videregive en brugerprofil til den afhængige part. Denne funktionalitet giver også organisationer mulighed for at tilbyde deres brugere enkeltlogon. OAuth 2.0- og OIDC-flowene ligner hinanden, bortset fra at de bruger lidt anderledes terminologi. 

    Et typisk OAuth 2.0-flow har følgende trin:

    1. En bruger går til det program, vedkommende vil have adgang til (ressourceserveren).
    2. Ressourceserveren omdirigerer brugeren til det program, hvor brugeren har en konto (klienten).
    3. Brugeren logger på med sine legitimationsoplysninger til klienten.
    4. Klienten validerer brugerens adgang.
    5. Klienten sender et adgangstoken til ressourceserveren.
    6. Ressourceserveren giver brugeren adgang.

    Et typisk OIDC-flow har følgende trin:

    1. En bruger går til det program, vedkommende ønsker at få adgang til (den afhængige part).
    2. Brugeren indtaster sit brugernavn og sin adgangskode.
    3. Den afhængige part sender en anmodning til OpenID-udbyderen.
    4. OpenID-udbyderen validerer brugeren ’legitimationsoplysninger og får godkendelse.
    5. OpenID-udbyderen sender et identitetstoken og ofte et adgangstoken til den afhængige part.
    6. Den afhængige part sender adgangstokenet til brugerens enhed.
    7. Brugeren får adgang baseret på de oplysninger, der er angivet i adgangstokenet, og den afhængige part. 
  • OpenID-udbyderen bruger id-tokens til at overføre godkendelsesresultater og alle relevante oplysninger til det afhængige partsprogram. Eksempler på den type data, der sendes, omfatter et id, en mailadresse og et navn.

Følg Microsoft Security